序列点之间能否多次读取volatile变量？

Question

我正在制作自己的 C 编译器，以尝试了解有关 C 的尽可能多的细节。我现在正试图准确了解volatile对象的工作原理。

令人困惑的是，代码中的每个读取访问都必须严格执行（C11，6.7.3p7）：

具有 volatile 限定类型的 object 可能会以实现未知的方式进行修改或具有其他未知的副作用。 因此，任何引用此类 object 的表达式都应严格按照抽象机的规则进行评估，如 5.1.2.3 中所述。 此外，在每个序列点上，最后存储在 object 中的值应与抽象机规定的值一致，除非被前面提到的未知因素修改。134）构成对具有 volatile 限定类型的 object 的访问的是实现-定义。

示例：in a = volatile_var - volatile_var; ，必须读取 volatile 变量两次，因此编译器无法优化为a = 0;

同时，序列点之间的求值顺序未定（C11，6.5p3）：

运算符和操作数的分组由语法指示。 除非稍后指定，否则子表达式的副作用和值计算是无序的。

示例：在b = (c + d) - (e + f)中，加法计算的顺序未指定，因为它们未排序。

但是对未排序对象的评估会产生副作用（例如使用volatile ），行为是未定义的（C11，6.5p2）：

如果相对于同一标量 object 的不同副作用或使用同一标量 object 的值的值计算，标量 object 的副作用未排序，则行为未定义。 如果一个表达式的子表达式有多个允许的排序，并且在任何排序中出现这种未排序的副作用，则行为是未定义的。

这是否意味着像x = volatile_var - (volatile_var + volatile_var)这样的表达式是未定义的？ 如果发生这种情况，我的编译器是否应该发出警告？

我试着看看 CLANG 和 GCC 做了什么。 既不抛出错误也不抛出警告。 输出的 asm 显示变量不是按执行顺序读取的，而是从左到右，如下面的 asm risc-v asm 所示：

const int volatile thingy = 0;
int main()
{
    int new_thing = thingy - (thingy + thingy);
    return new_thing;
}

main:
        lui     a4,%hi(thingy)
        lw      a0,%lo(thingy)(a4)
        lw      a5,%lo(thingy)(a4)
        lw      a4,%lo(thingy)(a4)
        add     a5,a5,a4
        sub     a0,a0,a5
        ret

编辑：我不是在问“为什么编译器接受它”，我是在问“如果我们严格遵循 C11 标准，它是否是未定义的行为”。 该标准似乎 state 它是未定义的行为，但我需要更精确才能正确解释它

Answer 1

从字面上看（ISO 9899:2018）标准，那就是未定义的行为。

C17 5.1.2.3/2 - 副作用的定义：

访问volatile object、修改 object、修改文件或调用 function 执行任何这些操作都是副作用

C17 6.5/2 - 操作数的排序：

如果标量 object 上的副作用相对于同一标量 object 上的不同副作用或使用同一标量 object 的值的值计算是未排序的，则行为未定义。 如果一个表达式的子表达式有多个允许的排序，并且在任何排序中出现这种未排序的副作用，则行为是未定义的。

因此，当从字面上阅读标准时， volatile_var - volatile_var绝对是未定义的行为。 实际上连续两次 UB，因为引用的两个句子都适用。

---

另请注意，此文本在 C11 中发生了很大变化。 以前C99说，6.5/2：

在前一个和下一个序列点之间，object 的存储值最多应通过表达式的评估修改一次。 此外，先验值应只读以确定要存储的值。

也就是说，该行为之前在 C99 中未指定（未指定求值顺序），但由于 C11 中的更改而变得未定义。

---

话虽这么说，除了根据需要重新排序评估之外，编译器实际上没有任何理由用这个表达式做疯狂和疯狂的事情，因为给定volatile没有太多可以优化的东西。

作为实现的质量，主流编译器似乎保持了 C99 之前的“仅仅未指定”行为。

Answer 2

根据 C11，这是未定义的行为。

根据5.1.2.3 Program execution ，第 2 段（粗体）：

访问 volatile object 、修改 object 、修改文件或调用 function 执行任何这些操作都是副作用......

和6.5 Expressions ，第 2 段（同样，加粗我的）：

如果标量 object 的副作用相对于同一标量 object 的不同副作用或使用同一标量 object 的值的值计算是未排序的，则行为是未定义的。

请注意，由于这是您的编译器，您可以根据需要自由定义行为。

Answer 3

正如其他答案所指出的那样，访问volatile限定变量是一种副作用，副作用很有趣，序列点之间具有多个副作用特别有趣，并且具有影响序列点之间相同 object 的多个副作用是不明确的。

作为未定义的方式/原因的示例，请考虑以下（错误的）代码，用于从输入 stream ifs读取两字节大端值：

uint16_t val = (getc(ifs) << 8) | getc(ifs);     /* WRONG */

此代码假设（即，为了实现大端）两个getc调用按从左到右的顺序发生，但当然这根本不能保证，这就是此代码错误的原因。

现在， volatile限定符的用途之一是输入寄存器。 所以如果你有一个 volatile 变量

volatile uint8_t inputreg;

如果每次读取它时，都会在某个设备上收到下一个字节——也就是说，如果仅仅访问变量inputreg就像在 stream 上调用getc() ——那么你可以编写以下代码：

uint16_t val = (inputreg << 8) | inputreg;       /* ALSO WRONG */

它和上面的getc()代码一样错误。

Answer 4

该标准没有比“未定义行为”更具体的术语来描述应该在某些实现中明确定义的行为，甚至是绝大多数实现，但根据实现定义的标准，在其他实现中可能表现出不可预测的行为。 如果有的话，标准 go 的作者特意避免谈论此类行为。

该术语还用作包罗万象的情况，其中潜在有用的优化可能会在某些情况下明显影响程序行为，以确保此类优化不会影响任何定义情况下的程序行为。

该标准指定 volatile 限定访问的语义是“实现定义的”，并且如果在序列点之间发生不止一个此类访问，则在某些平台上可以观察到某些涉及volatile限定访问的优化。 举个简单的例子，一些平台有读-修改-写操作，其语义可能明显不同于离散的读、修改和写操作。 如果程序员要写：

void x(int volatile *dest, int volatile *src)
{
  *dest = *src | 1;
}

并且两个指针相等，这样的 function 的行为可能取决于编译器是否识别出指针相等并用组合的读-修改-写替换离散的读和写操作。

可以肯定的是，在大多数情况下，这种区别不太可能重要，尤其是在 object 被读取两次的情况下。 N.尽管如此，该标准并未尝试区分此类优化实际上会影响程序行为的情况，更不用说它们会以任何实际重要的方式影响程序行为的情况，以及无法检测此类影响的情况优化。 短语“不可移植或错误”排除了在目标平台上不可移植但正确的构造的概念会导致一个有趣的讽刺，即编译器优化（如读-修改-写合并）在任何“正确”的程序。

Answer 5

具有未定义行为的程序不需要诊断，除非特别提及。 所以接受这段代码并没有错。

通常，不可能知道同一易失性存储是否在序列点之间被多次访问（考虑一个 function 采用两个volatile int*参数，没有restrict ，作为无法分析的最简单示例）。

也就是说，当您能够检测到有问题的情况时，用户可能会发现它有帮助，所以我鼓励您努力进行诊断。

Answer 6

IMO 这是合法的，但非常糟糕。

    int new_thing = thingy - (thingy + thingy);

允许在一个表达式中多次使用volatile变量，并且不需要警告。 但是从程序员的角度来看，这是一行非常糟糕的代码。

这是否意味着像 x = volatile_var - (volatile_var + volatile_var) 这样的表达式是未定义的？ 如果发生这种情况，我的编译器是否应该抛出错误？

没有，因为 C 标准没有说明必须如何对这些读取进行排序。 它留给实现。 我所知道的所有实现都是最简单的方法，就像这个例子中的那样： https://godbolt.org/z/99498141d

Answer 7

我认为这取决于关于波动率字符串的编译顺序，因为它与编译顺序相关，随着变量的出现与 (C/B) 成反比。 您的体验可能会有所不同。