[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
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.
More information about the cfe-commits