Bagaimana cara membuat loop kosong tanpa batas yang tidak akan dioptimalkan?

Standar C11 tampaknya menyiratkan bahwa pernyataan iterasi dengan ekspresi kontrol konstan tidak boleh dioptimalkan. Saya menerima saran saya dari jawaban ini , yang secara khusus mengutip bagian 6.8.5 dari konsep standar:

Pernyataan iterasi yang ekspresi pengontrolnya bukan ekspresi konstan ... dapat diasumsikan oleh implementasi untuk diakhiri.

Dalam jawaban itu disebutkan bahwa perulangan seperti while(1) ;tidak boleh dikenai optimasi.

Jadi ... mengapa Dentang / LLVM mengoptimalkan loop di bawah ini (dikompilasi dengan 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");
}

Di mesin saya, ini dicetak begin, kemudian crash pada instruksi ilegal ( ud2jebakan ditempatkan setelah die()). Pada godbolt , kita dapat melihat bahwa tidak ada yang dihasilkan setelah panggilan ke puts.

Sudah menjadi tugas yang sangat sulit untuk mendapatkan Dentang untuk menghasilkan loop tak terbatas di bawah -O2- sementara saya bisa berulang kali menguji volatilevariabel, yang melibatkan memori baca yang tidak saya inginkan. Dan jika saya melakukan sesuatu seperti ini:

#include <stdio.h>

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

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

... Dentang cetakan begindiikuti unreachableseolah-olah infinite loop tidak pernah ada.

Bagaimana Anda membuat Dentang untuk menghasilkan loop tak terbatas tanpa-memori-akses yang tepat dengan optimisasi dihidupkan?

Standar C11 mengatakan ini, 6.8.5 / 6:

Pernyataan iterasi yang ekspresi pengontrolnya bukan ekspresi konstan, ¹⁵⁶⁾ yang tidak melakukan operasi input / output, tidak mengakses objek yang mudah menguap, dan tidak melakukan sinkronisasi atau operasi atom di dalam tubuhnya, mengendalikan ekspresi, atau (dalam kasus a untuk pernyataan) ekspresinya-3, dapat diasumsikan oleh implementasi untuk mengakhiri. ¹⁵⁷⁾

Catatan dua kaki tidak normatif tetapi memberikan informasi yang berguna:

156) Ekspresi kontrol yang dihilangkan digantikan oleh konstanta bukan nol, yang merupakan ekspresi konstan.

157) Ini dimaksudkan untuk memungkinkan transformasi kompiler seperti penghapusan loop kosong bahkan ketika penghentian tidak dapat dibuktikan.

Dalam kasus Anda, while(1)adalah ekspresi konstan sebening kristal, sehingga mungkin tidak diasumsikan oleh implementasi untuk mengakhiri. Implementasi seperti itu akan putus harapan, karena loop "selamanya" adalah konstruksi pemrograman yang umum.

Apa yang terjadi pada "kode yang tidak terjangkau" setelah loop adalah, sejauh yang saya tahu, tidak didefinisikan dengan baik. Namun, dentang memang berperilaku sangat aneh. Membandingkan kode mesin dengan 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

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

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

gcc menghasilkan loop, dentang hanya berjalan ke hutan dan keluar dengan kesalahan 255.

Saya condong ke arah ini karena tingkah laku tidak patuh. Karena saya mencoba untuk memperluas contoh Anda lebih lanjut seperti ini:

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

Saya menambahkan C11 _Noreturndalam upaya untuk membantu kompilator lebih jauh. Harus jelas bahwa fungsi ini akan menutup telepon, dari kata kunci itu saja.

setjmpakan mengembalikan 0 pada eksekusi pertama, jadi program ini seharusnya hanya menabrak while(1)dan berhenti di sana, hanya mencetak "mulai" (dengan asumsi \ n flushes stdout). Ini terjadi dengan gcc.

Jika pengulangan hanya dihapus, itu harus mencetak "mulai" 2 kali kemudian mencetak "tidak terjangkau". Namun pada dentang ( godbolt ), ia mencetak "mulai" 1 kali dan kemudian "tidak dapat dijangkau" sebelum mengembalikan kode keluar 0. Itu benar-benar salah, tidak peduli bagaimana Anda memasukkannya.

Saya tidak dapat menemukan kasus untuk mengklaim perilaku tidak terdefinisi di sini, jadi pendapat saya adalah bahwa ini adalah bug di dentang. Bagaimanapun, perilaku ini membuat dentang 100% tidak berguna untuk program seperti embedded system, di mana Anda harus bisa mengandalkan loop kekal yang menggantung program (sambil menunggu anjing penjaga dll).

Anda perlu memasukkan ekspresi yang dapat menyebabkan efek samping.

Solusi paling sederhana:

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

Tautan Godbolt

Jawaban lain sudah membahas cara-cara untuk membuat Dentang memancarkan loop tak terbatas, dengan bahasa rakitan inline atau efek samping lainnya. Saya hanya ingin mengkonfirmasi bahwa ini memang bug kompiler. Secara khusus, ini adalah bug LLVM lama - ini menerapkan konsep C ++ dari "semua loop tanpa efek samping harus diakhiri" ke bahasa yang tidak seharusnya, seperti C.

Sebagai contoh, bahasa pemrograman Rust juga memungkinkan loop tak terbatas dan menggunakan LLVM sebagai backend, dan memiliki masalah yang sama.

Dalam jangka pendek, tampaknya LLVM akan terus menganggap bahwa "semua loop tanpa efek samping harus diakhiri". Untuk bahasa apa pun yang memungkinkan loop tak terbatas, LLVM mengharapkan front-end untuk memasukkan llvm.sideeffectopcode ke dalam loop tersebut. Ini adalah apa yang direncanakan Rust untuk dilakukan, jadi Dentang (ketika mengkompilasi kode C) mungkin harus melakukannya juga.

Ini adalah bug Dentang

... saat menggarisbawahi suatu fungsi yang mengandung infinite loop. Perilaku ini berbeda ketika while(1);muncul langsung di utama, yang baunya sangat buggy bagi saya.

Lihat jawaban @ Arnavion untuk ringkasan dan tautan. Sisa jawaban ini ditulis sebelum saya mendapat konfirmasi bahwa itu adalah bug, apalagi bug yang dikenal.

Untuk menjawab pertanyaan judul: Bagaimana cara membuat loop kosong tanpa batas yang tidak akan dioptimalkan? ? -
buat die()makro, bukan fungsi , untuk mengatasi bug ini di Dentang 3.9 dan yang lebih baru. (Sebelumnya versi dentang baik membuat loop atau memancarkancall ke versi non-inline fungsi dengan loop tak terbatas.) Itu muncul untuk menjadi aman bahkan jika print;while(1);print;inlines fungsi menjadi nya pemanggil ( Godbolt ). -std=gnu11vs -std=gnu99tidak mengubah apa pun.

Jika Anda hanya peduli dengan GNU C, P__J___ di__asm__(""); dalam loop juga berfungsi, dan seharusnya tidak merusak optimasi kode di sekitarnya untuk setiap kompiler yang memahaminya. GNU C Pernyataan asm dasar secara implisitvolatile , jadi ini dianggap sebagai efek samping yang terlihat yang harus "mengeksekusi" sebanyak yang akan terjadi pada mesin abstrak C. (Dan ya, Clang mengimplementasikan dialek C GNU, seperti yang didokumentasikan oleh manual GCC.)

Beberapa orang berpendapat bahwa mungkin saja mengoptimalkan loop kosong tanpa batas yang sah. Saya tidak setuju ¹ , tetapi bahkan jika kami menerimanya, tidak bisa juga legal bagi Dentang untuk mengambil pernyataan setelah perulangan tidak dapat dijangkau, dan membiarkan eksekusi jatuh dari ujung fungsi ke fungsi berikutnya, atau menjadi sampah yang menerjemahkan sebagai instruksi acak.

(Itu akan memenuhi standar untuk Clang ++ (tapi masih tidak terlalu berguna); loop tak terbatas tanpa efek samping adalah UB dalam C ++, tetapi tidak C.
Apakah sementara (1); perilaku tidak terdefinisi dalam C? UB memungkinkan kompiler memancarkan apa pun pada dasarnya untuk kode di jalur eksekusi yang pasti akan menemui UB. asmPernyataan dalam loop akan menghindari UB ini untuk C ++. Namun dalam praktiknya, Clang mengkompilasi sebagai C ++ tidak menghapus ekspresi konstan loop kosong tak terbatas kecuali saat inlining, sama seperti ketika kompilasi sebagai C.)

Inlining secara manual while(1);mengubah cara Clang mengkompilasinya: infinite loop hadir dalam asm. Ini adalah apa yang kami harapkan dari POV aturan-pengacara.

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

Di explorer compiler Godbolt, Dentang 9.0 -O3 dikompilasi sebagai C ( -xc) untuk 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"

Kompiler yang sama dengan opsi yang sama mengkompilasi a mainyang memanggil infloop() { while(1); }ke yang sama pertama puts, tetapi kemudian hanya berhenti memancarkan instruksi untuk mainsetelah titik itu. Jadi seperti yang saya katakan, eksekusi hanya jatuh dari ujung fungsi, ke fungsi apa pun yang berikutnya (tetapi dengan tumpukan tidak selaras untuk entri fungsi sehingga bahkan tidak ada panggilan masuk yang valid).

Opsi yang valid adalah untuk

• memancarkan label: jmp labelloop tak terbatas
• atau (jika kami menerima bahwa loop tak terbatas dapat dihapus) memancarkan panggilan lain untuk mencetak string 2, dan kemudian return 0dari main.

Menerjang atau melanjutkan tanpa mencetak "tidak dapat dijangkau" jelas tidak ok untuk implementasi C11, kecuali ada UB yang belum saya perhatikan.

Catatan kaki 1:

Sebagai catatan, saya setuju dengan jawaban @ Lundin yang mengutip standar untuk bukti bahwa C11 tidak mengizinkan asumsi penghentian untuk loop tak terbatas ekspresi konstan, bahkan ketika mereka kosong (tidak ada I / O, volatile, sinkronisasi, atau lainnya efek samping yang terlihat).

Ini adalah serangkaian kondisi yang memungkinkan loop dikompilasi ke loop asm kosong untuk CPU normal. (Bahkan jika tubuh tidak kosong di sumber, tugas ke variabel tidak dapat dilihat oleh utas lain atau penangan sinyal tanpa data-ras UB saat loop sedang berjalan. Jadi implementasi yang sesuai dapat menghapus tubuh loop seperti itu jika diinginkan Kemudian yang meninggalkan pertanyaan apakah loop itu sendiri dapat dihapus. ISO C11 secara eksplisit mengatakan tidak.)

Mengingat bahwa C11 memilih kasus itu sebagai kasus di mana implementasi tidak dapat mengasumsikan loop berakhir (dan bahwa itu bukan UB), tampaknya jelas mereka berniat loop hadir pada saat run-time. Implementasi yang menargetkan CPU dengan model eksekusi yang tidak dapat melakukan jumlah pekerjaan tak terbatas dalam waktu terbatas tidak memiliki alasan untuk menghapus loop infinite konstan kosong. Atau bahkan secara umum, kata-kata yang tepat adalah tentang apakah mereka dapat "diasumsikan berakhir" atau tidak. Jika sebuah loop tidak dapat diakhiri, itu berarti kode yang lebih baru tidak dapat dijangkau, tidak peduli argumen apa yang Anda buat tentang matematika dan ketidakterbatasan dan berapa lama waktu yang diperlukan untuk melakukan pekerjaan tak terbatas pada beberapa mesin hipotetis.

Lebih jauh dari itu, Clang bukan hanya DeathStation 9000 yang sesuai dengan ISO C, itu dimaksudkan untuk berguna untuk pemrograman sistem tingkat rendah dunia nyata, termasuk kernel dan hal-hal yang tertanam. Jadi apakah Anda menerima argumen tentang C11 yang memungkinkan penghapusan while(1);, tidak masuk akal bahwa Clang ingin benar-benar melakukan itu. Jika Anda menulis while(1);, itu mungkin bukan kecelakaan. Penghapusan loop yang berakhir tanpa batas oleh kecelakaan (dengan ekspresi kontrol variabel runtime) dapat berguna, dan masuk akal bagi kompiler untuk melakukan itu.

Jarang Anda ingin hanya berputar sampai interupsi berikutnya, tetapi jika Anda menuliskannya dalam C, itulah yang Anda harapkan akan terjadi. (Dan apa yang terjadi di GCC dan dentang, kecuali untuk dentang ketika loop tak terbatas di dalam fungsi pembungkus).

Misalnya, dalam kernel OS primitif, ketika scheduler tidak memiliki tugas untuk menjalankannya mungkin menjalankan tugas idle. Implementasi pertama mungkin while(1);.

Atau untuk perangkat keras tanpa fitur siaga hemat daya, itu mungkin satu-satunya implementasi. (Sampai awal 2000-an, itu saya pikir tidak jarang pada x86. Meskipun hltinstruksi itu ada, IDK jika itu menghemat jumlah daya yang berarti sampai CPU mulai memiliki status siaga daya rendah.)

Hanya sebagai catatan, Clang juga bertingkah dengan goto:

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

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

Ini menghasilkan output yang sama seperti pada pertanyaan, yaitu:

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

Saya melihat tidak melihat cara untuk membaca ini sebagaimana diizinkan dalam C11, yang hanya mengatakan:

6.8.6.1 (2) gotoPernyataan menyebabkan lompatan tanpa syarat ke pernyataan diawali oleh label bernama dalam fungsi melampirkan.

Karena gotoini bukan "pernyataan iterasi" (6.8.5 daftar while, dodan for) tidak ada apa-apa tentang indulgensi khusus "diasumsikan pemutusan" berlaku, namun Anda ingin membacanya.

Per kompiler tautan Godbolt pertanyaan asli adalah x86-64 Dentang 9.0.0 dan flag-flagnya adalah -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

Dengan yang lain seperti x86-64 GCC 9.2 Anda mendapatkan yang cukup sempurna:

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

Bendera: -g -o output.s -masm=intel -S -fdiagnostics-color=always -O2 -std=c11 example.c

Saya akan berperan sebagai pendukung iblis dan berpendapat bahwa standar tersebut tidak secara eksplisit melarang kompiler untuk mengoptimalkan loop tanpa batas.

Pernyataan iterasi yang ekspresi pengontrolnya bukan ekspresi konstan, 156) yang tidak melakukan operasi input / output, tidak mengakses objek yang mudah menguap, dan tidak melakukan sinkronisasi atau operasi atom di dalam tubuhnya, mengendalikan ekspresi, atau (dalam kasus a untuk pernyataan) ekspresinya-3, dapat diasumsikan oleh implementasi untuk mengakhiri.157)

Mari kita uraikan ini. Pernyataan iterasi yang memenuhi kriteria tertentu dapat diasumsikan berakhir:

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

Ini tidak mengatakan apa-apa tentang apa yang terjadi jika kriteria tidak terpenuhi dan dengan asumsi bahwa loop dapat berakhir bahkan tidak dilarang secara eksplisit selama aturan standar lainnya diamati.

do { } while(0)atau while(0){}setelah semua pernyataan iterasi (loop) yang tidak memenuhi kriteria yang memungkinkan kompiler untuk hanya mengasumsikan pada kemauan bahwa mereka mengakhiri dan namun mereka jelas-jelas mengakhiri.

Tetapi dapatkah kompiler hanya mengoptimalkan while(1){}?

5.1.2.3p4 mengatakan:

Dalam mesin abstrak, semua ekspresi dievaluasi sebagaimana ditentukan oleh semantik. Implementasi aktual tidak perlu mengevaluasi bagian dari ekspresi jika dapat menyimpulkan bahwa nilainya tidak digunakan dan tidak ada efek samping yang diperlukan dihasilkan (termasuk yang disebabkan oleh pemanggilan fungsi atau mengakses objek yang mudah menguap).

Ini menyebutkan ekspresi, bukan pernyataan, jadi tidak 100% meyakinkan, tetapi tentu saja memungkinkan panggilan seperti:

void loop(void){ loop(); }

int main()
{
    loop();
}

untuk dilewati. Menariknya, dentang memang melewatkannya, dan gcc tidak .

Saya yakin ini hanyalah bug lama. Saya meninggalkan tes saya di bawah ini dan khususnya referensi untuk diskusi di komite standar untuk beberapa alasan yang saya miliki sebelumnya.

Saya pikir ini adalah perilaku yang tidak terdefinisi (lihat akhir), dan Dentang hanya memiliki satu implementasi. GCC memang berfungsi seperti yang Anda harapkan, hanya mengoptimalkan unreachablepernyataan cetak tetapi meninggalkan loop. Entah bagaimana Clang secara aneh membuat keputusan saat menggabungkan in-lining dan menentukan apa yang bisa dilakukan dengan loop.

Perilaku ini sangat aneh - menghapus cetakan akhir, jadi "melihat" loop tak terbatas, tetapi kemudian menyingkirkan loop juga.

Itu lebih buruk sejauh yang saya tahu. Menghapus inline yang kita dapatkan:

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"

jadi fungsinya dibuat, dan panggilan dioptimalkan keluar. Ini bahkan lebih tangguh dari yang diharapkan:

#include <stdio.h>

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

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

menghasilkan perakitan yang sangat tidak optimal untuk fungsi tersebut, tetapi pemanggilan fungsi kembali dioptimalkan! Lebih buruk lagi:

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

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

Saya membuat banyak tes lain dengan menambahkan variabel lokal dan meningkatkannya, melewati pointer, menggunakan gotodll ... Pada titik ini saya akan menyerah. Jika Anda harus menggunakan dentang

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

melakukan pekerjaan. Ini payah dalam mengoptimalkan (jelas), dan pergi ke final yang berlebihan printf. Setidaknya programnya tidak berhenti. Mungkin GCC?

Tambahan

Setelah berdiskusi dengan David, saya berpendapat bahwa standar tidak mengatakan "jika kondisinya konstan, Anda mungkin tidak menganggap loop berakhir". Dengan demikian, dan diberikan berdasarkan standar tidak ada perilaku yang dapat diamati (seperti yang didefinisikan dalam standar), saya hanya akan berdebat tentang konsistensi - jika kompiler mengoptimalkan loop karena menganggap itu berhenti, seharusnya tidak mengoptimalkan pernyataan berikut.

Heck n1528 memiliki ini sebagai perilaku yang tidak terdefinisi jika saya membacanya dengan benar. Secara khusus

Masalah utama untuk melakukannya adalah memungkinkan kode bergerak melintasi loop yang berpotensi tidak berakhir

Dari sini saya pikir itu hanya bisa beralih ke diskusi tentang apa yang kita inginkan (diharapkan?) Daripada apa yang diizinkan.

Tampaknya ini adalah bug dalam kompiler Dentang. Jika tidak ada paksaan pada die()fungsi menjadi fungsi statis, hapus staticdan buat inline:

#include <stdio.h>

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

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

Ini berfungsi seperti yang diharapkan ketika dikompilasi dengan kompiler Dentang dan portabel juga.

Explorer Compiler (godbolt.org) - dentang 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"

Tampaknya ini berfungsi untuk saya:

#include <stdio.h>

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

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

di godbolt

Secara eksplisit mengatakan Dentang untuk tidak mengoptimalkan bahwa satu fungsi menyebabkan loop tak terbatas akan dipancarkan seperti yang diharapkan. Semoga ada cara untuk menonaktifkan optimasi tertentu secara selektif daripada hanya mematikannya seperti itu. Dentang masih menolak untuk mengeluarkan kode untuk yang kedua printf, meskipun. Untuk memaksanya melakukan itu, saya harus lebih lanjut memodifikasi kode di dalamnya mainmenjadi:

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

Sepertinya Anda harus menonaktifkan pengoptimalan untuk fungsi loop tak terbatas Anda, lalu memastikan bahwa loop tak terbatas Anda disebut kondisional. Di dunia nyata, yang terakhir hampir selalu terjadi.

Implementasi yang sesuai dapat, dan banyak yang praktis, memberlakukan batasan sewenang-wenang pada berapa lama suatu program dapat dijalankan atau berapa banyak instruksi yang akan dijalankannya, dan berperilaku secara sewenang-wenang jika batasan tersebut dilanggar atau - di bawah aturan "seolah-olah" --Jika itu menentukan bahwa mereka pasti akan dilanggar. Asalkan suatu implementasi dapat berhasil memproses setidaknya satu program yang secara nominal menjalankan semua batas yang tercantum dalam N1570 5.2.4.1 tanpa mencapai batas terjemahan, keberadaan batas, sejauh mana dokumen tersebut didokumentasikan, dan dampak dari melampauinya, adalah semua masalah Kualitas Penerapan di luar yurisdiksi Standar.

Saya pikir maksud Standar cukup jelas bahwa penyusun tidak boleh berasumsi bahwa while(1) {}perulangan tanpa efek samping atau breakpernyataan akan berakhir. Bertentangan dengan apa yang mungkin dipikirkan oleh beberapa orang, penulis Standar tidak mengundang penulis kompiler untuk menjadi bodoh atau bodoh. Implementasi yang sesuai mungkin berguna untuk memutuskan untuk menghentikan program apa pun yang, jika tidak terganggu, akan menjalankan lebih banyak instruksi efek samping daripada ada atom di alam semesta, tetapi implementasi kualitas tidak boleh melakukan tindakan seperti itu berdasarkan asumsi apa pun tentang pemberhentian tetapi lebih atas dasar bahwa hal itu bisa berguna, dan tidak akan (tidak seperti perilaku dentang) lebih buruk daripada tidak berguna.

Loop tidak memiliki efek samping, sehingga dapat dioptimalkan. Pengulangan secara efektif merupakan jumlah iterasi tanpa batas dari nol unit kerja. Ini tidak terdefinisi dalam matematika dan logika dan standar tidak mengatakan apakah suatu implementasi diizinkan untuk menyelesaikan banyak hal jika setiap hal dapat dilakukan dalam waktu nol. Interpretasi dentang sangat masuk akal dalam memperlakukan infinity kali nol sebagai nol daripada infinity. Standar tidak mengatakan apakah loop infinite dapat berakhir atau tidak jika semua pekerjaan dalam loop sudah selesai.

Kompiler diizinkan untuk mengoptimalkan segala sesuatu yang bukan perilaku yang dapat diamati sebagaimana didefinisikan dalam standar. Itu termasuk waktu eksekusi. Tidak perlu menjaga fakta bahwa perulangan, jika tidak dioptimalkan, akan membutuhkan waktu yang tidak terbatas. Hal ini diizinkan untuk mengubah itu ke waktu lari yang jauh lebih pendek - pada kenyataannya, itulah poin dari kebanyakan optimasi. Loop Anda dioptimalkan.

Bahkan jika dentang menerjemahkan kode secara naif, Anda dapat membayangkan sebuah CPU yang mengoptimalkan yang dapat menyelesaikan setiap iterasi dalam setengah waktu iterasi sebelumnya. Itu benar-benar akan menyelesaikan loop tak terbatas dalam jumlah waktu yang terbatas. Apakah mengoptimalkan CPU seperti itu melanggar standar? Tampaknya tidak masuk akal untuk mengatakan bahwa mengoptimalkan CPU akan melanggar standar jika terlalu baik dalam mengoptimalkan. Hal yang sama berlaku untuk kompiler.

Saya minta maaf jika ini bukan kepalang masalahnya, saya menemukan posting ini dan saya tahu karena tahun-tahun saya menggunakan distro Gentoo Linux bahwa jika Anda ingin kompiler tidak mengoptimalkan kode Anda, Anda harus menggunakan -O0 (Nol). Saya ingin tahu tentang hal itu, dan mengkompilasi dan menjalankan kode di atas, dan loop tidak berjalan tanpa batas. Dikompilasi menggunakan clang-9:

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

whileLoop kosong tidak memiliki efek samping pada sistem.

Oleh karena itu Dentang menghapusnya. Ada beberapa cara "lebih baik" untuk mencapai perilaku yang diinginkan yang memaksa Anda untuk lebih jelas tentang niat Anda.

while(1); adalah baaadd.