AVR/GNU, Compiler ... Pas très rassurant!

[lvdl2]

Bonjour,
Dans un contexte d'analyse de code généré par un AVR/GNU C Compiler, j'ai constaté la translation de code C vers assembleur (ATMegaXXX) suivante:
Code C:
if( (!v1) || ( (v1) && ( (!v2)&&(!v3) ) ) )
QQC_à_faire;
else
Autre_Chose_à faire;

qui correspond au Code en langage naturel ==> Si (v1 faux) OU Si (v1 Vrai ET ( v2 Faux ET v3 Faux).

Ci-dessous le code machine généré par le AVR/GNU C Compiler, mixé avec les lignes de code C génératrices:


Commentaires:

=> On constate alors la duplication parfaite du premier test (!V1) : Encadrés VERT et ROUGE, duplication parfaite de code !!!!
===> La différence dans le déplacement relatif PC+0x0D (cadre vert) devenant PC+0x0A (cadre rouge) correspondant au fait que chaque cadre fait 3 @PC de long (3 mots de 16 bits), et donc les 2 instructions 'BREQ' branchent en définitive exactement sur la même @ mémoire (flèches bleues).

Comment est-possible ?

Manifestement, c'est un BUG, car si le 2ième test (V1) a disparu, ce qui est normal, la duplication du test (!V1) est tout à fait anormale: Pour preuve, il suffit de supprimer le code inclue dans n'importe quel des cadres rouge ou vert et rien n'est changé à ce que le code fait alors !!!

Je ne savais pas que le AVR/GNU C COmpiler était atteint de baiguement ?
Pour info.
-----

[pm42]

Le 1er BREQ est en 2DB et fait un saut relatif de D : il va donc en 2E8.
Le 2nd est en 2DF et fait un saut de A : il va donc en 2E9.

Il serait intéressant de connaitre l'instruction en 2E8 mais il y a de bonnes chances pour que le code en question soit juste. En tout cas, les 2 instructions ne sautent pas au même endroit de ce que je vois.

[lvdl2]

Oui, vous avez raison, mais ce n'est pas vraiment le sujet: Ce qui apparaît suffit à détecter un PB de baiguement au minimum bouffeur de place et de temps d'exéc.

=> On a 2 blocs de code strictement identiques.

===> Si le 1ER branche, il va en 313H, sinon il exécute le 2ND, qui est le même code, donc il ne branche pas et son JMP pourrait être n'importe quoi, cela ne changerait rien : c'est le cas (!v1).

Cela suffit à démontrer qu'il s'agit bien d'un BUG certes qui ne change rien à l'exécution, mais qui n'est pas vraiment rassurant (je pense même transmettre ça à mes collègues, par exemple, les normes SILx n'acceptent pas du tout ce genre de "code pour rien", même s'il est "transparent")

Maintenant, je réponds à votre question, quoique cela reste visible sur l'image et sur le code C associé que j'ai reproduit:

==> Le premier jmp arrive dans le bloc if(true) (càd if(!v1)) et BREQ branchant.

==> Le deuxième, va 1 mot plus loin c'est à dire if(false); (bloc else absent donc)

Ainsi, la différence de branchement ne change rien u PB, mais c'est pire, car elle est même révélatrice du n'importe quoi de la génération de code ici: Heureusement, il est structurellement "transparent" !

J'en ai d'autres...

[pm42]

J'en ai d'autres...

Quand on trouve un bug dans un compilateur, on le signale aux gens qui en font la maintenance.
En parler ici est inutile.

Il est parfaitement possible que ce soit un bug mais le fait que vous vous soyez trompé au départ sur un truc aussi simple que le calcul d'adresses de saut en disant que "c'est la même" base de votre démonstration suivi de "ah oui ce n'est pas la même mais ce n'est pas le sujet" quand je vous ai fait remarquer votre erreur fait planer le doute : l'autre hypothèse est que vous vous trompiez.

De plus, on ne connait les options utilisées pour compiler mais la correspondance avec les lignes de code dans l'assembleur laissent penser qu'il n'y a eu aucune optimisation pour justement avoir une correspondance 1-1 entre le source et le généré.
Si c'est le cas, le "code pour rien" est parfaitement logique.

Enfin, il faut faire attention quand on pense trouver des bugs dans gcc et surtout aussi évidents : ce compilateur existe depuis très longtemps et est très bien débuggé. A titre perso, j'ai du trouver 1 bug dedans en plus de 30 ans et il y a longtemps.

[A voir en vidéo sur Futura]

[polo974]

dans le code source, le second test sur v1 est inutile, c'est "un bégaiement":

 if(  (!v1) || ( (v1)  &&  ( (!v2)&&(!v3) )  )  )

le compilo ne fait que le reproduire. car sans doute lancé sans option d'optimisation.
ce n'est PAS un bug.

il vaudrait mieux par ailleurs être moins épidermique (faible euphémisme) quand on échange...

[pm42]

On peut même ajouter que vu l'architecture de gcc et notamment son passage par du RTL avant le back-end qui cible un assembleur spécifique, ce genre de bug est très, très peu probable.

Parce que sauf backend très mal écrit et pas testé ce qui n'est pas le cas ici, le bug apparaitrait dans pratiquement tous les codes compilés avec gcc.
Vu qu'il fait tourner la planète depuis Internet jusqu'à tous les micro-controlleurs, si un simple if avec quelques conditions compilait de façon fausse, cela se remarquerait.

[ArchoZaure]

Bonjour.

Je vous trouve bien véhément.
Sachant d'autre part que je me suis fais exactement les mêmes réflexions que pm42 je me sens visé...
Options de compilateur !

Sinon sur le fond je me demande si ce code n'est pas juste normal vu que si vous faites un test genre SI (NON V1) OU SI(V1) alors quelle que soit la valeur de V1 vous avez le même résultat.
Il est alors inutile de faire le deuxième test (SI V1).
Mais comme il n'y a pas d'optimisation demandée c'est quand même conservé comme ça.
Puisque parfois c'est voulu...pour de bonnes raisons.

[ArchoZaure]

Cela suffit à démontrer qu'il s'agit bien d'un BUG certes qui ne change rien à l'exécution, mais qui n'est pas vraiment rassurant (je pense même transmettre ça à mes collègues, par exemple, les normes SILx n'acceptent pas du tout ce genre de "code pour rien", même s'il est "transparent")

Franchement là je serais très surpris d'un bug vu que ce genre de petit bout de test logique est vraiment élémentaire.
Vous pensez vraiment que c'est la première fois qu'on s'y intéresse ????!!!
Et vous allez leur dire quoi à vos collègues ?
N'utilisez pas ce type de test logique ????

[umfred]

Pour moi ce serait un bug si la traduction ne donnerait pas le fonctionnement attendu; un manque d'optimisation n'est pas un bug (encore moins si on ne demande pas d'optimisation)
Il faudrait voir les lignes suivantes