最適化されない無限の空のループを作成するにはどうすればよいですか？

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");
}

... Clang は、無限ループが存在しないかのようにbegin続きunreachableます。

最適化をオンにして、Clangに適切なメモリアクセスなしの無限ループを出力させるにはどうすればよいですか？

C11標準はこれを6.8.5 / 6と述べています：

制御式が定数式ではない反復ステートメント^156）は、入出力操作を実行せず、揮発性オブジェクトにアクセスせず、その本体、制御式、または（forの場合、ステートメント）その式-3は、実装によって終了すると見なされます。^157）

2つの脚注は規範的ではありませんが、有用な情報を提供します。

156）省略された制御式は、定数式であるゼロ以外の定数に置き換えられます。

157）これは、終了が証明できない場合でも、空のループの削除などのコンパイラー変換を可能にすることを目的としています。

あなたの場合、while(1)は非常に明確な定数式なので、実装によって終了するとは想定されていない場合があります。「いつまでも」ループはプログラミングの一般的な構成要素であるため、そのような実装は絶望的に破られるでしょう。

ただし、ループの後で「到達不能コード」に何が起こるかは、私の知る限り、明確に定義されていません。ただし、clangは実際には非常に奇妙な動作をします。マシンコードと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

clang 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");
}

_Noreturnコンパイラをさらに支援するためにC11を追加しました。このキーワードだけでは、この関数がハングアップすることは明らかです。

setjmp最初の実行時に0を返すため、このプログラムはにスマッシュしてwhile(1)そこで停止し、「begin」だけを出力する必要があります（\ nがstdoutをフラッシュすると想定）。これはgccで発生します。

ループが単に削除された場合は、「begin」を2回出力し、次に「unreachable」を出力する必要があります。ただし、clang（godbolt）では、「begin」が1回出力され、次に「unreachable」が出力されてから、終了コード0が返されます。どのように配置しても、それはまったく間違っています。

ここでは未定義の動作を主張することはできませんので、これはclangのバグだと思います。とにかく、この動作により、組み込みシステムなどのプログラムではclangが100％役に立たなくなります。この場合、（ウォッチドッグなどを待機している間）プログラムを停止している永遠のループに依存できる必要があります。

副作用を引き起こす可能性のある式を挿入する必要があります。

最も簡単な解決策：

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

ゴッドボルトリンク

他の回答は、Clangにインラインアセンブリ言語やその他の副作用を伴う無限ループを発生させる方法をすでにカバーしています。これが本当にコンパイラのバグであることを確認したいだけです。具体的には長年のLLVMバグです。「副作用のないすべてのループは終了する必要がある」というC ++の概念を、Cなどの禁止すべきでない言語に適用します。

たとえば、Rustプログラミング言語は無限ループも許可し、LLVMをバックエンドとして使用します。これと同じ問題があります。

短期的には、LLVMは「副作用のないすべてのループは終了しなければならない」と想定し続けるようです。無限ループを許可する言語の場合、LLVMは、フロントエンドがllvm.sideeffectそのようなループにオペコードを挿入することを期待します。これはRustが計画していることなので、Clang（Cコードのコンパイル時）もおそらくそれを行う必要があります。

これはClangのバグです

...無限ループを含む関数をインライン化するとき。while(1);mainに直接表示されたときの動作は異なります。

概要とリンクについては、@ Arnavionの回答を参照してください。この回答の残りの部分は、既知のバグはもちろんのこと、バグであることを確認する前に書かれました。

タイトルの質問に答えるには：最適化されない無限の空のループを作成するにはどうすればよいですか？？-
作るdie()マクロではなく、機能を、クラン3.9以降では、このバグを回避します。（以前のClangバージョンは、ループを保持するcallか、無限ループのある関数の非インラインバージョンにを出力します。）print;while(1);print;関数が呼び出し元（Godbolt）にインライン化しても安全であるように見えます。 -std=gnu11対-std=gnu99何も変わりません。

GNU Cのみに関心がある__asm__("");場合は、ループ内のP__J__も機能し、それを理解するコンパイラーの周囲のコードの最適化を損なうべきではありません。GNU C Basic asmステートメントは暗黙的volatileであるため、これは、C抽象マシンで実行するのと同じ回数「実行」する必要がある目に見える副作用としてカウントされます。（そうです、ClangはGCCマニュアルで文書化されているように、CのGNU方言を実装しています。）

一部の人々は、空の無限ループを最適化することは合法であるかもしれないと主張しました。私は同意しません¹、ただしそれを受け入れたとしても、Clangがループに到達できない後のステートメントを想定することは合法ではありません。し、実行が関数の終わりから次の関数またはガベージに落ちることを許すランダムな命令としてデコードします。

（これは、Clang ++の標準に準拠します（ただし、あまり有用ではありません）。副作用のない無限ループは、C ++ではUBですが、Cで
はありません。while （1）です。Cの未定義の動作 により、コンパイラーは基本的に何でも出力できます確実にUBに遭遇する実行パス上のコードの場合。asmループ内のステートメントはC ++のこのUBを回避します。しかし、実際には、C ++としてコンパイルされたClangは、インラインの場合を除いて、定数式の無限空ループを削除しません。 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 -xcをx86-64のC（）としてコンパイルします。

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"

同じコンパイラを同じオプションで使用すると、最初に同じmainを呼び出すa がコンパイルされますが、その後は命令の発行が停止されます。したがって、先に述べたように、実行は関数の最後から次の関数に落ちます（ただし、スタックは関数のエントリに対して誤って配置されているため、有効な末尾呼び出しではありません）。infloop() { while(1); }putsmain

有効なオプションは

• label: jmp label無限ループを放出する
• またはその後第2文字列を印刷するために別のコールを発し、そして（我々は、無限ループを除去することができることを受け入れる場合）return 0からmain。

クラッシュしたり、「到達不能」を表示せずに続行したりすることは、C11の実装では、気付かないUBがない限り、明らかに問題です。

脚注1：

記録として、私は、 C11が定数式無限ループが空である（I / O、揮発性、同期、またはその他がない）場合でも、終了の仮定を許可しないという証拠の基準を引用する@Lundinの回答に同意します目に見える副作用）。

これは、通常の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

私は悪魔の支持者を演じ、標準がコンパイラが無限ループを最適化することを明示的に禁止していないと主張します。

制御式が定数式ではない反復文156）は、入出力操作を実行せず、揮発性オブジェクトにアクセスせず、本体、制御式、または（forの場合は）同期またはアトミック操作を実行しません。ステートメント）その式-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には1つの実装しかないと思います。GCCは実際に期待どおりに機能し、unreachableprintステートメントのみを最適化してループを終了します。インラインを組み合わせてループで何ができるかを決定するときに、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。少なくともプログラムは停止しません。たぶんGCCでしょうか？

補遺

デビッドとの議論の後、私は標準が「条件が一定である場合、ループが終了すると仮定しないかもしれない」とは言っていません。そのため、標準で認められている動作（標準で定義されている）はありません。一貫性についてのみ議論します。コンパイラがループを終了することを想定しているため、ループを最適化している場合、次のステートメントは最適化しないでください。

ヘック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に1つの関数を最適化しないように明示的に指示すると、期待どおりに無限ループが発生します。うまくいけば、特定の最適化をすべて無効にするのではなく、特定の最適化を選択的に無効にする方法があります。printfただし、Clangは2番目のコードの発行を拒否します。それを強制するために、内部のコードをさらに変更する必要がありmainました：

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

無限ループ関数の最適化を無効にし、無限ループが条件付きで呼び出されるようにする必要があるようです。実世界では、とにかく後者がほとんどの場合当てはまります。

準拠する実装は、プログラムの実行時間または実行する命令の数に任意の制限を課す可能性があり、実際の多くの場合、制限に違反した場合、または「as-if」ルールの下で任意の方法で動作します。 -違反が避けられないと判断した場合。実装がN1570 5.2.4.1にリストされているすべての制限を名目上実行する少なくとも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です。