C++20 [[no_unique_address]] 不适用于 clang 的 win32-coff 目标

Hum*_*ler 4 c++ coff llvm clang c++20

在使用clang-13C++20 时,我注意到x86_64-pc-win32-coff交叉编译目标似乎完全拒绝该[[no_unique_address]]属性。我测试过的其他目标也支持此属性。

考虑这个最小的例子:

struct bar {};

struct foo {
    [[no_unique_address]] bar b;
};
Run Code Online (Sandbox Code Playgroud)

当用 编译时-target=x86_64-pc-win32-coff,会产生

<source>:4:7: warning: unknown attribute 'no_unique_address' ignored [-Wunknown-attributes]
    [[no_unique_address]] bar b;
      ^~~~~~~~~~~~~~~~~
1 warning generated.
Run Code Online (Sandbox Code Playgroud)

Live Example

不同目标拒绝属性是一个已知问题,还是这只是底层交叉编译目标的产物?我知道 MSVC 历史上没有进行空基优化并保留它是为了 ABI 兼容性;这是具有这种兼容性的产品吗?

怀疑这可能是目标中的一个错误,因为它不完全满足 C++20 规范,但我不确定是否存在务实或已知的原因来解释为什么此属性在其他交叉时被彻底拒绝。编译目标似乎工作没有问题。

Nic*_*las 11

no_unique_address其主要支持必须在 ABI 级别处理。Itanium ABI 和 Microsoft 事实上的 ABI(又名:无论 MSVC 做什么)都支持no_unique_address......有点。

看吧,微软目前并不愿意造成 ABI 中断。由于该属性在 C++17 构建下不执行任何操作,因此这意味着为 C++17 和 C++20 编译相同的标头可能会导致 ODR 违规。

因此,他们推迟全面实施该属性。他们已将代码准备好进入编译器(您甚至可以使用 MSVC 特定的属性msvc::no_unique_address来获得相同的效果)。但在他们进行 ABI 突破之前,他们并不打算支持它。

因此,Clang 似乎在这方面追随了微软的脚步。