[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