gcc 11.1 中 volatile 的非一致性优化

Question

在撰写有关编译器必须如何处理 volatile 的答案时，我相信我可能偶然发现了一个 gcc 错误，并希望有人在我报告它之前进行验证。

我写了一个这样的简单函数：

int foo (int a, int b, int c)
{
  b = a + 1;
  c = b + 1;
  a = c + 1;
  return a;
}

如果不进行优化，这会导致大量无意义的数据来回移动。通过优化，编译器只需获取存储a 的寄存器，然后添加 3 并返回该结果。说 x86 lea eax, [rdi+3] 和 ret。这是意料之中的，到目前为止一切顺利。

为了演示顺序和易失性访问，我将示例更改为：

int foo (int a, int b, int c)
{
  b = a + 1;
  c = *(volatile int*)&b + 1;
  a = c + 1;
  return a;
}

这里有一个对 b 内容的左值访问，它是 volatile 限定的，据我所知，绝对不允许编译器优化该访问¹⁾。从 gcc 4.1.2（可能更早）到 gcc 10.3，我得到了一致的行为（在 clang 中也是如此）。即使使用-O3，x86 机器代码也看起来像这样：

foo:
        add     edi, 1
        mov     DWORD PTR [rsp-4], edi
        mov     eax, DWORD PTR [rsp-4]
        add     eax, 2
        ret

然后我在 gcc 11.1 及更高版本上尝试相同，现在我得到：

foo:
        lea     eax, [rdi+3]
        ret

https://godbolt.org/z/e5x74z3Kb

ARM gcc 11.1 做了类似的事情。

这是编译器错误吗？

---

¹⁾ 参考：ISO/IEC 9899:2018 5.1.2.3，特别是 §2、§4 和 §6。

Answer 1

我听到一个编译器团队令人信服地争论（好吧，我差点睡着了，所以我得到了一个粗略的大纲），在外部作用域的字大小对象之外，易失性是一种毫无意义的装饰。此外，编译器提供了一些围绕无意义属性对象的传统行为，以方便使用遗留代码的人。这种解释是基于对 C 标准的荒谬简化，这比正确要好，它是 技术上正确的，是 alpha-geeks 的黄金标准。

Answer 2

根据 C18 5.1.2.3/6，对 volatile 对象的访问（严格按照抽象机的规则）是程序可观察行为的一部分，所有符合要求的实现都必须重现。在此上下文中，术语“访问”包括读取和写入。

C18 5.1.2.3/2 和 /4 强调 volatile 访问是需要的副作用，排除在允许实现避免产生不必要的副作用的规则之外。

我看到的 GCC 的唯一结果是一个论点，即尽管 (volatile int*)&b 是具有 volatile 限定类型的左值，但它可以证明它指定的对象 (b) 实际上不是“易失性对象” "，如果你按照它的声明去的话，确实不是这样。这与 GCC 11.2 对此版本的函数观察到的行为一致：

int foo (int a, int b, int c)
{
  volatile int bv = a + 1;
  c = bv + 1;
  a = c + 1;
  return a;
}

，它产生的程序集与旧版本的 GCC 对原始代码 (godbolt) 的程序集相同。

这是否构成不符合语言标准的错误尚不清楚，但 GCC 肯定阻碍了程序员的明显意图。

Answer 3

将地址传递给非内联函数使 GCC 尊重 volatile 转换，以便以后访问（可能更早，未检查）到函数 arg 或本地。 https://godbolt.org/z/cssveev7n

我复制了 c = 行，并且由于使用 GCC 主干的 volatile cast，asm 包含两个 b 负载。

void bar(void*);
int foo (int a, int b, int c)
{
  bar(&b);              // b's address has now "escaped" - potentially globally visible
  b = a + 1;

  c = *(volatile int*)&b + 1;
  c = *(volatile int*)&b + 1;   // both accesses present.
  a = c + 1;
  return a;
}

# GCC trunk -O3 -fverbose-asm
        call    bar     #
        mov     DWORD PTR [rsp+12], ebx   # b, tmp89
        mov     eax, DWORD PTR [rsp+12]   # _2, MEM[(volatile int *)&b]
        mov     eax, DWORD PTR [rsp+12]   # _3, MEM[(volatile int *)&b]
 ... 
        add     eax, 2
        ret

所以这似乎是无辜的，除非在一些微基准用例中；它不会使用像 the Linux kernel's READ_ONCE / WRITE_ONCE macros 这样的强制转换来破坏手工滚动的原子。

仍然可以说违反了 ISO C 规则，如果将普通的 int 别名为 volatile int 是合法的。如果不是，它只是 GCC 定义的行为，所以它取决于 GCC。我将其更多地作为数据点发布，而不是在问题的那个方面的任一方向的论点。