Discussion :

[sambia39]

Du code mort il y a le return qui même s'il est inatteignable, dit que cette branche peut être exécutée while -> for -> if -> return 1.

Ce qui va être exécuté est le return 1. l’optimisateur de clang vas tout simplement virer une bonne partie du code de la boucle pour en faire une boucle while(1) {return 1;} ou un "do{ return 1; }while(1)" et comme cela ne sert rien, il remplacera le tout par un return 1; donc à partir d’un code mort du if, succédera une déduction qui pousse naturellement l’optimiseur à remplacer le code de test part

Code asm :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
test:
  mov eax, 0x1
  ret 
; padding ...

Remarque qu'avec Gcc en mode statique en obtient le même résultat

[Kannagi]

le comportement est ok sans O3 mais avec O3 ça donne un programme qui fait pas le code. pour moi c'est un bug.

ça dépend de un si ton code est UB.
Et secundo je te rassure que GCC bug aussi avec -O3 ,peut être pas sur un target x86 , mais sur d'autre plateforme que j'ai fait GCC a de sacré bug

J'ai envie aussi de dire qu'il faut pas prendre ces optimisations comme un truc "magique" , et on met les flag d'optimisation par rapport à ce qu'on souhaite faire.
Pour ma part (et c'est ce que fait le kernel Linux aussi il me semble ) , on doit des fois annuler les optimisations du compilateur pour qu'une fonction soit "valide".

[Bktero]

Cela foutrait en l'air 90% des codes de la planète

Mon pauvre... Si tu savais le nombre de code qui reposent sur des UB...

Et secundo je te rassure que GCC bug aussi avec -O3 ,peut être pas sur un target x86 , mais sur d'autre plateforme que j'ai fait GCC a de sacré bug

C'est un classique les codes qui fonctionnent bien en O1 voire O2, et qui s'écroulent en O3... Il y a potentiellement des bugs compilo mais c'est surtout que tous les UB de ton code peuvent t'exploser à la figure. Cette discussion est intéressante : https://stackoverflow.com/questions/...dangerous-in-g

Et il ne faut pas oublier que votre compilateur peut faire tout ce qu'il veut quand il rencontre un UB dans votre code : le laisser en O0, Og, O1, O2, Os, et le virer en O3. Quand il rencontre un UB, le gentil deal "Le minimum qu'on est en droit d'attendre d'un compilateur est qu'il reproduise en toutes circonstances fidèlement l'algorithme qu'on lui donne" décrit par Sve@r n'existe plus.

Il y a une série incroyable sur le blog de LLVM : https://blog.llvm.org/2011/05/what-e...ould-know.html J'encourage vivement tout développeur qui n'est pas au clair sur les conséquences d'un UB à la lire. Vous aurez peur de coder après... Surtout quand on sait que quelque chose d'aussi bête qu'un overflow d'un int est un UB.

[Invité]

Bonsoir,

Il me vient hypothèse en tête : il y aurait un UB qui dirait "tu ne peux pas faire de return dans une fonction s'il y a une boucle infinie". Si tel est le cas, ça expliquerait une différence de comportement entre C et C++ (en admettant que l'UB soit présent dans les 2 langages). Ca expliquerait que le comportement en C avec optimisation n'est pas celui attendu.

C'est tout à fait ça :

Memory model - Progress guarantee

In a valid C++ program, every thread eventually does one of the following:

• terminate
• makes a call to an I/O library function
• reads or modifies a volatile object
• performs an atomic operation or a synchronization operation

No thread of execution can execute forever without performing any of these observable behaviors.

Note that it means that a program with endless recursion or endless loop (whether implemented as a for-statement or by looping goto or otherwise) has undefined behavior.

Et démontré avec un code proche du code montré dans Undefined behavior - Infinite loop without side-effects.

Suivant la complexité du code / l'optimisation demandée, si le compilateur parvient à détecter que la boucle ne se terminera jamais, alors il laissera libre court à son imagination.

[Sve@r]

Mon pauvre... Si tu savais le nombre de code qui reposent sur des UB...

Je suis content de ne pas le savoir

C'est tout à fait ça :

Et démontré avec un code proche du code montré dans Undefined behavior - Infinite loop without side-effects.

Tiens, j'ai appris quelque chose. Mais cela ouvre plein de questions. Par exemple un serveur dont le mécanisme général c'est "boucle infinie et dès qu'un client arrive je lance un fork pour traiter avec lui tandis que je retourne dans ma boucle" est-il dans ce cas en UB ???
Accessoirement tes exemples et assertions parlent de C++ et ici on est en C. J'ai idée que cela ne changera pas grand chose mais fallait le préciser...

[Bousk]

Par exemple un serveur dont le mécanisme général c'est "boucle infinie et dès qu'un client arrive je lance un fork pour traiter avec lui tandis que je retourne dans ma boucle" est-il dans ce cas en UB ???

Non parce que le serveur finit par appeler le fork ou autre fonction, si un client arrive, chose externe au programme que le compilateur ne peut pas exclure.
Ce n'est pas une boucle vide.

[Invité]

Accessoirement tes exemples et assertions parlent de C++ et ici on est en C. J'ai idée que cela ne changera pas grand chose mais fallait le préciser...

Ça l'est, au début de la citation.
Il n'y certes pas les mêmes lignes dans la partie C correspondante, mais on peut par contre y retrouver le même exemple. Niveau norme C, on peut lire :

6.8.5 Iteration statements

6. An iteration statement may be assumed by the implementation to terminate if its controlling expression is not a constant expression,⁽¹⁾) and none of the following operations are performed in its body, controlling expression or (in the case of a for statement) its expression-3:⁽²⁾)

• input/output operations
• accessing a volatile object
• synchronization or atomic operations

⁽¹⁾ An omitted controlling expression is replaced by a nonzero constant, which is a constant expression
⁽²⁾ This is intended to allow compiler transformations such as removal of empty loops even when termination cannot be proven.

Ce qui restreint ainsi en C ce comportement à des boucles dont la condition n'est pas une expression constante. (De part le ⁽¹⁾, for(;;) est considéré comme expression constante.)

Tiens, j'ai appris quelque chose. Mais cela ouvre plein de questions. Par exemple un serveur dont le mécanisme général c'est "boucle infinie et dès qu'un client arrive je lance un fork pour traiter avec lui tandis que je retourne dans ma boucle" est-il dans ce cas en UB ???

C'est l'absence d'effet de bord (cf. liste ci-dessus) au sein de la boucle. J'ose espérer que les serveurs effectuent de nombreuses opérations avec effets de bord en leur sein, en particulier des traitements I/O dont fait partie le fork.
Aucune raison donc de s'inquiéter .

[WhiteCrow]

Il n'y a aucun UB en C concernant les boucles infinies (may ≠ shall).