Optimize edilmeyecek sonsuz bir boş döngüyü nasıl yapabilirim?

C11 standardı, sürekli kontrol ifadelerine sahip yineleme ifadelerinin optimize edilmemesi gerektiği anlamına geliyor. Tavsiyemi taslak standarttan bölüm 6.8.5'ten alıntı yapan bu cevaptan alıyorum :

Kontrol ifadesi sabit bir ifade olmayan bir yineleme ifadesi ... uygulama tarafından sonlandırılacağı varsayılabilir.

Bu cevapta, benzer bir döngünün while(1) ;optimizasyona tabi olmaması gerektiği belirtilmektedir.

Öyleyse ... Clang / LLVM neden aşağıdaki döngüyü optimize ediyor (derlendi 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");
}

Makinemde bu yazdırılıyor begin, sonra yasadışı bir talimatla ( ud2sonra yerleştirilen bir tuzak die()) çöküyor . Godbolt'da , çağrıdan sonra hiçbir şeyin üretilmediğini görebiliriz puts.

Clang'ın sonsuz bir döngü çıkmasını sağlamak şaşırtıcı derecede zor bir işti -O2- tekrar tekrar bir volatiledeğişkeni test edebilirken , istemediğim bir hafıza okumasını içeriyor. Ve eğer böyle bir şey yaparsam:

#include <stdio.h>

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

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

... Clang baskıları ve beginardından unreachablesonsuz döngü hiç yokmuş gibi geliyor.

Optimizasyon açıkken Clang'ın uygun, hafızasız erişime sahip sonsuz bir döngü üretmesini nasıl sağlıyorsunuz?

C11 standardı bunu söylüyor, 6.8.5 / 6:

Kontrol ifadesi sabit bir ifade olmayan bir yineleme ifadesi, ¹⁵⁶⁾ giriş / çıkış işlemi gerçekleştirmeyen, uçucu nesnelere erişmeyen ve gövdesinde hiçbir senkronizasyon veya atomik işlem gerçekleştirmeyen, ifadeyi kontrol eden veya ifadesi) ifadesi-3, uygulama tarafından sonlandırılacağı varsayılabilir. ¹⁵⁷⁾

İki dip notu normatif değildir ancak faydalı bilgiler sağlar:

156) Atlanan bir kontrol ifadesi, sabit bir ifade olan sıfır olmayan bir sabit ile değiştirilir.

157) Bu, sonlandırma kanıtlanamasa bile boş döngülerin çıkarılması gibi derleyici dönüşümlerine izin vermek için tasarlanmıştır.

Senin durumunda, while(1)bu yüzden olabilir, kristal berraklığında sabit ifadesidir değil sonlandırmak için uygulanması yoluyla varsayılabilir. "Sonsuza dek" döngüler ortak bir programlama yapısı olduğundan böyle bir uygulama umutsuzca kırılacaktır.

Ancak döngüden sonra "ulaşılamaz kod" ne olur, bildiğim kadarıyla, iyi tanımlanmış değil. Ancak, clang gerçekten çok garip davranıyor. Makine kodunu gcc (x86) ile karşılaştırma:

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 döngüyü oluşturur, clang sadece ormana girer ve hata 255 ile çıkar.

Bu clang'ın uyumlu olmayan davranışına doğru eğildim. Çünkü örneğinizi şöyle genişletmeye çalıştım çünkü:

#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 ekledim _NoreturnDerleyiciye daha da yardımcı olmak için . Bu işlevin yalnızca o anahtar kelimeden kapatılacağı açık olmalıdır.

setjmpilk yürütme üzerine 0 döndürecektir, bu nedenle bu program sadece şut while(1)ve orada durmak gerekir , sadece baskı "başlar" (\ n stdout temizler varsayalım). Bu gcc ile olur.

Döngü basitçe kaldırılmışsa, 2 kez "start" yazmalı, sonra "ulaşılamaz" yazmalıdır. Ancak clang'da ( godbolt ), çıkış kodu 0'ı döndürmeden önce 1 kez "başlar" ve sonra "ulaşılamaz" yazdırır.

Burada tanımsız davranış iddia için hiçbir dava bulamıyorum, bu yüzden benim almak bu clang bir hata olmasıdır. Her halükarda, bu davranış, gömülü sistemler gibi programlar için% 100 işe yaramaz hale gelir, burada programı asılı olan sonsuz döngülere güvenmeniz gerekir (bir bekçi köpeği vb. Beklerken).

Yan etkiye neden olabilecek bir ifade eklemeniz gerekir.

En basit çözüm:

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

Godbolt bağlantısı

Diğer cevaplar, Clang'ı sıralı montaj dili veya diğer yan etkilerle sonsuz döngüyü yaymanın yollarını zaten içeriyordu. Sadece bunun gerçekten bir derleyici hatası olduğunu onaylamak istiyorum. Özellikle, uzun süredir devam eden bir LLVM hatası - C ++ "yan etkileri olmayan tüm döngülerin sona ermesi gerekir" kavramını, C gibi olmaması gereken dillere uygular.

Örneğin, Rust programlama dili sonsuz döngülere izin verir ve LLVM'yi arka uç olarak kullanır ve aynı sorunu yaşar.

Kısa vadede, LLVM'nin "yan etkileri olmayan tüm döngülerin sona ermesi gerektiğini" varsaymaya devam edeceği görülüyor. Sonsuz döngülere izin veren herhangi bir dil için, LLVM ön uçtan llvm.sideeffectbu tür döngülere opcode girmesini bekler . Rust'un yapmayı planladığı şey budur, bu yüzden Clang (C kodunu derlerken) muhtemelen bunu yapmak zorunda kalacaktır.

Bu bir Clang hatası

... sonsuz döngü içeren bir işlevi satır içine alırken. Davranış while(1);doğrudan anada göründüğünde farklıdır , bu da bana çok adamcağız kokuyor.

Özet ve bağlantılar için @ Arnavion'un cevabına bakınız . Bu cevabın geri kalanı, bilinen bir hata olsun, bunun bir hata olduğunu onaylamadan önce yazılmıştı.

Başlık sorusunu cevaplamak için: Optimize edilmeyen sonsuz bir boş döngüyü nasıl yapabilirim? ? -
yapmak die()bir makro değil, bir işlev , Clang 3.9 ve daha sonra bu hatayı gidermek için. (Daha önceki Clang sürümleri döngüyü tutar veyacall sonsuz döngü ile işlevin satıriçi olmayan bir sürümüne yayar .) print;while(1);print;İşlev , arayana ( Godbolt ) girdiğinde bile güvenli görünüyor . -std=gnu11vs. -std=gnu99hiçbir şeyi değiştirmez.

Sadece GNU C ile ilgileniyorsanız__asm__(""); , döngü içindeki P__J __ 'ler de çalışır ve onu anlayan herhangi bir derleyici için herhangi bir çevre kodunun optimizasyonuna zarar vermemelidir. GNU C Basic asm ifadeleri dolaylı olarakvolatile , bu nedenle bu C soyut makinesinde olduğu gibi "yürütülmesi" gereken görünür bir yan etki olarak sayılır. (Ve evet, Clang, GCC kılavuzunda belgelendiği gibi C'nin GNU lehçesini uygular.)

Bazı insanlar boş bir sonsuz döngüyü optimize etmenin yasal olabileceğini öne sürdüler. Katılmıyorum ¹ , ama biz bunu kabul bile, o olamaz da Clang döngü sonra ifadeleri ulaşılamaz olduğunu varsayıyorum, için yasal olması ve bir sonraki fonksiyonu içine fonksiyonun sonuna kapalı infaz düşürdüm veya çöpe rastgele talimatlar olarak çözülür.

(Bu Clang ++ için standartlara uygun olacaktır (ancak yine de çok yararlı değildir); herhangi bir yan etkisi olmayan sonsuz döngüler C ++ 'da UB'dir, ancak C değildir.
(1); C? UB'deki tanımlanmamış davranış derleyicinin temelde herhangi bir şey yayınlamasına izin verir UB ile karşılaşacak bir yürütme yolu üzerindeki kod asmiçin Döngüdeki bir ifade, C ++ için bu UB'yi önleyecektir.Ancak pratikte, C ++ olarak derlenen Clang, satır içi olanlar hariç, sabit ifade sonsuz boş döngüleri kaldırmaz. C olarak derleme)

Manuel olarak satır içine alma, while(1);Clang'ın derleme şeklini değiştirir: asm'de sonsuz döngü vardır. Kurallar avukatý POV'dan beklediđimiz bu.

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

Godbolt derleyici gezgininde Clang 9.0-O3 -xc, x86-64 için C ( ) olarak derlenir :

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"

Aynı seçeneklere sahip aynı derleyici, önce aynı mainçağrıyı çağıran bir derleme yapar , ancak o noktadan sonra için talimat infloop() { while(1); }vermeyi putsdurdurur main. Dediğim gibi, yürütme sadece fonksiyonun sonundan, sonraki herhangi bir fonksiyona düşer (ancak yığın, işlev girişi için yanlış hizalanmış olduğundan, geçerli bir kuyruk araması bile değildir).

Geçerli seçenekler

• label: jmp labelsonsuz döngü yayar
• veya daha sonra 2 dize yazdırmak için başka bir çağrı yayan ve (biz sonsuz döngü kaldırılabilir kabul varsa) return 0den main.

Farkedilmediğim UB olmadığı sürece, "ulaşılamıyor" yazdırılmadan çökme veya başka bir şekilde devam etme, bir C11 uygulaması için açıkça uygun değildir.

Dipnot 1:

Kayıt için, C11'in boş ifadeli sonsuz döngüler için sonlandırma varsayımına izin vermediğine dair kanıt standardını belirten @ Lundin'in cevabı ile aynı fikirdeyim (G / Ç, uçucu, senkronizasyon veya diğer görünür yan etkiler).

Bu, bir döngünün normal bir CPU için boş bir asm döngüsüne derlenmesine izin verecek koşullar kümesidir . (Gövde kaynakta boş olmasa bile, değişkenler için atamalar döngü çalışırken veri yarışı UB'si olmayan diğer iş parçacıkları veya sinyal işleyicileri tarafından görülemez. Bu nedenle, uygun bir uygulama isterse bu döngü gövdelerini kaldırabilir Bu, halkanın kendisinin kaldırılıp kaldırılamayacağı sorusunu bırakır. ISO C11 açıkça hayır diyor.)

C11'in, uygulamanın döngünün sona erdiğini varsayamayacağı (ve bunun UB olmadığı) bir durum olduğu göz önüne alındığında, döngünün çalışma zamanında mevcut olmasını amaçladıkları açık görünüyor. Sonlu zamanda sonsuz miktarda iş yapamayan bir yürütme modeline sahip CPU'ları hedefleyen bir uygulamanın, boş bir sabit sonsuz döngüyü kaldırmak için bir gerekçesi yoktur. Ya da genel olarak bile, kesin ifadeler "sonlandıkları varsayılıp varsayılmayacakları" ile ilgilidir. Bir döngü sonlanamazsa, matematik ve sonsuzluklarla ilgili hangi argümanları yaptığınız ve bazı varsayımsal makinelerde sonsuz miktarda iş yapmanın ne kadar sürdüğü önemli değil, daha sonra kodlara erişilemez demektir .

Bunun yanı sıra, Clang sadece ISO C uyumlu bir DeathStation 9000 değil, çekirdekler ve gömülü nesneler de dahil olmak üzere gerçek dünyadaki düşük seviyeli sistem programlaması için faydalı olması amaçlanmıştır. Dolayısıyla , C11'in kaldırılmasına izin veren argümanları kabul edip while(1);etmediğiniz, Clang'ın bunu gerçekten yapmak isteyeceği mantıklı değildir. Eğer yazarsanız while(1);, bu muhtemelen bir kaza değildi. Kaza ile sonsuz olan döngülerin kaldırılması (çalışma zamanı değişken kontrol ifadeleriyle) yararlı olabilir ve derleyicilerin bunu yapması mantıklıdır.

Bir sonraki kesintiye kadar sadece döndürmek istersiniz, ancak C'de yazarsanız kesinlikle olmasını beklediğiniz şey budur. (Ya gelmez , GCC ve Clang meydana sonsuz döngü bir sarıcı işlevi içinde olduğunda Clang için hariç).

Örneğin, ilkel bir OS çekirdeğinde, zamanlayıcının çalışacak hiçbir görevi olmadığında, boşta kalma görevini çalıştırabilir. Bunun ilk uygulaması olabilir while(1);.

Veya herhangi bir güç tasarruflu rölanti özelliği olmayan donanımlar için tek uygulama bu olabilir. (2000'lerin başına kadar, bu x86'da nadir olmadığını düşünüyorum. hltTalimat mevcut olmasına rağmen , IDK, CPU'lar düşük güçlü boşta durumlara sahip olana kadar anlamlı miktarda güç tasarrufu yaptıysa.)

Sadece rekor için, Clang ayrıca şu şekilde yanlış davranır goto:

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

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

Sorudakiyle aynı çıktıyı üretir, yani:

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

Bunu, C11'de izin verildiği gibi okumak için herhangi bir yol göremiyorum, sadece şunu söylüyor:

6.8.6.1 (2) Bir gotoifade, kapatma fonksiyonunda adlandırılmış etiketin önüne gelen ifadeye koşulsuz bir sıçramaya neden olur.

As gotobir "yineleme deyimi" (6.8.5 listeleri değil while, dove for"sonlandırma-varsayılır" hoşgörü uygulamak, ancak bunları okumak istiyorum) special hakkında hiçbir şey.

Orijinal sorunun Godbolt bağlantı derleyicisi başına x86-64 Clang 9.0.0 ve bayraklar -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 gibi diğerleriyle oldukça mükemmel hale gelirsiniz:

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

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

Şeytanın avukatını oynayacağım ve standardın bir derleyicinin sonsuz bir döngüyü optimize etmesini açıkça yasaklamadığını savunacağım.

Kontrol ifadesi sabit bir ifade olmayan bir yineleme ifadesi, 156) giriş / çıkış işlemi gerçekleştirmeyen, uçucu nesnelere erişmeyen ve gövdesinde hiçbir senkronizasyon veya atomik işlem gerçekleştirmeyen, ifadeyi kontrol eden veya ifadesi) ifadesi-3, uygulama tarafından sonlandırılacağı varsayılabilir.157)

Bunu ayrıştıralım. Belirli kriterleri karşılayan bir yineleme ifadesinin sona erdirileceği varsayılabilir:

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

Bu, kriterler karşılanmadığında ve bir döngünün sona erebileceğini varsayarsak ne olacağı hakkında hiçbir şey söylemez, standardın diğer kuralları gözetildiği sürece açıkça yasak değildir.

do { } while(0)ya while(0){}da sonuçta bir derleyicinin sadece sonlandıkları bir hevesle varsaymalarına izin veren kriterleri karşılamayan ve yine de sonlandıkları açık olan yineleme ifadeleri (döngüler).

Ancak derleyici sadece optimize edebilir while(1){}mi?

5.1.2.3p4 diyor ki:

Soyut makinede, tüm ifadeler semantik tarafından belirtildiği şekilde değerlendirilir. Gerçek bir uygulamanın, değerinin kullanılmadığını ve gerekli hiçbir yan etkinin üretilmediğini (bir işlevi çağırmaktan veya geçici bir nesneye erişmekten kaynaklananlar da dahil olmak üzere) bir ifadenin bir kısmını değerlendirmesine gerek yoktur.

Bu ifadelerden değil, ifadelerden bahsediyor, bu yüzden% 100 ikna edici değil, ancak kesinlikle aşağıdaki gibi çağrılara izin veriyor:

void loop(void){ loop(); }

int main()
{
    loop();
}

atlanacak. İlginçtir, clang onu atlamaz ve gcc yapmaz .

Bu sadece düz eski bir hata olduğuna ikna oldum. Testlerimi aşağıda ve özellikle de daha önce sahip olduğum bazı gerekçelerle standart komitede tartışmaya atıfta bulunuyorum.

Bence bu tanımsız davranış (sonuna bakın) ve Clang'ın sadece bir uygulaması var. GCC gerçekten beklediğiniz gibi çalışır, yalnızca unreachableprint deyimini optimize eder, ancak döngüyü terk eder. Clang, astarı birleştirirken ve döngü ile neler yapabileceğini belirlerken garip bir şekilde kararlar veriyor.

Davranış çok tuhaf - son baskıyı kaldırır, bu yüzden sonsuz döngüyü "görür", ancak daha sonra döngüden de kurtulur.

Anlayabildiğim kadarıyla daha da kötü. Satır içi kaldırdığımızda:

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"

böylece işlev oluşturulur ve çağrı optimize edilir. Bu beklenenden daha dayanıklı:

#include <stdio.h>

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

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

fonksiyon için çok uygun olmayan bir montaj ile sonuçlanır, ancak fonksiyon çağrısı tekrar optimize edilir! Daha da kötüsü:

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

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

Yerel bir değişken ekleyerek ve artırarak, bir işaretçi geçirerek, gotovb. Kullanarak bir sürü test yaptım ... Bu noktada vazgeçerdim. Clang kullanmanız gerekiyorsa

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

işi yapar. Optimizasyon (berrak) için berbat ve gereksiz finalde bırakır printf. En azından program durmuyor. Belki sonuçta GCC?

ek

David ile tartışmayı takiben, standardın "koşul sabitse, döngünün sona erdiğini varsaymayabilirsiniz" demediğini veriyorum. Bu nedenle ve standart altında (standartta tanımlandığı gibi) gözlemlenebilir davranış yoktur, sadece tutarlılık için tartışacağım - eğer bir derleyici bir döngüyü sonlandırdığı için optimize ederse, aşağıdaki ifadeleri optimize etmemelidir.

Heck n1528 bunları doğru okursam tanımsız davranış olarak görür. özellikle

Bunu yapmak için önemli bir sorun, kodun sonlandırılmayan bir döngüde hareket etmesine izin vermesidir

Buradan sadece izin verilenlerden ziyade istediğimiz (beklenen?) Bir tartışmaya dönüşebileceğini düşünüyorum .

Görünüşe göre bu Clang derleyicisinde bir hata. die()Statik bir işlev olması için herhangi bir zorlama yoksa,static ve yapın inline:

#include <stdio.h>

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

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

Clang derleyicisiyle derlendiğinde beklendiği gibi çalışıyor ve taşınabilir.

Derleyici Gezgini (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"

Aşağıdakiler benim için çalışıyor gibi görünüyor:

#include <stdio.h>

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

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

en Godbolt

Clang'a bir fonksiyonun optimize edilmemesini açıkça bildirmesi, beklendiği gibi sonsuz bir döngü yayılmasına neden olur. Umarım belirli optimizasyonları hepsini böyle kapatmak yerine seçici olarak devre dışı bırakmanın bir yolu vardır. Yine de Clang, ikincisi için kod yayınlamayı reddediyor printf. Bunu yapmaya zorlamak için, içinde kodu daha fazla değiştirmek zorunda mainkaldı:

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

Sonsuz döngü işleviniz için optimizasyonları devre dışı bırakmanız ve ardından sonsuz döngünüzün koşullu olarak çağrıldığından emin olmanız gerekir. Gerçek dünyada, ikincisi zaten her zaman böyledir.

Uygun bir uygulama ve birçok pratik uygulama, bir programın ne kadar süre çalışabileceği veya kaç komut yürüteceği konusunda keyfi sınırlamalar getirebilir ve bu sınırlar ihlal edilirse veya - "eğer" kuralı uyarınca keyfi şekilde davranabilir - kaçınılmaz olarak ihlal edileceğini tespit ederse. Bir uygulamanın, N1570 5.2.4.1'de listelenen tüm limitleri, herhangi bir çeviri limitine, sınırların varlığına, belgelendirilme derecesine ve bunları aşmanın etkilerine çarpmadan nominal olarak uygulayan en az bir programı başarıyla işleyebilmesi şartıyla, Standardın yetki alanı dışındaki tüm Uygulama Kalitesi sorunları.

Standardın amacı, derleyicilerin while(1) {}hiçbir yan etkisi veya breakifadesi olmayan bir döngünün sona ereceğini varsaymaması gerektiğinin oldukça açık olduğunu düşünüyorum . Bazı insanların düşündüklerinin aksine, Standardın yazarları derleyici yazarlarını aptal veya küstah olmaya davet etmiyorlardı. Uygun bir uygulama, kesintiye uğramamışsa, evrendeki atomlardan daha fazla yan etki içermeyen talimatlar yürütecek olan herhangi bir programı sonlandırmaya karar vermek için yararlı olabilir, ancak kaliteli bir uygulama, bu tür herhangi bir varsayım temelinde bu tür bir eylem gerçekleştirmemelidir. sonlandırma yerine, yararlı olabileceğine ve (clang'ın davranışından farklı olarak) işe yaramayacağından daha kötü olmayacağı temelinde.

Döngünün hiçbir yan etkisi yoktur ve bu nedenle optimize edilebilir. Döngü, sıfır iş biriminin sonsuz sayıda yinelemesidir. Bu, matematikte ve mantıkta tanımlanmamıştır ve standart, her şeyin sıfır zamanda yapılabilmesi durumunda bir uygulamanın sonsuz sayıda şeyi tamamlamasına izin verilip verilmediğini söylemez. Clang'ın yorumu, sonsuzluk zamanlarının sonsuzluktan ziyade sıfır olarak muamele edilmesinde mükemmel bir şekilde makul. Standart, döngülerdeki tüm çalışmalar aslında tamamlandığında sonsuz bir döngünün sona erip bitmeyeceğini söylemez.

Derleyicinin, standartta tanımlanan gözlemlenebilir davranış olmayan her şeyi optimize etmesine izin verilir. Bu, yürütme süresini de içerir. Optimize edilmezse, döngünün sonsuz miktarda zaman alacağı gerçeğini korumak gerekli değildir. Bunu çok daha kısa çalışma süresine değiştirebilir - aslında, çoğu optimizasyon noktası. Döngünüz optimize edildi.

Clang kodu safça çevirse bile, her yinelemeyi bir önceki yinelemenin yarısında tamamlayabilen bir optimize CPU düşünebilirsiniz. Bu kelimenin tam anlamıyla sonsuz döngüyü sınırlı bir sürede tamamlardı. Böyle bir optimize edici CPU standardı ihlal ediyor mu? Optimize etmek için çok iyi olursa, optimize edici bir CPU'nun standardı ihlal edeceğini söylemek oldukça saçma görünüyor. Aynı şey bir derleyici için de geçerlidir.

Bu durum saçma değilse üzgünüm, bu yazı üzerine tökezledi ve biliyorum çünkü Gentoo Linux dağıtımını kullanarak yıllarım derleyicinin kodunuzu optimize etmemesini istiyorsanız -O0 (Sıfır) kullanmalısınız. Bunu merak ettim ve yukarıdaki kodu derledim ve çalıştırdım ve döngü süresiz olarak devam ediyor. Clang-9 kullanılarak derlendi:

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

Boş bir whiledöngünün sistem üzerinde herhangi bir yan etkisi yoktur.

Bu yüzden Clang onu kaldırır. Sizi niyetlerinizden daha belirgin olmaya zorlayan amaçlanan davranışa ulaşmanın "daha iyi" yolları vardır.

while(1); baaadd.