[PATCH] D122874: [clang] Add GNU spelling for no_unqiue_address attribute

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Apr 5 13:17:39 PDT 2022

aaron.ballman added a comment.

In D122874#3422489 <https://reviews.llvm.org/D122874#3422489>, @philnik wrote:

> In D122874#3422263 <https://reviews.llvm.org/D122874#3422263>, @aaron.ballman wrote:
>> I'm not opposed, but this does muddy the waters about the target-specific nature of the attribute. Currently, the semantic attribute cannot be used outside of Itanium ABI targets, so it doesn't work on Windows (and we don't want it to -- Microsoft hasn't picked their ABI for the standard attribute and we want to avoid ABI breaks). But should we pick an ABI for the GNU attribute on Windows and just assume that Microsoft gets no say in the ABI for that because it's not their vendor extension? Or, if we disallow the GNU spelling on Windows because we want it to match the ABI of the standard attribute, does it actually help libc++ to expose the GNU spelling?
>> Also, the change is missing test coverage and a release note.
> The best option for libc++ would probably be having the same ABI for `__atrribute__((no_unique_address))` and `[[msvc::no_unique_address]]` on Windows.

And if `[[msvc::no_unique_address]]` and `[[no_unique_address]]` (when eventually implemented) in MSVC have a different ABI impact, will we will leave `__attribute__((no_unique_address))` alone so it won't break ABI?

> We already have code that uses `[[no_unique_address]]`/`[[msvc::no_unique_address]]` but clang-cl currently supports none of them, so there will be an ABI break if we declare these things stable before clang-cl has implemented one of these (although we don't //really// care about ABI stability on Windows AFAICT).

I believe we care about ABI stability, even on Windows. At the very least, I've never heard that the community does not care about ABI stability on Windows.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list