Re: Lazy allocation of DECL_ASSEMBLER_NAME

[Mark Mitchell <mark at codesourcery dot com>]

> 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