如何制作不会被优化的无限空循环？

C11标准似乎暗示不应优化具有恒定控制表达式的迭代语句。我从这个答案中获取建议，该答案特别引用了标准草案的6.8.5节：

该实现可以假定其控制表达式不是常量表达式...的迭代语句终止。

在该答案中，它提到while(1) ;不应对循环进行优化。

那么...为什么Clang / LLVM优化了下面的循环（与编译cc -O2 -std=c11 test.c -o test）？

#include <stdio.h>

static void die() {
    while(1)
        ;
}

int main() {
    printf("begin\n");
    die();
    printf("unreachable\n");
}

在我的机器上，此打印输出begin，然后在一条非法指令（ud2位于后面的陷阱die()）中崩溃。在godbolt上，我们可以看到调用之后什么也没有产生puts。

让Clang在下面输出无限循环是一件非常困难的任务-O2-虽然我可以重复测试一个volatile变量，但该变量涉及不需要的内存读取。如果我做这样的事情：

#include <stdio.h>

static void die() {
    while(1)
        ;
}

int main() {
    printf("begin\n");
    volatile int x = 1;
    if(x)
        die();
    printf("unreachable\n");
}

...打印begin出来的unreachable是无穷循环，仿佛永无止境。

如何在启用优化的情况下让Clang输出正确的，无内存访问的无限循环？

C11标准是6.8.5 / 6：

不执行输入/输出操作，不访问易失对象，并且在其主体，控制表达式中或者（对于for的情况下）不执行同步或原子操作的迭代语句，其控制表达式不是常量表达式（^156）。语句）其表达式3，可能被实现假定为终止。^157）

这两个脚注不是规范性的，但是提供了有用的信息：

156）被省略的控制表达式被非零常量替换，这是一个常量表达式。

157）这旨在允许编译器转换，例如即使无法证明终止也可以删除空循环。

在您的情况下，while(1)是一个非常清晰的常量表达式，因此实现可能不会假定它终止。由于“永远”的循环是常见的编程结构，因此这种实现将无可避免地被破坏。

据我所知，循环后“无法访问的代码”发生了什么，尚不清楚。但是，c确实确实表现得很奇怪。将机器代码与gcc（x86）进行比较：

gcc 9.2 -O3 -std=c11 -pedantic-errors

.LC0:
        .string "begin"
main:
        sub     rsp, 8
        mov     edi, OFFSET FLAT:.LC0
        call    puts
.L2:
        jmp     .L2

lang 9.0.0 -O3 -std=c11 -pedantic-errors

main:                                   # @main
        push    rax
        mov     edi, offset .Lstr
        call    puts
.Lstr:
        .asciz  "begin"

gcc生成了循环，clang刚好进入树林，并以错误255退出。

我倾向于这是不兼容的clang行为。因为我试图像这样进一步扩展您的示例：

#include <stdio.h>
#include <setjmp.h>

static _Noreturn void die() {
    while(1)
        ;
}

int main(void) {
    jmp_buf buf;
    _Bool first = !setjmp(buf);

    printf("begin\n");
    if(first)
    {
      die();
      longjmp(buf, 1);
    }
    printf("unreachable\n");
}

我添加了C11 _Noreturn试图进一步帮助编译器。应该清楚的是，仅从该关键字开始，该函数就会挂断。

setjmp将在首次执行时返回0，因此该程序应将其粉碎while(1)并停在那里，仅打印“ begin”（假定\ n刷新stdout）。这发生在gcc中。

如果只是删除了循环，则应打印“ begin”两次，然后打印“ unreachable”。但是，在clang（godbolt）上，它先打印“ begin” 1次，然后“ unreachable”，然后返回退出代码0。无论您如何输入，这都是很错误的。

我在这里找不到主张未定义行为的情况，因此我认为这是clang中的错误。无论如何，这种行为会使clang 100％对于嵌入式系统之类的程序毫无用处，在嵌入式系统中，您仅必须能够依靠永久循环挂起程序（在等待看门狗时）。

您需要插入一个可能引起副作用的表达式。

最简单的解决方案：

static void die() {
    while(1)
       __asm("");
}

Godbolt链接

其他答案已经涵盖了使Clang发出无限循环，内联汇编语言或其他副作用的方法。我只想确认这确实是一个编译器错误。具体来说，这是一个长期存在的LLVM错误 -它将C ++概念“所有循环都必须终止，而没有副作用”必须应用到不应该使用的语言，例如C。

例如，Rust编程语言还允许无限循环，并使用LLVM作为后端，并且它具有相同的问题。

在短期内，LLVM似乎将继续假设“必须终止所有没有副作用的循环”。对于允许无限循环的任何语言，LLVM都希望前端将llvm.sideeffect操作码插入此类循环中。这正是Rust计划要做的，因此Clang（在编译C代码时）可能也必须这样做。

这是一个Clang错误

...当内联包含无限循环的函数时。当while(1);直接出现在main中时，行为是不同的，这对我来说很臭。

有关摘要和链接，请参见@Arnavion的答案。该答案的其余部分是在我确认这是一个错误之前编写的，更不用说一个已知的错误了。

要回答标题问题：如何制作不会被优化的无限空循环？？-
创建die()宏而不是函数，以解决Clang 3.9及更高版本中的此错误。（早期的Clang版本要么保留循环，要么call使用无限循环将其发送到函数的非内联版本。）即使该print;while(1);print;函数内联到其调用方（Godbolt）中，这似乎也是安全的。 -std=gnu11vs. -std=gnu99没有任何改变。

如果您只关心GNU C，则循环内的P__J____asm__("");也可以使用，并且不会影响任何了解它的编译器的周围代码的优化。GNU C Basic asm语句是隐式的volatile，因此这被视为可见的副作用，必须像在C抽象机中那样“执行”多次。（是的，Clang实现了C的GNU方言，如GCC手册所记录。）

有人认为，优化空的无限循环可能是合法的。我不同意¹，但是即使我们接受，Clang在循环不可到达之后承担语句，并让执行从函数的末尾落入下一个函数或垃圾中，这也是不合法的解码为随机指令。

（这符合Clang ++的标准（但仍然不是很有用）；没有任何副作用的无限循环在C ++中是UB，但在C中不是UB。is
（1）; C？ UB中的未定义行为使编译器基本上可以发出任何东西对于肯定会遇到UB的执行路径上的代码，asm循环中的语句将避免使用UB for C ++。但实际上，Clang编译为C ++不会删除常量表达式无限空循环，除非在内联时与编译为C。）

手动内联while(1);更改Clang的编译方式：asm中存在无限循环。 这就是我们从规则律师POV所期望的。

#include <stdio.h>
int main() {
    printf("begin\n");
    while(1);
    //infloop_nonconst(1);
    //infloop();
    printf("unreachable\n");
}

在Godbolt编译器资源管理器上，将Clang 9.0 -O3编译为C（-xc）用于x86-64：

main:                                   # @main
        push    rax                       # re-align the stack by 16
        mov     edi, offset .Lstr         # non-PIE executable can use 32-bit absolute addresses
        call    puts
.LBB3_1:                                # =>This Inner Loop Header: Depth=1
        jmp     .LBB3_1                   # infinite loop


.section .rodata
 ...
.Lstr:
        .asciz  "begin"

具有相同选项的相同编译器将首先编译到的a main，然后在此之后停止发出指令。因此，正如我所说，执行只是落在函数的末尾，然后进入下一个函数（但堆栈未对齐函数入口，因此它甚至不是有效的尾调用）。infloop() { while(1); }putsmain

有效的选择是

• 发出label: jmp label无限循环
• 或（如果我们接受无限循环可以删除的话）会发出另一个调用以打印第二个字符串，然后return 0从发出main。

对于C11实现，崩溃或以其他方式继续而没有打印“ unreachable”显然不行，除非我没有注意到UB。

脚注1：

记录下来，我同意@Lundin的回答，该回答引用了标准，以证明C11不允许假设常量表达式无限循环的终止，即使它们为空（没有I / O，volatile，同步或其他）可见的副作用）。

这是一组条件，可以将循环编译为正常CPU 的空asm循环。（即使源代码中的主体不为空，在循环运行时，没有数据争用UB，其他线程或信号处理程序也看不到变量的赋值。因此，如果需要的话，一致的实现可以删除此类循环主体然后留下了是否可以删除循环本身的问题。ISOC11明确表示否。）

鉴于C11指出了这种情况，即实现无法假定循环终止（并且它不是UB），因此显然他们希望循环在运行时出现。以执行模型为目标的CPU的实现无法在有限时间内完成无限量工作的实现，没有理由删除空的常数无限循环。甚至一般来说，确切的用语是关于是否可以“假定终止”。如果循环无法终止，则意味着无论您对数学和无穷大采用什么参数，以及在某个假设的机器上进行无数次工作需要花费多长时间，都无法访问更高版本的代码。

除此之外，Clang不仅是符合ISO C的DeathStation 9000，它还旨在用于现实世界的低级系统编程，包括内核和嵌入式内容。 因此，无论您是否接受有关允许删除的C11的论点while(1);，Clang都不愿意实际执行。如果您编写while(1);，那可能不是偶然的。删除意外终止的无限循环（使用运行时变量控制表达式）可能会很有用，并且编译器可以这样做。

很少旋转直到下一个中​​断是很少见的，但是如果用C编写，那肯定是您期望发生的事情。（并且在GCC和Clang 中会发生什么，除了当无限循环位于包装函数内部时的Clang之外）。

例如，在原始OS内核中，当调度程序没有要运行的任务时，它可能会运行空闲任务。的第一个实现可能是while(1);。

或者对于没有任何节能空闲功能的硬件，这可能是唯一的实现。（直到2000年代初，我认为这在x86上并不少见。尽管该hlt指令确实存在，但IDK会在CPU开始具有低功耗空闲状态之前节省大量电量。）

仅作记录，Clang也有以下不良行为goto：

static void die() {
nasty:
    goto nasty;
}

int main() {
    int x; printf("begin\n");
    die();
    printf("unreachable\n");
}

它产生与问题相同的输出，即：

main: # @main
  push rax
  mov edi, offset .Lstr
  call puts
.Lstr:
  .asciz "begin"

我看到看不到C11允许的任何读取方式，它只说：

6.8.6.1（2）goto语句导致无条件跳转到包含在封装函数中的命名标签为前缀的语句。

至于goto是不是“循环语句”（6.8.5名单while，do以及for“终止假定的”放纵申请，但是你想读他们）对特殊罢了。

每个原始问题的Godbolt链接编译器是x86-64 Clang 9.0.0，标志是 -g -o output.s -mllvm --x86-asm-syntax=intel -S --gcc-toolchain=/opt/compiler-explorer/gcc-9.2.0 -fcolor-diagnostics -fno-crash-diagnostics -O2 -std=c11 example.c

使用x86-64 GCC 9.2之类的其他工具，您将获得非常完美的效果：

.LC0:
  .string "begin"
main:
  sub rsp, 8
  mov edi, OFFSET FLAT:.LC0
  call puts
.L2:
  jmp .L2

标志： -g -o output.s -masm=intel -S -fdiagnostics-color=always -O2 -std=c11 example.c

我将扮演魔鬼的拥护者，并争辩说该标准并未明确禁止编译器优化无限循环。

不执行输入/输出操作，不访问易失对象，并且在其主体，控制表达式中或者（对于语句）其表达式3，可能被实现假定为终止（157）

让我们来分析一下。可以假定满足某些条件的迭代语句终止：

if (satisfiesCriteriaForTerminatingEh(a_loop)) 
    if (whatever_reason_or_just_because_you_feel_like_it)
         assumeTerminates(a_loop);

这没有说明如果不满足标准会发生什么，并且只要观察到该标准的其他规则，就不会明确禁止循环甚至终止。

do { } while(0)还是while(0){}在所有不满足标准的迭代语句（循环）之后，编译器只是一时兴起就假定它们终止了，但是显然它们确实终止了。

但是编译器可以优化while(1){}吗？

5.1.2.3p4说：

在抽象机中，所有表达式均按语义指定的方式求值。如果实际实现可以推断出未使用表达式的值并且没有产生所需的副作用（包括由调用函数或访问易失性对象引起的副作用），则无需评估表达式的一部分。

这里提到的是表达式，而不是语句，因此并不是100％令人信服，但它确实允许以下调用：

void loop(void){ loop(); }

int main()
{
    loop();
}

被跳过。有趣的是，clang会跳过它，而gcc不会。

我已经确信这只是一个普通的老错误。由于先前的某些原因，我将我的测试留在下面，尤其是参考标准委员会中的讨论。

我认为这是未定义的行为（请参见结尾），Clang仅有一个实现。GCC确实按照您的期望工作，仅优化了unreachable打印语句，但退出了循环。当组合内联并确定它可以对循环做什么时，Clang如何奇怪地做出决策。

该行为特别怪异-它删除了最终的打印内容，因此“看到”了无限循环，但随后也摆脱了循环。

据我所知，情况甚至更糟。删除内联，我们得到：

die: # @die
.LBB0_1: # =>This Inner Loop Header: Depth=1
  jmp .LBB0_1
main: # @main
  push rax
  mov edi, offset .Lstr
  call puts
.Lstr:
  .asciz "begin"

这样就创建了函数，并优化了调用。这比预期的更具弹性：

#include <stdio.h>

void die(int x) {
    while(x);
}

int main() {
    printf("begin\n");
    die(1);
    printf("unreachable\n");
}

导致该函数的装配非最佳，但是再次优化了函数调用！甚至更糟：

void die(x) {
    while(x++);
}

int main() {
    printf("begin\n");
    die(1);
    printf("unreachable\n");
}

我做了一些其他的测试，添加了一个局部变量并增加了它，传递了一个指针，使用了一个goto等。这时我会放弃。如果必须使用clang

static void die() {
    int volatile x = 1;
    while(x);
}

做这份工作。它很费力地优化（显然），并留在多余的final中printf。至少程序不会停止。也许毕竟是海湾合作委员会？

附录

在与David讨论之后，我得出的标准不是说“如果条件恒定，则您可能不会认为循环终止”。因此，根据标准，没有可观察到的行为（如标准中所定义），我只为保持一致性而争论-如果编译器由于假定循环终止而正在优化循环，则不应优化以下语句。

eck 如果我没看错的话， n1528会将其作为未定义的行为。特别

这样做的主要问题是它允许代码在可能终止的循环中移动

从这里开始，我认为它只能演变成关于我们想要什么（期望？）而不是允许的讨论。

看来这是Clang编译器中的错误。如果该die()函数没有任何强制要成为静态函数，请废除static并将其制成inline：

#include <stdio.h>

inline void die(void) {
    while(1)
        ;
}

int main(void) {
    printf("begin\n");
    die();
    printf("unreachable\n");
}

使用Clang编译器进行编译时，它可以按预期工作，并且可移植。

编译器资源管理器（godbolt.org）-clang 9.0.0-O3 -std=c11 -pedantic-errors

main:                                   # @main
        push    rax
        mov     edi, offset .Lstr
        call    puts
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
        jmp     .LBB0_1
.Lstr:
        .asciz  "begin"

以下内容似乎对我有用：

#include <stdio.h>

__attribute__ ((optnone))
static void die(void) {
    while (1) ;
}

int main(void) {
    printf("begin\n");
    die();
    printf("unreachable\n");
}

在godbolt

明确告诉Clang不要优化一个函数会导致按预期方式发出无限循环。希望有一种方法可以有选择地禁用特定的优化，而不仅仅是像这样将其全部关闭。但是Clang仍然拒绝为第二个发出代码printf。为了强制这样做，我不得不进一步修改其中的代码main以：

volatile int x = 0;
if (x == 0)
    die();

看来您需要禁用无限循环功能的优化，然后确保有条件地调用无限循环。在现实世界中，后者几乎总是如此。

符合标准的实现可能并且许多实际的方法会对程序执行的时间或执行的指令施加任意限制，并且如果违反了这些限制或在“按条件”规则下以任意方式运行-如果确定不可避免地会受到侵犯。前提是实现可以成功处理至少一个名义上执行N1570 5.2.4.1中列出的所有限制的程序，而不会达到任何翻译限制，限制的存在，记录的程度以及超出这些限制的影响本标准管辖范围之外的所有实施质量问题。

我认为标准的意图很明确，编译器不应假定while(1) {}没有副作用或break语句的循环将终止。与某些人的想法相反，该标准的作者并没有邀请编译器作者变得愚蠢或过时。合格的实现可能会有用地决定终止任何程序，该程序如果不被中断，则执行的无副作用指令要比宇宙中存在的原子更多，但是高质量的实现不应基于以下假设进行任何操作：终止，而是基于这样做可能是有用的，并且不会（与clang的行为不同）比没有用更糟。

该循环没有副作用，因此可以进行优化。循环实际上是零工作单位的无限次迭代。在数学和逻辑上这是未定义的，并且标准没有说如果每件事情都可以在零时间内完成，那么是否允许一个实现完成无数个事情。Clang的解释在将无穷大时间零视为零而不是无穷大时是完全合理的。该标准没有说明如果实际上所有循环工作都已完成，那么无限循环是否可以结束。

允许编译器优化标准中未定义的任何行为。这包括执行时间。不需要保留以下事实：如果不进行优化，则循环将花费无数的时间。可以将其更改为更短的运行时间-实际上，这是大多数优化的关键。您的循环已优化。

即使clang天真地翻译了代码，您也可以想象一个优化的CPU可以在上次迭代花费一半的时间内完成每个迭代。从字面上看，这将在有限的时间内完成无限循环。这样的优化CPU是否违反标准？如果说优化CPU太擅长优化就会违反标准，这似乎很荒谬。编译器也是如此。

如果真不是这样，我很抱歉，我偶然发现了这篇文章，我知道因为我使用Gentoo Linux发行版的年限，如果您不希望编译器优化代码，则应该使用-O0（Zero）。我对此感到很好奇，并编译并运行了上面的代码，循环确实无限期地进行。使用clang-9编译：

cc -O0 -std=c11 test.c -o test

一个空的 while循环对系统没有任何副作用。

因此Clang将其删除。有一些“更好的”方法可以实现预期的行为，从而迫使您更加清楚自己的意图。

while(1); 是baaadd。