Lazy allocation of DECL_ASSEMBLER_NAME

[Mark Mitchell]

>Could you mention this in the documentation of DECL_ASSEMBLER_NAME in
>c-tree.texi?
>  
>
Yes.

>>To check for whether two declarations are the same, just compare their
>>addresses.
>>    
>>
>
>You mean, the addresses of the trees
>  
>
Yes, I mean the addresses of the trees.  If that makes PCH unhappy, then 
we use DECL_UID.  (Much though I think that wasting a word in every DECL 
for a UID when the address is *already* a UID is goofy.  The EDG front 
end is a worked example demonstrating that you can use pointers as 
indices and still make PCH work by swizzling the pointers on the way 
in.  We really should do that; it would allow us to save memory and 
would make PCH more robust.)

>>If a front end creates two FUNCTION_DECLs or VAR_DECLs
>>that happen to have the same DECL_ASSEMBLER_NAME that's either a bug
>>or an intentional trick on the part of the front end: by the time
>>things get to the middle end there should be only one DECL for each
>>declared entity.
>>    
>>
>
>I don't believe that the frontends actually ensure this.  For instance,
>
>extern int x;
>extern int y asm ("x");
>
>will produce two DECLs that refer to the same integer.
>  
>
Yes -- but that's the user's issue.

 From the point of view of the compiler, we should still treat these as 
two separate variables.

You could even do
 
  extern float y asm ("x")

and I don't expect that we would present give you a warning.

I certainly don't think that should be an error -- I think it's 
perfectly valid input -- but of course the user must be very careful 
about type-based aliasing rules if playing such games.

The asm-specifier should have nothing to do with anything except what 
name is put out in the assembly file.

>Likewise, I believe with Zack's c-decl changes, I believe that it
>always returns the new DECL, which means that in code like:
>
>extern int foo();
>int bar(void) { return foo(1); }
>extern int foo(int);
>int baz(void) { return foo(2); }
>
>bar will reference one DECL of foo, and baz will reference a different
>one.  I think there are cases (perhaps even this example) where it'll
>do this even without Zack's changes.
>  
>
The point of Zack's changes was (in part) to eliminate having multiple 
copies of a FUNCTION_DECL for foo.

 I'm not 100% sure that this was fully completed in the current patch, 
but if not, it will be soon.

There should be just one FUNCTION_DECL for "foo", and by the time we 
reach the middle end, its type should be "int ()(int)".

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