[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
rjmccall at apple.com
Fri Jan 14 12:41:01 PST 2011
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
Also, I wish this had been discussed on the ML even slightly before being
More information about the cfe-commits