[PATCH] D158223: [clang] Add clang::unnamed_addr attribute that marks globals' address as not significant

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added inline comments.


================
Comment at: clang/include/clang/Basic/AttrDocs.td:1416-1417
+not significant. This allows global constants with the same contents to be
+merged. This can break global pointer identity, i.e. two different globals have
+the same address.
+
----------------
aaron.ballman wrote:
> What happens for tentative definitions where the value isn't known? e.g.,
> ```
> [[clang::unnamed_addr]] int i1, i2;
> ```
> 
> What happens if the types are similar but not the same?
> ```
> [[clang::unnamed_addr]] signed int i1 = 32;
> [[clang::unnamed_addr]] unsigned int i2 = 32;
> ```
> 
> Should we diagnose taking the address of such an attributed variable so users have some hope of spotting the non-conforming situations?
> 
> Does this attribute have impacts across translation unit boundaries (perhaps only when doing LTO) or only within a single TU?
> 
> What does this attribute do in C++ in the presence of constructors and destructors? e.g.,
> ```
> struct S {
>   S();
>   ~S();
> };
> 
> [[clang::unnamed_addr]] S s1, s2; // Are these merged and there's only one ctor/dtor call?
> ```
globals are only mergeable if they're known to be constant and have the same value/size. this can be done at compile time only if the optimizer can see the constant values, or at link time

so nothing would happen in any of the cases you've given.

but yeah that does imply that we should warn when the attribute is used on non const, non-POD globals. I'll update this patch to do that

as mentioned in the description, we actually do want to take the address of these globals for table-driven parsing, but we don't care about identity equality


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158223/new/

https://reviews.llvm.org/D158223