Peut-optimisation du compilateur introduire des bogues?

Question

Aujourd'hui, j'ai eu une discussion avec un ami à moi et nous avons discuté pendant quelques heures, à propos de "optimisation du compilateur".

J'ai défendu, au point que parfois, une optimisation du compilateur pourrait introduire des bugs ou au moins, un comportement indésirable.

Mon ami totalement en désaccord, affirmant que "les compilateurs sont construits par des gens intelligents et intelligents choses" et donc, ne peut jamais vous tromper.

Il ne l'a pas convaincu de ma à tous, mais je dois avouer que je manque d'exemples concrets pour renforcer mon point de vue.

Qui est ici ? Si je suis, avez-vous un exemple concret où une optimisation du compilateur produit un bug dans le logiciel ? Si je me trompe, dois-je arrêter de programmation et d'apprendre la pêche à la place ?

Merci!!!!

Answer 1

Les optimisations du compilateur peuvent introduire des bogues. C'est pourquoi vous pouvez les désactiver.

Un exemple: un compilateur peut optimiser les accès en lecture/écriture à un emplacement de la mémoire, en faisant des choses comme l'élimination double lit ou écrit en double, ou la réorganisation de certaines opérations. Si l'emplacement de mémoire en question n'est utilisé que par un seul thread et est en fait de la mémoire, qui peut être ok. Mais si l'emplacement de mémoire est un dispositif matériel IO registre, puis re-de la commande ou de l'élimination de l'écrit peut être complètement faux. Dans cette situation, normalement, vous devez écrire du code en sachant que le compilateur peut "optimiser", et donc en sachant que l'approche naïve qui ne fonctionne pas.

Mise à jour: Comme Adam Robinson a souligné dans un commentaire, le scénario que j'ai décrit ci-dessus est plus d'une erreur de programmation qu'un optimiseur d'erreur. Mais le point que j'essayais de montrer que certains programmes, qui sont par ailleurs correct, combiné avec quelques optimisations, qui, autrement, travail correctement, peut introduire des bogues dans le programme lorsqu'ils sont combinés ensemble. Dans certains cas, la spécification du langage dit "Vous devez faire les choses de cette façon, parce que ces sortes d'optimisations peuvent se produire et que votre programme va échouer", auquel cas c'est un bug dans le code. Mais parfois, un compilateur est un (généralement en option) fonction d'optimisation qui peut générer un code incorrect, car le compilateur essaie trop dur pour optimiser le code ou ne peut pas détecter que l'optimisation est inapproprié. Dans ce cas, le programmeur doit savoir quand il est sûr de mettre sur l'optimisation en question.

Answer 2

Quand un bug disparaît par disbaling optimisations, la plupart du temps, c'est toujours de votre faute

Je suis responsable d'une application commerciale, écrits pour la plupart en C++ - a commencé avec VC5, porté à VC6 début, maintenant porté avec succès à VC2008. Il a grandi à plus de 1 Millions de lignes dans les 10 dernières années.

En ce moment j'ai pu confirmer une seule génération de code bug thast s'est produite lors agressive optimisations où activé.

Alors, pourquoi suis-je plaint? Parce que dans le même temps, il y avait des dizaines de bugs qui m'ont fait douter le compilateur, mais il s'est avéré être mon manque de compréhension de la norme C++. Le standard de fait de la place pour les optimisations du compilateur peut ou ne peut pas faire usage de.

Au fil des années sur différents forums, j'ai vu beaucoup de posts de blâmer le compilateur, en fin de compte de tourner à avoir des bugs dans le code original. Sans doute la plupart d'entre eux obscur de bugs qui ont besoin d'une compréhension approfondie des concepts utilisés dans la norme, mais le code source de bugs tout de même.

Pourquoi je répondre si tard: arrêter de blâmer le compilateur avant d'avoir confirmé que c'est en fait le compilateur de la faute.

Answer 3

Oui, absolument.
Voir ici, ici (qui existe toujours - "by design"!?!), ici, ici, ici, ici...

Answer 4

Compilateur (et l'exécution) d'optimisation peut certainement présenter indésirable comportement - mais c'est au moins doit se produire uniquement si vous êtes en s'appuyant sur le comportement non spécifié (ou fait en effet sur des hypothèses erronées sur le bien-comportements spécifiques).

Maintenant, au-delà, bien sûr, les compilateurs peuvent avoir des bugs dans. Certains de ceux-ci peut être autour d'optimisations, et les conséquences pourraient être très subtil - en effet, ils sont susceptibles de l'être, comme une évidence, des bugs sont plus susceptibles d'être fixe.

En supposant que vous inclure des Ece que les compilateurs, j'ai vu des bugs dans les versions de deux de la .NET JIT et de la JVM Hotspot (je n'ai pas de détails pour le moment, malheureusement) qui étaient reproductibles particulièrement étrange situations. S'ils ont été en raison notamment des optimisations ou pas, je ne sais pas.

Answer 5

Combiner les autres posts:

1. Les compilateurs n'ont de temps en temps des bugs dans leur code, comme la plupart des logiciels. Les "gens intelligents" argument est totalement indifférent à ce, que les satellites de la NASA et d'autres applications créées par des gens intelligents aussi avoir des bugs. Le codage qui ne l'optimisation est différent de codage à partir de ce qui ne l'est pas, donc si le bug se trouve être dans l'optimiseur alors, en effet, votre code optimisé peut contenir des erreurs lors de votre non-optimisé le code ne sera pas.

2. Comme M. Brillant et Nouveau souligné, il est possible pour le code qui est naïf à l'égard de la simultanéité et/ou des problèmes de timing pour exécuter de manière satisfaisante, sans optimisation mais pas avec l'optimisation, car cela peut modifier le calendrier d'exécution. Vous pouvez blâmer un tel problème sur le code source, mais si il ne se manifeste lorsque optimisé, certaines personnes peuvent blâmer d'optimisation.