Comment créer une boucle vide infinie qui ne sera pas optimisée?

La norme C11 semble impliquer que les instructions d'itération avec des expressions de contrôle constantes ne doivent pas être optimisées. Je prends mon conseil de cette réponse , qui cite spécifiquement la section 6.8.5 du projet de norme:

Une instruction d'itération dont l'expression de contrôle n'est pas une expression constante ... peut être supposée par l'implémentation se terminer.

Dans cette réponse, il mentionne qu'une boucle comme celle- while(1) ;ci ne devrait pas être soumise à l'optimisation.

Alors ... pourquoi Clang / LLVM optimise-t-il la boucle ci-dessous (compilée avec 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");
}

Sur ma machine, cela s'imprime begin, puis se bloque sur une instruction illégale (un ud2piège placé après die()). Sur godbolt , nous pouvons voir que rien n'est généré après l'appel à puts.

Cela a été une tâche étonnamment difficile d'obtenir que Clang produise une boucle infinie sous -O2- alors que je pouvais tester à plusieurs reprises une volatilevariable, ce qui implique une lecture en mémoire que je ne veux pas. Et si je fais quelque chose comme ça:

#include <stdio.h>

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

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

... Clang imprime beginsuivi unreachablecomme si la boucle infinie n'avait jamais existé.

Comment obtenir Clang pour produire une boucle infinie sans accès à la mémoire appropriée avec les optimisations activées?

La norme C11 le dit, 6.8.5 / 6:

Une instruction d'itération dont l'expression de contrôle n'est pas une expression constante, ¹⁵⁶⁾ qui n'effectue aucune opération d'entrée / sortie, n'accède pas aux objets volatils et n'effectue aucune synchronisation ou opération atomique dans son corps, contrôlant l'expression ou (dans le cas d'un pour ), son expression-3, peut être supposée par l'implémentation se terminer. ¹⁵⁷⁾

Les deux notes de bas de page ne sont pas normatives mais fournissent des informations utiles:

156) Une expression de contrôle omise est remplacée par une constante non nulle, qui est une expression constante.

157) Ceci est destiné à permettre des transformations du compilateur telles que la suppression de boucles vides même lorsque la terminaison ne peut pas être prouvée.

Dans votre cas, while(1)est une expression constante limpide, donc l'implémentation ne peut pas être considérée comme terminée. Une telle implémentation serait désespérément interrompue, car les boucles "pour toujours" sont une construction de programmation courante.

Ce qui arrive au "code inaccessible" après la boucle n'est cependant pas, à ma connaissance, bien défini. Cependant, le clang se comporte en effet très étrangement. Comparaison du code machine avec 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 génère la boucle, clang court juste dans les bois et se termine avec l'erreur 255.

Je penche pour que ce soit un comportement non conforme de clang. Parce que j'ai essayé de développer votre exemple comme ceci:

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

J'ai ajouté C11 _Noreturnpour essayer d'aider le compilateur plus loin. Il doit être clair que cette fonction va raccrocher, à partir de ce seul mot-clé.

setjmprenverra 0 lors de la première exécution, donc ce programme devrait juste s'écraser sur le while(1)et s'arrêter là, n'imprimant que "begin" (en supposant que \ n vide la sortie standard). Cela se produit avec gcc.

Si la boucle a été simplement supprimée, elle devrait imprimer "commencer" 2 fois puis imprimer "inaccessible". Cependant, sur clang ( godbolt ), il imprime "begin" 1 fois puis "inaccessible" avant de retourner le code de sortie 0. C'est tout simplement faux, peu importe comment vous le mettez.

Je ne trouve aucun argument pour revendiquer un comportement indéfini ici, donc je pense que c'est un bogue dans Clang. En tout cas, ce comportement rend clang 100% inutile pour des programmes comme les systèmes embarqués, où vous devez simplement pouvoir compter sur des boucles éternelles suspendant le programme (en attendant un chien de garde, etc.).

Vous devez insérer une expression susceptible de provoquer un effet secondaire.

La solution la plus simple:

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

Lien Godbolt

D'autres réponses ont déjà couvert les moyens de faire émettre Clang la boucle infinie, avec le langage d'assemblage en ligne ou d'autres effets secondaires. Je veux juste confirmer qu'il s'agit bien d'un bug du compilateur. Plus précisément, il s'agit d' un bogue LLVM de longue date - il applique le concept C ++ de «toutes les boucles sans effets secondaires doivent se terminer» aux langages où il ne devrait pas, comme C.

Par exemple, le langage de programmation Rust autorise également des boucles infinies et utilise LLVM comme backend, et il a ce même problème.

À court terme, il semble que LLVM continuera de supposer que "toutes les boucles sans effets secondaires doivent se terminer". Pour tout langage autorisant des boucles infinies, LLVM s'attend à ce que le frontal insère des llvm.sideeffectopcodes dans ces boucles. C'est ce que Rust prévoit de faire, donc Clang (lors de la compilation du code C) devra probablement le faire aussi.

Ceci est un bug Clang

... lors de l'insertion d'une fonction contenant une boucle infinie. Le comportement est différent lorsqu'il while(1);apparaît directement en main, ce qui me sent très bogué.

Voir la réponse de @ Arnavion pour un résumé et des liens. Le reste de cette réponse a été écrit avant que je ne confirme que c'était un bug, encore moins un bug connu.

Pour répondre à la question du titre: Comment créer une boucle vide infinie qui ne sera pas optimisée? ? -
créer die()une macro, pas une fonction , pour contourner ce bogue dans Clang 3.9 et versions ultérieures. (Les versions antérieures de Clang conservent la boucle ou émettent uncall vers une version non en ligne de la fonction avec la boucle infinie.) Cela semble être sûr même si la print;while(1);print;fonction s'aligne dans son appelant ( Godbolt ). -std=gnu11vs -std=gnu99ne change rien.

Si vous ne vous souciez que de GNU C, P__J____asm__(""); à l'intérieur de la boucle fonctionne également, et ne devrait pas nuire à l'optimisation du code environnant pour les compilateurs qui le comprennent. Les instructions asm GNU C Basic sont implicitementvolatile , donc cela compte comme un effet secondaire visible qui doit "s'exécuter" autant de fois que dans la machine abstraite C. (Et oui, Clang implémente le dialecte GNU de C, comme documenté par le manuel GCC.)

Certaines personnes ont fait valoir qu'il pourrait être légal d'optimiser une boucle infinie vide. Je ne suis pas d'accord ¹ , mais même si nous acceptons cela, il ne peut pas également être légal pour Clang de supposer que les instructions après que la boucle soit inaccessible, et de laisser l'exécution tomber de la fin de la fonction dans la fonction suivante, ou dans les ordures qui décode comme des instructions aléatoires.

(Ce serait conforme aux normes pour Clang ++ (mais toujours pas très utile); les boucles infinies sans aucun effet secondaire sont UB en C ++, mais pas C.
Is while (1); comportement indéfini en C? UB permet au compilateur d'émettre pratiquement n'importe quoi pour le code sur un chemin d'exécution qui rencontrera certainement l'UB. Une asminstruction dans la boucle éviterait cet UB pour C ++. Mais dans la pratique, la compilation de Clang en C ++ ne supprime pas les boucles vides infinies d'expression constante, sauf en ligne, comme lorsque compilation en C.)

L'intégration manuelle while(1);modifie la façon dont Clang le compile: boucle infinie présente dans asm. C'est ce que nous attendons d'un PDV de règles-avocat.

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

Sur l'explorateur du compilateur Godbolt , Clang 9.0 -O3 se compile en C ( -xc) pour 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"

Le même compilateur avec les mêmes options compile un mainqui appelle infloop() { while(1); }d'abord le même puts, mais arrête ensuite d'émettre des instructions pour mainaprès ce point. Donc, comme je l'ai dit, l'exécution tombe juste de la fin de la fonction, quelle que soit la fonction suivante (mais avec la pile mal alignée pour l'entrée de la fonction, ce n'est donc même pas un appel valide).

Les options valables seraient de

• émettre une label: jmp labelboucle infinie
• ou (si nous acceptons que la boucle infinie puisse être supprimée) émettre un autre appel pour imprimer la 2ème chaîne, puis à return 0partir de main.

Crasher ou continuer sans imprimer "inaccessible" n'est clairement pas acceptable pour une implémentation C11, sauf s'il y a UB que je n'ai pas remarqué.

Note de bas de page 1:

Pour mémoire, je suis d'accord avec la réponse de @ Lundin qui cite la norme pour prouver que C11 ne permet pas l'hypothèse de terminaison pour les boucles infinies à expression constante, même lorsqu'elles sont vides (pas d'E / S, volatiles, synchronisation, ou autre effets secondaires visibles).

Il s'agit de l'ensemble de conditions permettant de compiler une boucle en une boucle asm vide pour un processeur normal. (Même si le corps n'était pas vide dans la source, les affectations aux variables ne peuvent pas être visibles par les autres threads ou les gestionnaires de signaux sans UB de course de données pendant que la boucle est en cours d'exécution. Une implémentation conforme pourrait donc supprimer ces corps de boucle si elle le voulait Ensuite, cela laisse la question de savoir si la boucle elle-même peut être supprimée. ISO C11 dit explicitement non.)

Étant donné que C11 distingue ce cas comme un cas où l'implémentation ne peut pas supposer que la boucle se termine (et que ce n'est pas UB), il semble clair qu'ils ont l'intention que la boucle soit présente au moment de l'exécution. Une implémentation qui cible les processeurs avec un modèle d'exécution qui ne peut pas faire une quantité infinie de travail en temps fini n'a aucune justification pour supprimer une boucle infinie constante vide. Ou même en général, la formulation exacte consiste à savoir si elles peuvent être "supposées se terminer" ou non. Si une boucle ne peut pas se terminer, cela signifie que le code ultérieur n'est pas accessible, quels que soient les arguments que vous faites sur les mathématiques et les infinis et combien de temps il faut pour effectuer une quantité infinie de travail sur une machine hypothétique.

De plus, Clang n'est pas simplement une DeathStation 9000 conforme à la norme ISO C, il est destiné à être utile pour la programmation de systèmes de bas niveau dans le monde réel, y compris les noyaux et les éléments intégrés. Donc , si vous acceptiez ou non des arguments au sujet de C11 permettant la suppression de while(1);, il ne fait pas de sens que Clang voudrait réellement faire cela. Si vous écrivez while(1);, ce n'était probablement pas un accident. La suppression des boucles qui finissent par être infinies par accident (avec des expressions de contrôle de variable d'exécution) peut être utile, et il est logique que les compilateurs le fassent.

Il est rare que vous vouliez simplement tourner jusqu'à la prochaine interruption, mais si vous écrivez cela en C, c'est certainement ce que vous attendez. (Et ce qui se passe dans GCC et Clang, sauf pour Clang lorsque la boucle infinie est à l'intérieur d'une fonction wrapper).

Par exemple, dans un noyau de système d'exploitation primitif, lorsque le planificateur n'a aucune tâche à exécuter, il peut exécuter la tâche inactive. Une première implémentation de cela pourrait être while(1);.

Ou pour le matériel sans aucune fonction d'économie d'énergie, cela pourrait être la seule implémentation. (Jusqu'au début des années 2000, c'était je pense pas rare sur x86. Bien que l' hltinstruction existait, IDK si elle économisait une quantité significative d'énergie jusqu'à ce que les processeurs commencent à avoir des états de veille à faible puissance.)

Juste pour mémoire, Clang se comporte également mal avec goto:

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

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

Il produit le même résultat que dans la question, c'est-à-dire:

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

Je ne vois aucun moyen de lire ceci comme autorisé dans C11, qui dit seulement:

6.8.6.1 (2) Une gotoinstruction provoque un saut inconditionnel à l'instruction préfixée par l'étiquette nommée dans la fonction englobante.

Comme goton'est pas une « déclaration d'itération » (6.8.5 listes while, doet for) rien indulgences appliquer « pris terminaison » spéciale, mais vous voulez les lire.

Le compilateur de liens Godbolt de la question d'origine est x86-64 Clang 9.0.0 et les drapeaux sont -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

Avec d'autres tels que x86-64 GCC 9.2, vous obtenez le parfait:

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

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

Je jouerai l'avocat du diable et soutiendrai que la norme n'interdit pas explicitement à un compilateur d'optimiser une boucle infinie.

Une instruction d'itération dont l'expression de contrôle n'est pas une expression constante, 156) qui n'effectue aucune opération d'entrée / sortie, n'accède pas aux objets volatils et n'effectue aucune synchronisation ou opération atomique dans son corps, contrôlant l'expression ou (dans le cas d'un pour ), son expression-3, peut être supposée par l'implémentation se terminer.157)

Analysons cela. Une instruction d'itération qui satisfait certains critères peut être supposée se terminer:

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

Cela ne dit rien sur ce qui se passe si les critères ne sont pas satisfaits et supposer qu'une boucle peut se terminer même alors n'est pas explicitement interdit tant que d'autres règles de la norme sont respectées.

do { } while(0)ou while(0){}sont après tout des instructions d'itération (boucles) qui ne satisfont pas aux critères qui permettent à un compilateur de simplement supposer sur un coup de tête qu'elles se terminent et pourtant elles se terminent évidemment.

Mais le compilateur peut-il tout simplement optimiser while(1){}?

5.1.2.3p4 dit:

Dans la machine abstraite, toutes les expressions sont évaluées comme spécifié par la sémantique. Une implémentation réelle n'a pas besoin d'évaluer une partie d'une expression si elle peut en déduire que sa valeur n'est pas utilisée et qu'aucun effet secondaire nécessaire n'est produit (y compris ceux provoqués par l'appel d'une fonction ou l'accès à un objet volatil).

Cela mentionne des expressions, pas des déclarations, donc ce n'est pas convaincant à 100%, mais cela permet certainement des appels comme:

void loop(void){ loop(); }

int main()
{
    loop();
}

à sauter. Fait intéressant, clang le saute, et gcc ne le fait pas .

J'ai été convaincu que ce n'est qu'un simple vieux bug. Je laisse mes tests ci-dessous et en particulier la référence à la discussion au sein du comité standard pour certains raisonnements que j'avais précédemment.

Je pense que c'est un comportement indéfini (voir fin), et Clang n'a qu'une seule implémentation. GCC fonctionne en effet comme vous vous y attendez, optimisant uniquement l' unreachableinstruction print mais laissant la boucle. Certains comment Clang prend étrangement des décisions en combinant la doublure et en déterminant ce qu'elle peut faire avec la boucle.

Le comportement est très étrange - il supprime l'impression finale, donc "voir" la boucle infinie, mais aussi se débarrasser de la boucle.

C'est encore pire pour autant que je sache. Suppression de l'inline que nous obtenons:

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"

de sorte que la fonction est créée et l'appel optimisé. C'est encore plus résistant que prévu:

#include <stdio.h>

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

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

entraîne un assemblage très non optimal pour la fonction, mais l'appel de fonction est à nouveau optimisé! Encore pire:

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

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

J'ai fait un tas d'autres tests en ajoutant une variable locale et en l'augmentant, en passant un pointeur, en utilisant un gotoetc ... À ce stade, j'abandonnerais. Si vous devez utiliser clang

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

Fait le travail. Il aspire à l'optimisation (évidemment), et part en finale redondante printf. Au moins, le programme ne s'arrête pas. Peut-être GCC après tout?

Addenda

Après discussion avec David, je cède que la norme ne dit pas "si la condition est constante, vous ne pouvez pas supposer que la boucle se termine". En tant que tel, et conformément à la norme, il n'y a pas de comportement observable (tel que défini dans la norme), je ne plaiderais que pour la cohérence - si un compilateur optimise une boucle parce qu'il suppose qu'elle se termine, il ne doit pas optimiser les instructions suivantes.

Heck n1528 a ces comportements indéfinis si je lis bien. Plus précisément

Un problème majeur pour cela est qu'il permet au code de se déplacer à travers une boucle potentiellement non terminante

À partir de là, je pense que cela ne peut se résumer qu'à une discussion de ce que nous voulons (attendu?) Plutôt que de ce qui est autorisé.

Il semble que ce soit un bug dans le compilateur Clang. S'il n'y a aucune contrainte sur la die()fonction d'être une fonction statique, supprimez-la staticet faites-la inline:

#include <stdio.h>

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

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

Il fonctionne comme prévu lorsqu'il est compilé avec le compilateur Clang et est également portable.

Explorateur du compilateur (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"

Les éléments suivants semblent fonctionner pour moi:

#include <stdio.h>

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

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

à godbolt

Dire explicitement à Clang de ne pas optimiser qu'une fonction entraîne l'émission d'une boucle infinie comme prévu. Espérons qu'il existe un moyen de désactiver sélectivement certaines optimisations au lieu de simplement les désactiver toutes comme ça. Clang refuse toujours d'émettre du code pour le second printf, cependant. Pour le forcer à le faire, j'ai dû modifier davantage le code à l'intérieur mainpour:

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

Il semble que vous deviez désactiver les optimisations pour votre fonction de boucle infinie, puis vous assurer que votre boucle infinie est appelée conditionnellement. Dans le monde réel, ce dernier est presque toujours le cas de toute façon.

Une implémentation conforme peut, et de nombreuses applications pratiques le font, imposer des limites arbitraires sur la durée d'exécution d'un programme ou sur le nombre d'instructions qu'il exécuterait, et se comporter de manière arbitraire si ces limites sont violées ou - selon la règle "comme si" - s'il détermine qu'ils seront inévitablement violés. À condition qu'une implémentation puisse traiter avec succès au moins un programme qui exerce nominalement toutes les limites énumérées dans N1570 5.2.4.1 sans atteindre aucune limite de traduction, l'existence de limites, la mesure dans laquelle elles sont documentées et les effets de leur dépassement sont tous les problèmes de qualité de mise en œuvre en dehors de la juridiction de la norme.

Je pense que l'intention de la norme est tout à fait claire que les compilateurs ne devraient pas supposer qu'une while(1) {}boucle sans effets secondaires ni breakinstructions se terminera. Contrairement à ce que certains pourraient penser, les auteurs de la norme n'invitaient pas les rédacteurs de compilateurs à être stupides ou obtus. Une implémentation conforme pourrait utilement décider de mettre fin à tout programme qui, s'il n'était pas interrompu, exécuterait plus d'instructions libres d'effets secondaires qu'il n'y a d'atomes dans l'univers, mais une implémentation de qualité ne devrait pas effectuer une telle action sur la base d'une hypothèse concernant résiliation mais plutôt sur la base que cela pourrait être utile, et ne serait pas (contrairement au comportement de clang) pire qu'inutile.

La boucle n'a pas d'effets secondaires et peut donc être optimisée. La boucle est en fait un nombre infini d'itérations de zéro unité de travail. Ceci n'est pas défini en mathématiques et en logique et la norme ne dit pas si une implémentation est autorisée à accomplir un nombre infini de choses si chaque chose peut être faite en un temps nul. L'interprétation de Clang est parfaitement raisonnable en traitant l'infini fois zéro comme zéro plutôt que l'infini. La norme ne dit pas si une boucle infinie peut se terminer si tout le travail dans les boucles est en fait terminé.

Le compilateur est autorisé à optimiser tout ce qui n'est pas un comportement observable tel que défini dans la norme. Cela comprend le temps d'exécution. Il n'est pas nécessaire de conserver le fait que la boucle, si elle n'est pas optimisée, prendrait un temps infini. Il est permis de changer cela en un temps d'exécution beaucoup plus court - en fait, c'est le point de la plupart des optimisations. Votre boucle a été optimisée.

Même si clang a traduit le code naïvement, vous pourriez imaginer un processeur d'optimisation capable de terminer chaque itération en deux fois moins de temps que l'itération précédente. Cela compléterait littéralement la boucle infinie en un temps fini. Un tel processeur optimisant viole-t-il la norme? Il semble assez absurde de dire qu'un processeur d'optimisation violerait la norme s'il est trop bon pour l'optimisation. Il en va de même pour un compilateur.

Je suis désolé si ce n'est absurdement pas le cas, je suis tombé sur ce post et je sais parce que mes années d'utilisation de la distribution Gentoo Linux que si vous voulez que le compilateur n'optimise pas votre code, vous devez utiliser -O0 (Zero). J'étais curieux à ce sujet, et j'ai compilé et exécuté le code ci-dessus, et la boucle va indéfiniment. Compilé avec clang-9:

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

Une whileboucle vide n'a aucun effet secondaire sur le système.

Par conséquent, Clang le supprime. Il existe de "meilleures" façons de réaliser le comportement prévu qui vous obligent à être plus évident de vos intentions.

while(1); est baaadd.