[distcc] gcc bootstraps with distcc

[Alexandre Oliva]

On Jul 10, 2003, Mike Stump <mrs@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.

Yay.

> 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@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