[PATCH] D158223: [clang] Add clang::unnamed_addr attribute that marks globals' address as not significant
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Aug 22 07:05:41 PDT 2023
aaron.ballman added a reviewer: erichkeane.
aaron.ballman added a comment.
Hmmm, so this is effectively making a per-declaration version of `-fmerge-all-constants`? (How does this interact with the `common` attribute, if at all?)
================
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.
+
----------------
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?
```
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D158223/new/
https://reviews.llvm.org/D158223
More information about the cfe-commits
mailing list