Lazy allocation of DECL_ASSEMBLER_NAME

[Mark Mitchell]

Geoff Keating wrote:

>>Yes.  I have partial code implementing this.  The fiddliest part is
>>the nontransitive type comparison problem that Dale is encountering.
>>I personally think that the front end should go to whatever lengths
>>are necessary to present just one type to the language-independent
>>compiler, even across multiple translation units, even in the presence
>>of a nontransitive type system.  I think this is easier than it might
>>sound - the trick I have in mind is permuting TYPE_MAIN_VARIANT so
>>that it's always the appropriate choice for *this* translation unit.
>>    
>>
>
>It might be difficult to determine which translation unit is "this
>unit" at any given point; you might have code that does:
>  
>
There are lots of things that are hard about inter-module analysis, as 
you of course know. :-)

It's an inherent design problem: we're essentially trying to combine 
multiple C translation units into a single C translation unit, and C is 
not a language that permits that.  Most object file formats are designed 
to support C, so we see these problems at that level too.  For example, 
in the past, I've complained about the fact that if we have two static 
functions with the same name in different translation units, the single 
.o that we generate renames them.

In the example that you give, the program is not conforming if the 
definitions of "struct foo" are not identical across translation units.  
(Or, at least, that would be true in ISO C++.  It might not have to be 
true in ISO C.  You may know more than I.)  In any case, if the 
structures do not match up across the translation units, we should just 
not combine them.  That is certainly not the common case.

We'll likely break some aspects of inter-module optimization when we fix 
some of the single translation-unit issues.  That is what we get for 
collectively not agreeing on a single development plan.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com