为何GCC使用__attribute__((__ms_abi__))时返回值规则与MSVC不一致？

这不是GCC的潜在bug，你观察到的调用约定差异来自两个明确的实现层面原因：一是__ms_abi__属性本身在32位x86平台的兼容范围有明确边界，二是测试所用的编译目标并非Windows原生平台，属性模拟不会对齐所有MSVC的实现细节。

ABI属性的实际作用范围 #

根据GCC《x86 Function Attributes》章节的定义，ms_abi和sysv_abi属性用于在同一程序内混合指定函数使用的调用约定：ms_abi对应微软ABI，sysv_abi对应System V ELF ABI，默认值随编译目标变化，Windows目标默认用微软ABI，其余目标默认用System V ABI。
但该属性的兼容程度在不同位宽的平台上存在明显区别：

• 在64位x86平台上，两个属性可以100%对齐对应ABI的完整规则，覆盖参数传递、寄存器保存责任、栈平衡、聚合类型返回等所有细节，可放心用于跨ABI互操作。
• 在32位x86平台上，微软从未公开过完整、严格的32位调用约定规范，大量细节属于MSVC编译器的内部实现约定，因此ms_abi属性仅保证核心调用规则和微软ABI一致，包括参数入栈顺序、栈平衡责任、调用过程中的寄存器保存/易失规则、标量类型（整数、指针、浮点数）的传递与返回规则，不会对齐所有MSVC的专属实现细节。

测试结果差异的具体原因 #

测试所用代码如下：

#include <assert.h>

#ifdef _MSC_VER
#define MS_ABI
#else
#define MS_ABI __attribute__((__ms_abi__))
#endif

typedef struct {
    void *x, *y;
} foo;

static_assert(sizeof(foo) == 8, "foo must be an 8-byte structure");

foo MS_ABI f(void *x, void *y) {
    foo rv;
    rv.x = x;
    rv.y = y;
    return rv;
}

观察到的汇编生成结果差异，完全符合GCC的实现逻辑：

• 使用gcc -O2 -m32（Linux i386非Windows目标）编译时，即便给函数加了ms_abi属性，GCC依然会沿用System V ABI的聚合类型返回规则：所有大小超过4字节的结构体、联合体，都通过函数接收的第一个隐藏参数（指向返回值内存地址的指针）返回，因此生成的汇编会直接将EAX（存放隐藏指针的寄存器）作为写入地址，把两个参数写入对应内存后直接返回，不会使用EDX:EAX寄存器对返回8字节结构体。
• 使用MSVC cl /O2编译时，生成的代码符合MSVC内部实现规则：8字节大小的POD结构体通过EDX:EAX寄存器对直接返回，不需要隐藏指针参数，因此汇编逻辑是把两个入参分别存入EAX、EDX后直接返回。

即便是原生32位Windows目标的MinGW GCC，对于8字节结构体的返回规则也和MSVC存在细微差异：只有当结构体成员类型完全一致、满足特定对齐要求时，才会使用EDX:EAX寄存器对返回，其余场景依然走隐藏指针逻辑。

正确使用建议 #

• 64位平台下跨ABI互操作可以直接使用__ms_abi__/__sysv_abi__属性，GCC的实现完全符合公开ABI规范，不会出现兼容问题。
• 32位平台下如果需要和MSVC编译的二进制互操作，不要在Linux ELF目标上靠__ms_abi__属性模拟兼容，必须使用i686-w64-mingw32目标的GCC编译对应代码；为了彻底规避聚合类型传递/返回的兼容风险，可以把结构体返回值改写为输出指针参数的形式，从代码层面统一调用约定。

内容的提问来源于stack exchange，提问作者Joseph Sible-Reinstate Monica