Disons que ce que je reproche le plus est l'attitude «c'est pas vraiment un bug puisqu'il y a une demande d'optimisation …, t'as qu''a pas demander d'optimiser et puis c'est tout.»
Pour avoir confiance en un compilo il faut qu'il fasse son boulot : produire un exécutable dont les seuls défauts sont imputables aux défauts du code source. Ce n'est pas au programmeur de modifier le code si le compilo optimise trop agressivement. Ce n'est peut-être pas anodin que l'option qui contrôle ce comportement dans gcc n'est activé par défaut qu'en O2 pour c++11 et supérieur … car en effet une boucle infinie avec un chemin infini est un UB en c++ ; mais pas en C (enfin jusqu'à C18).
Ok, tous les compilos sont bugués, il suffit d'aller consulter n'importe quel bugzilla. Et le problème adressé par le PO est bien un bug, enfin il a été reconnu comme tel par l'équipe clang. Je trouve juste que ce bug est gros, surtout que ça traîne depuis 2006, car ce n'est pas quelque chose de rare que de voir une boucle infinie, ce n'est pas comme un réordonnancement d'opérations sur une plateforme particulière.
Le problème c'est de lancer la compilation avec des options (-O3) qui déclenchent des transformations dont on ne veut pas, même si elles sont autorisées par le standard.
Admittedly the title is somewhat lurid—kudos to Dijkstra—but the C and C++ standards have some constraints regarding termination that may be surprising at first. In the following we will have a look at some example programs for which unexpected code is emitted by two compilers, and examine the C and C++ standards in order to clarify whether such compilations are sound or not.
tl;dr Non-termination essentially invokes undefined behavior under certain conditions.
...
In the upcoming sections we first have a look at the C standard and afterwards at the C++ standard in order to clarify whether such compilations are sound or not.
Pluttôt que d'avoir 3 options d'optimisation -O1, -O2 et -O3 comme maintenant (et je ne suis pas certain qu'elles sont différentes ...) ne serait-il pas concevable qu'il y ait des options plus spécifiques comme pour les warnings -W... ? Par exemple: -Oempty-loop ... Je ne sais pas si les comités de standards seraient réceptifs à une telle implémentation.
Le Tout est souvent plus grand que la somme de ses parties.
Je crois avoir lu (mais c'est à vérifier en cherchant dans quelques centaines de documents) que le comité en a discuté, mais se refuse à donner des indications sur les options de compilations, genre ça serait empiéter sur le boulot des gens qui font les compilateurs. Et déclencher une guerre entre les fabricants de compilos qui sont membres du comité pour défendre leur casse-croûte. Si on se met à leur imposer des options avec des significations précises où va-t-on.
An implementation may generate warnings in many situations, none of which are specified as part of this International Standard.
Pour les options de compilation, on doit pouvoir considérer ceci comme un autre disclaimer (1. Scope)
This International Standard does not specify— the mechanism by which C programs are transformed for use by a data-processing system
Au fait, à propos des comportements non définis, en fait c'est précisé dans le standard qu'ils n'ont pas besoin d'être spécifiés explicitement comme tels pour l'être quand même (relire calmement).
(4 Conformance).
If a “shall” or “shall not” requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words “undefined behavior ” or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe “behavior that is undefined”
Donc si on tombe sur un "a compiler may do this", paf, c'est le cas. Ni shall, ni shall not =>bingo.
Surtout que les options de compilo dépend de la cible aussi , faut savoir que GCC a des options de compilations spécifique pour chaque processeurs. Et sinon non il n'ya pas 3 options de compilation , les -O41 ,-O2 et -O3 sont des raccourcis , c'est optimisations en rajouter des dizaines d'autre.
tu peux les voir ici : https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html (et donc tu peux activé ceux que tu souhaite) , tu peux aussi (je le redis) le faire pour chaque fichier (donc que chaque fichier à une optimisation différente) GCC permet aussi si tu le souhaite qye chaque fonction à une opti spécifique ,bref ce n'est clairement pas un soucis actuellement de choisir une optimisations suivnat les cas ,c'est d'ailleurs très utilisé en emparquée justement.
D'ailleurs en -O2 GCC met ceci :
-ffinite-loops
Assume that a loop with an exit will eventually take the exit and not loop indefinitely. This allows the compiler to remove loops that otherwise have no side-effects, not considering eventual endless looping as such.
This option is enabled by default at<samp>-O2</samp>for C++ with -std=c++11 or higher.
En fait, normaliser les options de compilation, ça voudrait dire expliciter la nature exacte des optimisations/transformations (Et donc les limiter), pour pouvoir garantir qu'elles sont faites si et seulement si on les demande.
C'est très loin de l'état réel du langage, qui ne prétend à la portabilité que pour les codes sources soigneusement écrits pour éviter tout comportement indéfini, explicitement ou pas, ce qui est concrètement quasi-impossible (Voir discussions sur les debordements arithmétiques par exemple).
Donc faut rester pragmatique, et pas supposer que les compilateurs appliquent les choix qu'on voudrait.
Il y a bien des travaux sur des compilateurs certifiés, mais vu l'état du langage à compiler, ils n'implement pas tout et ne n'optimisent pas beaucoup. Et quand ils tombent sur du code qui correspond à un comportement indefini, ils font un choix, comme les autres.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le Tout est souvent plus grand que la somme de ses parties.