Jak utworzyć nieskończoną pustą pętlę, która nie zostanie zoptymalizowana?

Standard C11 wydaje się sugerować, że instrukcje iteracji ze stałymi wyrażeniami kontrolującymi nie powinny być optymalizowane. Czerpię radę z tej odpowiedzi , która konkretnie cytuje sekcję 6.8.5 projektu standardu:

Instrukcja iteracji, której wyrażenie kontrolne nie jest wyrażeniem stałym ... może zostać przyjęte przez implementację jako zakończona.

W tej odpowiedzi wspomniano, że taka pętla while(1) ;nie powinna podlegać optymalizacji.

Więc ... dlaczego Clang / LLVM optymalizuje poniższą pętlę (z kompilacją 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");
}

Na mojej maszynie drukuje się begin, a następnie ulega awarii na niedozwolonej instrukcji ( ud2pułapka umieszczona po die()). W Godbolt możemy zobaczyć, że nic nie jest generowane po wezwaniu do puts.

Zaskakująco trudne zadanie sprawiło, że Clang wyprowadził nieskończoną pętlę poniżej -O2- podczas gdy mogłem wielokrotnie testować volatilezmienną, która wymaga odczytu pamięci, którego nie chcę. A jeśli zrobię coś takiego:

#include <stdio.h>

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

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

... Odbitki Clanga, begina po nich unreachablejakby nieskończona pętla nigdy nie istniała.

Jak sprawić, by Clang wyprowadził prawidłową nieskończoną pętlę bez dostępu do pamięci z włączonymi optymalizacjami?

Norma C11 mówi 6.8.5 / 6:

Instrukcja iteracyjna, której wyrażenie kontrolne nie jest wyrażeniem stałym, ^156), które nie wykonuje żadnych operacji wejścia / wyjścia, nie ma dostępu do obiektów lotnych i nie wykonuje żadnych synchronizacji ani operacji atomowych w swoim ciele, kontroluje wyrażenie lub (w przypadku instrukcja) jego wyrażenie-3 może zostać przyjęte przez implementację jako zakończone. ¹⁵⁷⁾

Dwie nuty nie są normatywne, ale dostarczają przydatnych informacji:

156) Pominięte wyrażenie kontrolne jest zastępowane niezerową stałą, która jest wyrażeniem stałym.

157) Ma to na celu umożliwienie transformacji kompilatora, takich jak usuwanie pustych pętli, nawet jeśli nie można udowodnić zakończenia.

W twoim przypadku while(1)jest to krystalicznie czyste stałe wyrażenie, więc implementacja nie może założyć, że zakończy się. Taka implementacja byłaby beznadziejnie zepsuta, ponieważ pętle „na zawsze” są powszechną konstrukcją programistyczną.

O ile wiem, co dzieje się z „nieosiągalnym kodem” po pętli, nie jest dobrze zdefiniowane. Jednak klang rzeczywiście zachowuje się bardzo dziwnie. Porównanie kodu maszynowego z 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

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

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

gcc generuje pętlę, clang po prostu wpada do lasu i kończy pracę z błędem 255.

Pochylam się nad tym, że zachowanie klangu jest niezgodne z przeznaczeniem. Ponieważ próbowałem rozszerzyć twój przykład w ten sposób:

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

Dodałem C11, _Noreturnaby pomóc kompilatorowi dalej. Powinno być jasne, że ta funkcja się rozłączy, na podstawie samego słowa kluczowego.

setjmpzwróci 0 po pierwszym uruchomieniu, więc ten program powinien po prostu uderzyć w while(1)i zatrzymać się tam, wypisując tylko „start” (zakładając, że \ n opróżnia standardowe wyjście). Dzieje się tak z gcc.

Jeśli pętla została po prostu usunięta, powinna wypisać „rozpocząć” 2 razy, a następnie wydrukować „nieosiągalny”. Jednak w przypadku clang ( godbolt ) wypisuje „ start ” 1 raz, a następnie „nieosiągalny” przed zwróceniem kodu wyjścia 0. To po prostu źle, bez względu na to, jak to określisz.

Nie mogę znaleźć tutaj powodu do twierdzenia o nieokreślonym zachowaniu, więc uważam, że jest to błąd. W każdym razie takie zachowanie sprawia, że ​​clang jest w 100% bezużyteczny dla programów takich jak systemy wbudowane, w których po prostu musisz polegać na wiecznych pętlach zawieszających program (podczas oczekiwania na watchdoga itp.).

Musisz wstawić wyrażenie, które może powodować efekt uboczny.

Najprostsze rozwiązanie:

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

Link Godbolt

Inne odpowiedzi zawierały już sposoby na to, aby Clang emitował nieskończoną pętlę z wbudowanym językiem asemblera lub innymi efektami ubocznymi. Chcę tylko potwierdzić, że to rzeczywiście błąd kompilatora. W szczególności jest to długotrwały błąd LLVM - stosuje koncepcję C ++ „wszystkie pętle bez efektów ubocznych muszą się kończyć” w językach, w których nie powinien, takich jak C.

Na przykład język programowania Rust pozwala również na nieskończone pętle i wykorzystuje LLVM jako backend i ma ten sam problem.

W krótkim okresie wydaje się, że LLVM będzie nadal zakładać, że „wszystkie pętle bez skutków ubocznych muszą się zakończyć”. Dla każdego języka, który zezwala na nieskończone pętle, LLVM oczekuje, że front-end wstawi llvm.sideeffectkody do takich pętli. To właśnie planuje zrobić Rust, więc Clang (podczas kompilacji kodu C) prawdopodobnie będzie musiał to zrobić.

To jest błąd Clanga

... podczas wstawiania funkcji zawierającej nieskończoną pętlę. Zachowanie jest inne, gdy while(1);pojawia się bezpośrednio w głównym, który pachnie dla mnie bardzo błędnie.

Zobacz odpowiedź @ Arnavion na podsumowanie i linki. Reszta tej odpowiedzi została napisana, zanim otrzymałem potwierdzenie, że był to błąd, a tym bardziej znany błąd.

Aby odpowiedzieć na pytanie tytułowe: Jak utworzyć nieskończoną pustą pętlę, która nie będzie zoptymalizowana? ? -
utworzyć die()makro, a nie funkcję , aby obejść ten błąd w Clang 3.9 i nowszych. (Wcześniejsze wersje Clanga albo utrzymywały pętlę, albo wysyłały „a”call do nieliniowej wersji funkcji z nieskończoną pętlą.) Wydaje się to bezpieczne, nawet jeśli print;while(1);print;funkcja włącza się w jej wywołującym ( Godbolt ). -std=gnu11vs. -std=gnu99nic nie zmienia.

Jeśli zależy ci tylko na GNU C, P__J ____asm__(""); wewnątrz pętli również działa i nie powinno zaszkodzić optymalizacji żadnego otaczającego kodu dla żadnego kompilatora, który go rozumie. Podstawowe instrukcje asm GNU C Basic są domyślnievolatile , więc liczy się to jako widoczny efekt uboczny, który musi „wykonać” tyle razy, ile by to miało miejsce w maszynie abstrakcyjnej C. (I tak, Clang implementuje dialekt GNU języka C, jak udokumentowano w instrukcji GCC.)

Niektórzy twierdzą, że optymalizacja pustej nieskończonej pętli może być legalna. Nie zgadzam się ¹ , ale nawet jeśli to zaakceptujemy, Clang nie może również legalnie zakładać, że instrukcje po osiągnięciu pętli są nieosiągalne, i pozwolić , aby wykonanie spadło z końca funkcji do następnej lub do śmieci który dekoduje jako losowe instrukcje.

(Byłoby to zgodne ze standardami dla Clang ++ (ale nadal niezbyt przydatne); nieskończone pętle bez żadnych skutków ubocznych są UB w C ++, ale nie C.
Jest while (1); niezdefiniowane zachowanie w C? UB pozwala kompilatorowi emitować praktycznie wszystko dla kodu na ścieżce wykonania, która na pewno napotka UB. asmInstrukcja w pętli unikałaby tego UB dla C ++. Ale w praktyce Clang kompiluje jako C ++ nie usuwa nieskończonych pustych pętli o stałym wyrażeniu, z wyjątkiem wstawiania, tak jak wtedy, gdy kompilacja jako C.)

Ręczne wstawianie while(1);zmienia sposób kompilacji Clanga: nieskończona pętla obecna w asm. Tego oczekujemy od prawnika POV.

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

W eksploratorze kompilatorów Godbolt Clang 9.0 -O3 kompiluje się jako C ( -xc) dla 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"

Ten sam kompilator z tymi samymi opcjami kompiluje najpierw ten , mainktóry wywołuje infloop() { while(1); }ten sam puts, ale potem przestaje wydawać instrukcje dla maintego punktu. Tak jak powiedziałem, wykonanie po prostu spada z końca funkcji, do dowolnej funkcji, która będzie następna (ale przy stosie przesuniętym względem wejścia funkcji, więc nie jest to nawet poprawne wywołanie ogona).

Prawidłowe opcje to

• emitują label: jmp labelnieskończoną pętlę
• lub (jeśli zaakceptujemy, że nieskończona pętla może zostać usunięta) wysyłamy kolejne wywołanie, aby wydrukować 2. ciąg, a następnie return 0z main.

Awaria lub kontynuacja bez drukowania „nieosiągalnego” najwyraźniej nie jest odpowiednia dla implementacji C11, chyba że istnieje UB, którego nie zauważyłem.

Przypis 1:

Dla przypomnienia, zgadzam się z odpowiedzią @ Lundin, która przytacza standard dla dowodów, że C11 nie pozwala na założenie zakończenia dla nieskończonych pętli o stałym wyrażeniu, nawet gdy są one puste (brak we / wy, niestabilność, synchronizacja lub inne widoczne efekty uboczne).

Jest to zestaw warunków, które pozwoliłyby skompilować pętlę do pustej pętli asm dla normalnego procesora. (Nawet jeśli treść nie była pusta w źródle, przypisania do zmiennych nie mogą być widoczne dla innych wątków lub procedur obsługi sygnałów bez UB wyścigu danych, gdy pętla jest uruchomiona. Zatem zgodna implementacja mogłaby usunąć takie treści pętli, gdyby chciała To pozostawia pytanie, czy samą pętlę można usunąć. ISO C11 wyraźnie mówi nie.)

Biorąc pod uwagę, że C11 wyróżnia ten przypadek jako przypadek, w którym implementacja nie może zakładać, że pętla się kończy (i że nie jest to UB), wydaje się jasne, że zamierzają być obecni w pętli w czasie wykonywania. Implementacja ukierunkowana na procesory z modelem wykonania, który nie może wykonać nieskończonej ilości pracy w skończonym czasie, nie ma uzasadnienia dla usuwania pustej stałej pętli nieskończonej. Lub nawet ogólnie, dokładne sformułowanie dotyczy tego, czy można je „założyć, że wygasną”, czy nie. Jeśli pętla nie może się zakończyć, oznacza to, że późniejszy kod jest nieosiągalny, bez względu na argumenty dotyczące matematyki i nieskończoności oraz czas potrzebny na wykonanie nieskończonej ilości pracy na jakiejś hipotetycznej maszynie.

Co więcej, Clang nie jest jedynie DeathStation 9000 zgodnym z ISO C, ale ma być przydatny do programowania systemów niskopoziomowych w świecie rzeczywistym, w tym do jąder i osadzonych elementów. Niezależnie od tego, czy akceptujesz argumenty dotyczące C11 zezwalające na usunięcie while(1);, nie ma sensu, aby Clang chciał to zrobić. Jeśli napiszesz while(1);, to prawdopodobnie nie był wypadek. Usuwanie pętli, które przypadkowo kończą się nieskończonością (z wyrażeniami kontrolnymi zmiennych wykonawczych), może być przydatne i ma to sens dla kompilatorów.

Rzadko zdarza się, że chcesz się kręcić do następnego przerwania, ale jeśli napiszesz to w C, to na pewno tego się spodziewasz. (I co dzieje się w GCC i Clang, z wyjątkiem Clanga, gdy nieskończona pętla znajduje się w funkcji otoki).

Na przykład w prymitywnym jądrze systemu operacyjnego, gdy program planujący nie ma zadań do uruchomienia, może uruchomić zadanie bezczynne. Pierwszą implementacją tego może być while(1);.

Lub w przypadku sprzętu bez funkcji bezczynności oszczędzania energii, może to być jedyna implementacja. (Do wczesnych lat 2000., tak myślę, nie było to rzadkie na x86. Chociaż hltinstrukcja istniała, IDK jeśli oszczędzał znaczącą ilość energii, dopóki procesory nie zaczęły mieć stanów bezczynności o niskiej mocy).

Dla przypomnienia Clang również źle się zachowuje goto:

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

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

Daje takie same wyniki jak w pytaniu, tj .:

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

Widzę, że nie widzę żadnego sposobu, aby odczytać to jako dozwolone w C11, który mówi tylko:

6.8.6.1 (2) gotoInstrukcja powoduje bezwarunkowy skok do instrukcji poprzedzonej nazwaną etykietą w funkcji zamykającej.

Ponieważ gotonie jest to „oświadczenie iteracja” (6.8.5 listy while, doa for) nic o specjalnej „ustanie-zakłada” odpusty stosuje się jednak chcesz je przeczytać.

Według oryginalnego pytania kompilator Godbolt link to x86-64 Clang 9.0.0 i flagi są -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

Z innymi, takimi jak x86-64 GCC 9.2, otrzymujesz całkiem nieźle idealny:

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

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

Wcielę się w adwokata diabła i argumentuję, że standard nie zabrania kompilatorowi optymalizacji nieskończonej pętli.

Instrukcja iteracyjna, której wyrażenie kontrolne nie jest wyrażeniem stałym, 156), które nie wykonuje żadnych operacji wejścia / wyjścia, nie ma dostępu do obiektów lotnych i nie wykonuje żadnych synchronizacji ani operacji atomowych w swoim ciele, kontroluje wyrażenie lub (w przypadku instrukcja) jego wyrażenie-3 może zostać przyjęte przez implementację jako terminate.157)

Przeanalizujmy to. Można przyjąć, że wypowiedź iteracyjna, która spełnia określone kryteria, kończy się:

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

Nie mówi to nic o tym, co się stanie, jeśli kryteria nie zostaną spełnione, a zakładanie, że pętla może się zakończyć nawet wtedy nie jest wyraźnie zabronione, o ile przestrzegane są inne reguły standardu.

do { } while(0)lub while(0){}są przecież instrukcjami iteracyjnymi (pętlami), które nie spełniają kryteriów, które pozwalają kompilatorowi na przyjęcie kaprysu, że kończą, a jednak oczywiście kończą.

Ale czy kompilator może po prostu zoptymalizować while(1){}?

5.1.2.3p4 mówi:

W maszynie abstrakcyjnej wszystkie wyrażenia są obliczane zgodnie z semantyką. Rzeczywista implementacja nie musi oceniać części wyrażenia, jeśli można wywnioskować, że jego wartość nie jest używana i że nie powstają żadne potrzebne skutki uboczne (w tym wszelkie wywołane wywołaniem funkcji lub dostępem do lotnego obiektu).

Wspomina o wyrażeniach, a nie o wyrażeniach, więc nie jest w 100% przekonujący, ale z pewnością umożliwia wywołania takie jak:

void loop(void){ loop(); }

int main()
{
    loop();
}

do pominięcia. Co ciekawe, clang go pomija, a gcc nie .

Byłem przekonany, że to zwykły stary błąd. Moje testy zostawiam poniżej, w szczególności odniesienie do dyskusji w komisji standardowej z pewnych powodów, które wcześniej miałem.

Myślę, że jest to niezdefiniowane zachowanie (patrz koniec), a Clang ma tylko jedną implementację. GCC rzeczywiście działa zgodnie z oczekiwaniami, optymalizując tylko instrukcję unreachableprint, ale pozostawiając pętlę. Trochę dziwnego sposobu, w jaki Clang dziwnie podejmuje decyzje, łącząc wstawianie i określając, co może zrobić z pętlą.

Zachowanie jest wyjątkowo dziwne - usuwa końcowy nadruk, więc „widzi” nieskończoną pętlę, ale także pozbywa się jej.

O ile mogę powiedzieć, jest jeszcze gorzej. Usuwając wstawkę otrzymujemy:

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"

więc funkcja została utworzona, a połączenie zoptymalizowane. Jest to nawet bardziej odporne niż oczekiwano:

#include <stdio.h>

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

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

skutkuje bardzo nieoptymalnym zestawem funkcji, ale wywołanie funkcji jest ponownie zoptymalizowane! Nawet gorzej:

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

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

Zrobiłem kilka innych testów, dodając zmienną lokalną i zwiększając ją, przekazując wskaźnik, używając gotoetc ... W tym momencie zrezygnowałem. Jeśli musisz użyć clang

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

wykonuje pracę. Jest do bani w optymalizacji (oczywiście) i pozostawia zbędny finał printf. Przynajmniej program się nie zatrzymuje. Może w końcu GCC?

Uzupełnienie

Po dyskusji z Davidem stwierdzam, że standard nie mówi „jeśli warunek jest stały, możesz nie założyć, że pętla się kończy”. Jako taki, i zgodnie ze standardem nie ma obserwowalnego zachowania (jak zdefiniowano w standardzie), argumentowałbym tylko za spójnością - jeśli kompilator optymalizuje pętlę, ponieważ zakłada, że ​​się kończy, nie powinien optymalizować następujących instrukcji.

Heck n1528 ma to jako niezdefiniowane zachowanie, jeśli dobrze to przeczytam. konkretnie

Głównym problemem jest to, że pozwala on na przemieszczanie się kodu w potencjalnie nie kończącej się pętli

Odtąd myślę, że może ona przerodzić się w dyskusję o tym, czego chcemy (oczekiwaliśmy?), A nie o to, co jest dozwolone.

Wygląda na to, że jest to błąd w kompilatorze Clanga. Jeśli nie ma żadnego przymusu, aby die()funkcja była funkcją statyczną, usuń ją statici zrób to inline:

#include <stdio.h>

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

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

Działa zgodnie z oczekiwaniami po kompilacji z kompilatorem Clang, a także jest przenośny.

Eksplorator kompilatorów (godbolt.org) - klang 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"

Wydaje się, że dla mnie działają:

#include <stdio.h>

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

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

w godbolt

Jawne mówienie Clangowi, aby nie optymalizował, że jedna funkcja powoduje, że nieskończona pętla jest emitowana zgodnie z oczekiwaniami. Mamy nadzieję, że istnieje sposób, aby selektywnie wyłączyć poszczególne optymalizacje zamiast po prostu je wszystkie wyłączyć. Jednak Clang nadal odmawia wydania kodu dla drugiego printf. Aby to zmusić, musiałem dodatkowo zmodyfikować kod wewnątrz, mainaby:

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

Wygląda na to, że musisz wyłączyć optymalizacje dla funkcji nieskończonej pętli, a następnie upewnić się, że twoja nieskończona pętla jest wywoływana warunkowo. W prawdziwym świecie i tak jest to prawie zawsze.

Implementacja zgodna może, i wiele praktycznych, może narzucić dowolne limity czasu trwania programu lub liczby instrukcji, które wykona, i zachowywać się w sposób arbitralny, jeśli limity te zostaną naruszone lub - zgodnie z zasadą „jak gdyby” - jeśli stwierdzi, że zostaną one nieuchronnie naruszone. Pod warunkiem, że wdrożenie może z powodzeniem przetworzyć co najmniej jeden program, który nominalnie wykonuje wszystkie limity wymienione w N1570 5.2.4.1, nie przekraczając żadnych limitów translacji, istnienia limitów, zakresu ich udokumentowania i skutków ich przekroczenia są: wszystkie kwestie dotyczące jakości wdrożenia poza jurysdykcją normy.

Myślę, że intencja Standardu jest całkiem jasna, że ​​kompilatory nie powinny zakładać, że while(1) {}pętla bez efektów ubocznych i breakinstrukcji nie zostanie zakończona. Wbrew temu, co niektórzy mogą sądzić, autorzy Standardu nie zapraszali pisarzy kompilatorów, aby byli głupi lub tępi. Implementacja zgodna może być przydatna do podjęcia decyzji o zakończeniu dowolnego programu, który, jeśli nie zostanie przerwany, wykona więcej instrukcji wolnych od skutków ubocznych niż atomów we wszechświecie, ale implementacja wysokiej jakości nie powinna wykonywać takich działań na podstawie jakichkolwiek założeń dotyczących zakończenie, ale raczej na tej podstawie, że może to być przydatne i nie byłoby (w przeciwieństwie do zachowania klanu) gorsze niż bezużyteczne.

Pętla nie ma skutków ubocznych, dlatego można ją zoptymalizować. Pętla jest w rzeczywistości nieskończoną liczbą iteracji zerowych jednostek pracy. Jest to niezdefiniowane w matematyce i logice, a standard nie mówi, czy implementacja jest dozwolona do wykonania nieskończonej liczby rzeczy, jeśli każda rzecz może być wykonana w czasie zerowym. Interpretacja Clanga jest całkowicie rozsądna w traktowaniu nieskończoności razy zero jako nieskończoności. Standard nie mówi, czy nieskończona pętla może się zakończyć, jeśli cała praca w pętli zostanie faktycznie zakończona.

Kompilator może optymalizować wszystko, co nie jest możliwe do zaobserwowania, zgodnie z definicją zawartą w standardzie. Obejmuje to czas wykonania. Nie jest konieczne zachowanie faktu, że pętla, jeśli nie zostanie zoptymalizowana, zajmie nieskończoną ilość czasu. Dozwolone jest zmienianie tego na znacznie krótszy czas działania - w rzeczywistości jest to punkt większości optymalizacji. Twoja pętla została zoptymalizowana.

Nawet jeśli clang przetłumaczył kod naiwnie, można sobie wyobrazić optymalizujący procesor, który może ukończyć każdą iterację w połowie czasu poprzedniej iteracji. To dosłownie uzupełniłoby nieskończoną pętlę w skończonym czasie. Czy taki optymalizujący procesor narusza standard? Absurdalne wydaje się stwierdzenie, że optymalizujący procesor naruszyłby standard, jeśli jest zbyt dobry w optymalizacji. To samo dotyczy kompilatora.

Przepraszam, jeśli tak absurdalnie nie jest, natknąłem się na ten post i wiem, ponieważ moje lata z dystrybucją Gentoo Linux, że jeśli chcesz, aby kompilator nie zoptymalizował twojego kodu, powinieneś użyć opcji -O0 (zero). Byłem ciekawy tego, skompilowałem i uruchomiłem powyższy kod, a pętla robi się bez końca. Kompilacja przy użyciu clang-9:

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

Pusta whilepętla nie ma żadnych skutków ubocznych w systemie.

Dlatego Clang go usuwa. Istnieją „lepsze” sposoby osiągnięcia zamierzonego zachowania, które zmuszają cię do bardziej oczywistych zamiarów.

while(1); jest baaadd.