返回元组时 GCC/Clang x86_64 C++ ABI 不匹配？

Question

在尝试to optimize return values on x86_64 时，我注意到了一件奇怪的事情。即，给定代码：

#include <cstdint>
#include <tuple>
#include <utility>

using namespace std;

constexpr uint64_t a = 1u;
constexpr uint64_t b = 2u;

pair<uint64_t, uint64_t> f() { return {a, b}; }
tuple<uint64_t, uint64_t> g() { return tuple<uint64_t, uint64_t>{a, b}; }

Clang 3.8 outputsf 的这个汇编代码：

movl $1, %eax
movl $2, %edx
retq

这是g：

movl $2, %eax
movl $1, %edx
retq

看起来最佳。但是，当compiled with GCC 6.1 时，虽然为f 生成的程序集与Clang 输出的相同，但为g 生成的程序集是：

movq %rdi, %rax
movq $2, (%rdi)
movq $1, 8(%rdi)
ret

看起来返回值的类型被 GCC 归类为 MEMORY，但被 Clang 归类为 INTEGER。我可以确认将 Clang 代码与 GCC 代码链接这样的代码会导致分段错误（Clang 调用 GCC 编译的 g() 写入到 %rdi 碰巧指向的任何地方）并返回无效值（GCC 调用 Clang 编译的 @ 987654337@)。哪个编译器有问题？

相关：

• G++ and clang++ incompatibility with standard library when building shared libraries?
• [cxx-abi-dev] Non-trivial move constructor

另见

• System V Application Binary Interface. AMD64 Architecture Processor Supplement. Draft Version 0.99.5

Answer 1

正如 davmac 的回答所示，libstdc++ std::tuple 可以简单地复制构造，但不能简单地移动构造。两个编译器在移动构造函数是否应该影响参数传递约定方面存在分歧。

您链接到的 C++ ABI 线程似乎解释了这种分歧： http://sourcerytools.com/pipermail/cxx-abi-dev/2016-February/002891.html

总之，Clang 完全实现了 ABI 规范所说的内容，但 G++ 实现了它应该说的内容，但实际上并未更新。

Answer 2

ABI 规定参数值是根据特定算法分类的。这里相关的是：

1. 如果聚合的大小超过单个八字节，则将每个单独分类。每八字节被初始化为 NO_CLASS 类。

2. 对对象的每个字段进行递归分类，以便始终考虑两个字段。根据八字节中字段的类别计算得到的类：

在这种情况下，每个字段（对于一个元组或一对）都是uint64_t 类型，因此占据了整个“八字节”。那么，每八字节中要考虑的“两个字段”是“NO_CLASS”（根据 3）和uint64_t 字段，它被归类为 INTEGER。

还有，与参数相关的传递：

如果 C++ 对象具有非平凡的复制构造函数或非平凡的析构函数，则它通过不可见的引用传递（对象在参数列表中被具有类 INTEGER 的指针替换）

不满足这些要求的对象必须有地址，因此需要在内存中，这就是存在上述要求的原因。返回值也是如此，尽管这似乎在规范中被省略了（可能是偶然的）。

最后还有：

(c) 如果聚合的大小超过两个八字节并且前八字节不是 SSE 或任何其他八字节不是 SSEUP，则整个参数 在内存中传递。

这显然不适用于这里；聚合的大小正好是两个八字节。

在返回值时，文本说：

1. 使用分类算法对返回类型进行分类

这意味着，如上所述，元组应归类为 INTEGER。那么：

1. 如果类是 INTEGER，则序列的下一个可用寄存器 %rax, %rdx 被使用。

这很清楚。

唯一仍然悬而未决的问题是这些类型是否是非平凡复制可构造/可破坏的。如上所述，这种类型的值不能在寄存器中传递或返回，即使规范似乎没有认识到返回值的问题。但是，我们可以很容易地证明元组和对都是可平凡复制构造和可平凡破坏的，使用以下程序：

测试程序：

#include <utility>
#include <cstdint>
#include <tuple>
#include <iostream>

using namespace std;

int main(int argc, char **argv)
{
    cout << "pair is trivial? : " << is_trivial<pair<uint64_t, uint64_t> >::value << endl;
    cout << "pair is trivially_copy_constructible? : " << is_trivially_copy_constructible<pair<uint64_t, uint64_t> >::value << endl;
    cout << "pair is standard_layout? : " << is_standard_layout<pair<uint64_t, uint64_t> >::value << endl;
    cout << "pair is pod? : " << is_pod<pair<uint64_t, uint64_t> >::value << endl;
    cout << "pair is trivially_destructable? : " << is_trivially_destructible<pair<uint64_t, uint64_t> >::value << endl;
    cout << "pair is trivially_move_constructible? : " << is_trivially_move_constructible<pair<uint64_t, uint64_t> >::value << endl;

    cout << "tuple is trivial? : " << is_trivial<tuple<uint64_t, uint64_t> >::value << endl;
    cout << "tuple is trivially_copy_constructible? : " << is_trivially_copy_constructible<tuple<uint64_t, uint64_t> >::value << endl;
    cout << "tuple is standard_layout? : " << is_standard_layout<tuple<uint64_t, uint64_t> >::value << endl;
    cout << "tuple is pod? : " << is_pod<tuple<uint64_t, uint64_t> >::value << endl;
    cout << "tuple is trivially_destructable? : " << is_trivially_destructible<tuple<uint64_t, uint64_t> >::value << endl;
    cout << "tuple is trivially_move_constructible? : " << is_trivially_move_constructible<tuple<uint64_t, uint64_t> >::value << endl;
    return 0;
}

使用 GCC 或 Clang 编译时的输出：

pair is trivial? : 0
pair is trivially_copy_constructible? : 1
pair is standard_layout? : 1
pair is pod? : 0
pair is trivially_destructable? : 1
pair is trivially_move_constructible? : 1
tuple is trivial? : 0
tuple is trivially_copy_constructible? : 1
tuple is standard_layout? : 0
tuple is pod? : 0
tuple is trivially_destructable? : 1
tuple is trivially_move_constructible? : 0

这意味着 GCC 弄错了。返回值应该在 %rax,%rdx 中传递。

（类型之间的主要显着差异是 pair 是标准布局并且可以简单地移动构造，而 tuple 不是，因此 GCC 可能总是通过例如指针）。