[cfe-commits] r123192 - in /cfe/trunk: lib/CodeGen/CodeGenModule.cpp test/CodeGen/blocksignature.c test/CodeGen/const-init.c test/CodeGen/darwin-string-literals.c test/CodeGen/func-in-block.c test/CodeGen/predefined-expr.c test/CodeGen/string-literal-short-wstring.c test/CodeGen/string-literal.c test/CodeGenCXX/predefined-expr.cpp test/CodeGenObjC/predefined-expr.m

[John McCall]

On Jan 14, 2011, at 12:03 PM, Rafael Ávila de Espíndola wrote:

>>> BTW, should we allow unnamed_addr in function declarations?
>> 
>> It seems that unnamed_addr should be allowed on function definitions.  If we allow it on function declarations we should allow it on external globals as well.  Is there a use case for it?  It seems reasonable to allow it on declarations...
> 
> So, I went the other way and disallowed it for both function and 
> variable declarations.
> 
> The high level argument is that the address not being significant is not 
> a useful knowledge when all you have is a declaration. There is nothing 
> you can do to influence the address for example. This is unlike knowing 
> that a declaration is constant for example, since you can use the 
> constantness in optimizations.
> 
> Allowing them on declaration also means that we have to worry about 
> merging them during linking. What combinations should be valid?

Are you not already merging them during linking?  What happens when I have
two weak/linkonce definitions?  More generally, is this attribute a guarantee
that nobody *ever* cares about address significance, or just that the current
module doesn't?

Also, I wish this had been discussed on the ML even slightly before being
committed.

John.