[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

Rafael Ávila de Espíndola rafael.espindola at gmail.com
Fri Jan 14 12:03:31 PST 2011

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

I do agree that we should allow them in both function and variable 
declarations or in none of them. If you have a use for one of them let 
me know I will allow them back.

> -Chris


More information about the cfe-commits mailing list