trous laissés parfois volontairement par les standards pour essayer (résultat non garantit) d'aller au plus vite pour un même résultat conforme au standard.
Si le programme n'a pas de sens ... quelles garanties voudrais-tu avoir ? L'incompréhension venait du fait que le message de Renault pouvait être compris comme : « à partir de -O2 le compilateur se réservait le droit de modifier la sémantique d'un programme [qui possède une sémantique] ». En particulier cela se serait appliqué à tout programme sans UB. Il n'est pas encore clair au vu des réponses si oui ou non -O2 fait une telle chose. D'après un autre commentaire (d'Arnaudus) -Ofast le fait très clairement.
Partons donc du principe que -Ofast s'arroge le droit de modifier la sémantique d'un code valide sans comportement indéfini. Un commentaire d'Anthony Jaguenaud qui s'est fait moinsser assez fortement explique clairement que selon cette spécification le compilateur qui construit juste un int main (int argc, char** argv) { return 0; } est valide et produit le code le plus rapide possible. Un tel compilateur serait la version « ultime » de -Ofast. Conclusion: si on ne met pas d'autres restrictions cela n'a pas beaucoup de sens de parler « d'optimisations destructrices ».
Ainsi: soit on ne peut qu'utiliser les comportements indéfinis pour optimiser, soit on modifie le sens de code valide et à ce moment là il faut bien un jour définir proprement quelles garanties on apporte ...
optimisations les plus agressives exploitent les trous laissés parfois volontairement par les standards
Mais ce n'était pas (je pense) ce qui faisait réagir Anasteo et moi-même, on est bien tous d'accord qu'un programme sans sémantique n'a de toute manière ... pas de sémantique, donc pas besoin de creuser plus loin. Encore une fois ce qui était a fait réagir Anasteo (« [je pensais que] dans tous les cas il s'agissait de respecter le standard ») c'est bien le fait que malgré tous les trous du standard gcc décide de ne pas en respecter une partie.
[^] # Re: Comportement attendu
Posté par Aluminium95 . En réponse au journal Compilateur trop intelligent. Évalué à 2.
Si le programme n'a pas de sens ... quelles garanties voudrais-tu avoir ? L'incompréhension venait du fait que le message de Renault pouvait être compris comme : « à partir de
-O2le compilateur se réservait le droit de modifier la sémantique d'un programme [qui possède une sémantique] ». En particulier cela se serait appliqué à tout programme sans UB. Il n'est pas encore clair au vu des réponses si oui ou non-O2fait une telle chose. D'après un autre commentaire (d'Arnaudus)-Ofastle fait très clairement.Partons donc du principe que
-Ofasts'arroge le droit de modifier la sémantique d'un code valide sans comportement indéfini. Un commentaire d'Anthony Jaguenaud qui s'est fait moinsser assez fortement explique clairement que selon cette spécification le compilateur qui construit juste unint main (int argc, char** argv) { return 0; }est valide et produit le code le plus rapide possible. Un tel compilateur serait la version « ultime » de-Ofast. Conclusion: si on ne met pas d'autres restrictions cela n'a pas beaucoup de sens de parler « d'optimisations destructrices ».Ainsi: soit on ne peut qu'utiliser les comportements indéfinis pour optimiser, soit on modifie le sens de code valide et à ce moment là il faut bien un jour définir proprement quelles garanties on apporte ...
Mais ce n'était pas (je pense) ce qui faisait réagir Anasteo et moi-même, on est bien tous d'accord qu'un programme sans sémantique n'a de toute manière ... pas de sémantique, donc pas besoin de creuser plus loin. Encore une fois ce qui était a fait réagir Anasteo (« [je pensais que] dans tous les cas il s'agissait de respecter le standard ») c'est bien le fait que malgré tous les trous du standard gcc décide de ne pas en respecter une partie.