[distcc] using distcc to speed up gcc bootstraps

Neil Booth neil at daikokuya.co.uk
Sun Aug 25 06:53:01 GMT 2002

Alexandre Oliva wrote:-

> So are additional strings allowed at all?  I thought the filename was
> supposed to be followed by flags only.  In fact, the CPP manual seems
> to support my understanding.  If the documented format does not
> support this, I don't see how it can be considered backward
> compatible.

Of course, but that doesn't prevent you adding it for the first line
of the original file now, does it?  And it would still be backwards

> > I don't think they should be doing that.  Why do they feel the need
> > to do that?  
> dwarf2out.c maps that to filename 0, whereas tree.c uses "<built-in>"
> as the source file name in case input_filename is NULL (should never
> happen, right?).  cp/decl.c, in the debugging function
> print_binding_leval, doesn't print info about declarations associated
> with files named <built-in> either.

I think this is old code before integrated CPP.

> The only relevant use of <built-in> seems to be in dwarf2out.c, and
> that's actually an important one.  In case you want to get built-in
> macros through to debugging info, you need it to be able to detect the
> proper name.

This is another case where I don't think we can reasonably expect
to do as well with preprocessed files as with original files.  Original
files should be easy to get right.  We can only get debug info for
macros for .i files with -dD anyway.

As far as I'm concerned, the only reason for "<built-in>" and "<command-
line>" is diagnostics; I did the work to get them right between 3.0 and
3.1 I think.


More information about the distcc mailing list