[distcc] gcc bootstraps with distcc

Alexandre Oliva aoliva at redhat.com
Fri Jul 11 05:04:03 GMT 2003

On Jul 10, 2003, Mike Stump <mrs at apple.com> wrote:

> They bear a strong resemblance to my own patches that I developed
> and delivered in our product for distcc.  :-)

Did you base yours in the patch I posted 11 months ago? :-)

> Your version has one advantage over mine,
> they reuse of the # format.

That's what I was set to use from the beginning.  It's unfortunate
that it has faced so much resistance :-(

> This is more critical than you may know.

I knew it :-)  Gratuitous extensions are evil :-)

> In my version, I use #pragma gcc_debug_pwd "/sdf/sdf", and that's
> turned out to be not as good as I had thought it would be.


> The next problem, before you relicate more work, will be to make
> distcc work well in the presence of pch.

This doesn't really make sense to me.  I mean...  pch?  We're not
doing integrated preprocessing, how does pch come into play?

What I'd really like is a patch that fixes the problem I refer to
below, after posting my first patch for `# 1 "<directory>/path/name"':

On Aug 23, 2002, Alexandre Oliva <aoliva at redhat.com> wrote:

> Unfortunately, the bootstrap compare test still failed :-(

> The reason is that gcc generates different debugging information for a
> source file such as:

> #define FOO(X)
> int FOO((x, y,
>          z, w)) bar;
> int baz;

> If we preprocess this code and compile it separately (e.g.,
> -save-temps), the result is:

> # 2 "<filename>"
> int bar;

> int baz;

> i.e., the declaration of bar is moved from line 3 to line 2.  However,
> with integrated preprocessing, the declaration of bar is correctly
> flagged as in line 3 in debugging information.  This difference is
> enough for the bootstrap compare to fail, since at least varray.h
> contains a number of union member declarations like above, with
> multi-line GTY() macro invocations between the types and the
> declarators.  Oh, well...

> This should probably be fixed.  I don't think it's good that compiling
> with or without -save-temps can result in different assembly output.
> Neil, Zack, any comments?

I've written patches that fixed this problem, but they were rejected
or ignored.  There's not even agreement that this is a legitimate bug

The way I'm thinking of fixing it is to try to figure out when we
finish expanding the outermost macro, and at that point emit an
explicit line&column adjust to get back in sync with what the
integrated preprocessor would use.  Unfortunately, the patch I had
that would make sure the integrated and separate preprocessors agreed
on the location of every token was conceptually rejected, and I never
posted it to the list (IIRC) because it actually exposed problems in
the integrated preprocessor's tracking of line&column that I could
never track down.  It wasn't worth pursuing, since both Neil and Zack
considered it a bad idea to add enough information to the preprocessed
file such that we'd be able to tell exactly where each token came
from, at the expense of making it bigger.

Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

More information about the distcc mailing list