Re: [distcc] using distcc to speed up gcc bootstraps

[Alexandre Oliva <aoliva at redhat dot com>]

On Aug 24, 2002, Neil Booth <neil@daikokuya.co.uk> wrote:

> Yes, have two strings, with the second one optional and only valid at
> the start of a preprocessed file.  Just an idea; I think it's cleaner.
> It is backwards compatible.

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.

>> > Why did your patch remove the gettext calls on the pseudo file names?
>> 
>> Because other parts of the compiler compare source filenames with
>> <built-in>, so those strings shouldn't be subject to translation.

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

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.  But then, I don't know what the problem would be if the
macros were marked as defined in a file named, say, <pré-definido>.
Perhaps it could instead take any names enclosed in angle brackets as
filename 0, instead?  Or just do away with this special case?  I don't
know.  Any DWARF-2 debugging info experts around?

>> Also, you wouldn't want them to be handled differently if you get a
>> file preprocessed with another language enabled, would you?

> No, but remember that file names appear in diagnostics.

Good point.  And we definitely don't want to be translating filenames
:-)

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