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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
