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: Thomas Walker <Thomas dot Walker at morganstanley dot com>, Zack Weinberg <zack at codesourcery dot com>, Dara Hazeghi <dhazeghi at yahoo dot com>, gcc-patches at gcc dot gnu dot org, mbp at sourcefrog dot net, distcc at lists dot samba dot org, Neil Booth <neil at daikokuya dot co dot uk>
- Date: 03 Aug 2003 10:56:18 -0300
- Subject: Re: [distcc] gcc bootstraps with distcc
- Organization: GCC Team, Red Hat
- References: <ED06E029-B327-11D7-BDE9-003065A77310@apple.com><or4r1tvene.fsf@livre.redhat.lsd.ic.unicamp.br>
On Jul 11, 2003, Alexandre Oliva <aoliva@redhat.com> wrote:
> 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.
It was actually simpler and sufficient to simply let line-breaks
through while parsing functional-macro arguments. Column numbers go
out of sync, but Neil doesn't care, so...
With this patch and the one I posted about 1 hour ago, a bootstrap of
GCC with distcc passes without having to disable the use of localhost.
Ok to install?
Index: gcc/ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
* c-ppoutput.c (cb_line_change): Don't skip line changing while
parsing macro arguments in the top-level context.
Index: gcc/c-ppoutput.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-ppoutput.c,v
retrieving revision 1.7
diff -u -p -r1.7 c-ppoutput.c
--- gcc/c-ppoutput.c 13 Jul 2003 17:34:17 -0000 1.7
+++ gcc/c-ppoutput.c 3 Aug 2003 13:38:03 -0000
@@ -262,7 +262,8 @@ print_line (const struct line_map *map,
static void
cb_line_change (cpp_reader *pfile, const cpp_token *token, int parsing_args)
{
- if (token->type == CPP_EOF || parsing_args)
+ if (token->type == CPP_EOF
+ || (parsing_args && pfile->context && pfile->context->prev))
return;
maybe_print_line (print.map, token->line);
--
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