[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

[Chris Lattner]

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.

Yep, I saw that fly by.

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

I agree that it isn't very useful, but it does make sense.  The C++ frontend knows that the external rtti info for "int" is unnamed_addr, for example.

> Allowing them on declaration also means that we have to worry about merging them during linking. What combinations should be valid?

Merge to the value with the least information.  If one say it is named and one says it is unnamed, be pessimistic and assume named.  Since the two translation units could be written in different languages (one may not have pointer comparison for example) we have to do this.

-Chris