This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [distcc] gcc bootstraps with distcc
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Mike Stump <mrs at apple dot com>
- Cc: Neil Booth <neil at daikokuya dot co dot uk>, mbp at sourcefrog dot net, gcc-patches at gcc dot gnu dot org, Dara Hazeghi <dhazeghi at yahoo dot com>, distcc at lists dot samba dot org, Thomas Walker <Thomas dot Walker at morganstanley dot com>, Zack Weinberg <zack at codesourcery dot com>
- Date: 11 Jul 2003 02:03:17 -0300
- Subject: Re: [distcc] gcc bootstraps with distcc
- Organization: GCC Team, Red Hat
- References: <ED06E029-B327-11D7-BDE9-003065A77310@apple.com>
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