从函数返回结构时可能出现 GCC 错误

Question

我相信我在实施 O'Neill 的 PCG PRNG 时在 GCC 中发现了一个错误。 (Initial code on Godbolt's Compiler Explorer)

在将oldstate 乘以MULTIPLIER 之后（结果存储在rdi 中），GCC 不会将该结果添加到INCREMENT，而是将INCREMENT 移动到rdx，然后将其用作返回值rand32_ret.state

一个最小的可重现示例 (Compiler Explorer)：

#include <stdint.h>

struct retstruct {
    uint32_t a;
    uint64_t b;
};

struct retstruct fn(uint64_t input)
{
    struct retstruct ret;

    ret.a = 0;
    ret.b = input * 11111111111 + 111111111111;

    return ret;
}

生成的程序集（GCC 9.2、x86_64、-O3）：

fn:
  movabs rdx, 11111111111     # multiplier constant (doesn't fit in imm32)
  xor eax, eax                # ret.a = 0
  imul rdi, rdx
  movabs rdx, 111111111111    # add constant; one more 1 than multiplier
     # missing   add rdx, rdi   # ret.b=... that we get with clang or older gcc
  ret
# returns RDX:RAX = constant 111111111111 : 0
# independent of input RDI, and not using the imul result it just computed

有趣的是，修改结构以将 uint64_t 作为第一个成员 produces correct code，changing both members to be uint64_t 也是如此

x86-64 System V 确实在 RDX:RAX 中返回小于 16 字节的结构，当它们可以简单地复制时。在这种情况下，第二个成员在 RDX 中，因为 RAX 的高半部分是对齐的填充，或者当.a 是更窄的类型时，.b。 （sizeof(retstruct) 无论哪种方式都是 16；我们没有使用 __attribute__((packed)) 所以它尊重 alignof(uint64_t) = 8。）

此代码是否包含任何未定义的行为，会允许 GCC 发出“不正确”的程序集？

如果没有，这应该在https://gcc.gnu.org/bugzilla/ 上报告

Answer 1

此问题已在 trunk/master 上修复。

这里是relevant commit。

这是a patch 来解决这个问题。

根据补丁中的评论，reload_combine_recognize_pattern 函数正在尝试调整 USE insns。

Answer 2

此代码是否包含任何未定义的行为会允许 GCC 发出“不正确”的程序集？

问题中提供的代码的行为根据 C99 和更高版本的 C 语言标准进行了很好的定义。特别是，C 允许函数不受限制地返回结构值。

Answer 3

我在这里没有看到任何 UB；你的类型是无符号的，所以有符号溢出 UB 是不可能的，而且没有什么奇怪的。 （即使已签名，它也必须为不会导致溢出 UB 的输入产生正确的输出，例如 rdi=1）。它也被 GCC 的 C++ 前端所破坏。

此外，GCC8.2 将其编译为correctly for AArch64 and RISC-V（在使用movk 构造常量后编译为madd 指令，或在加载常量后使用RISC-V mul 和add）。如果 GCC 找到的是 UB，我们通常希望它能够找到它并破坏其他 ISA 的代码，至少是具有相似类型宽度和寄存器宽度的代码。

Clang 也能正确编译。

这似乎是从 GCC 5 到 6 的回归； GCC5.4 编译正确，6.1 及更高版本不正确。 (Godbolt)。

您可以使用问题中的 MCVE 在GCC's bugzilla 上报告此问题。

看起来这确实是 x86-64 System V 结构返回处理中的一个错误，可能是包含填充的结构。这可以解释为什么它在内联时以及在将 a 扩大到uint64_t（避免填充）。