Oui, il faut utiliser -fltconsistency
Ca a un avantage dans le sens ou cela suit strictement la norme.
Dans le cas ci-dessus, c'est plus precis.
L'inconvenient c'est que parfois c'est moins precis aussi. Par exemple sur Itanium, a*b+c sera desormait encode avec une multiplication et une addition separee, plutot qu'avec un fma (fused multiply and add). Or comme il n'y a que fma de disponible, on se retrouve avec:
temp <- a*b + 0
res <- temp*1+c
au lieu de:
res <- a*b + c
La difference c'est qu'il y a potentiellement deux erreures d'arrondis dans le premier cas, au lieu d'une seule dans le second.
Maintenant tu as tout a fait raison: Ne confonds pas la norme et la toutouille des compilos.
Le compilo fait ce qu'on lui demande. Il faut lui dire ce que l'on attend de lui.
Mais tout n'est pas bon a jeter dans la toutouille d'un compilo, et on est parfois bien content que le compilo n'applique pas la norme dans sa version stricte.... Sinon adieu le multithreading.
Imagine que a soit une variable qui est accessible par plusieurs thread et que ton code utilises par exemple un semaphore.
Maintenant tu as la sequence:
c=e+f
g=h+i
Tu n'utilises pas a. Donc pas de pb. Oui, parce que les compilos sont gentils et ils ont surtout autre chose a faire que de nous embeter avec la lecture strict de la norme.
Parce que d'apres la norme, il est tout a fait correcte pour un compilo de generer la sequence suivante:
j=a
c=e+f
g=h+i
a=j
La sequence etant equivalente a la precedente, c'est valable. Tu vois le drame? Ben des fois Gcc fait des trucs bizarre dans ce genre. Linus c'est un peu fache.
C'etait juste pour ouvrir un peu le debat entre l'adequation d'un compilateur a une norme. Meme si les deux cas sont differents.
[^] # Re: Quelques infos
Posté par mdlh . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 2.
Ca a un avantage dans le sens ou cela suit strictement la norme.
Dans le cas ci-dessus, c'est plus precis.
L'inconvenient c'est que parfois c'est moins precis aussi. Par exemple sur Itanium, a*b+c sera desormait encode avec une multiplication et une addition separee, plutot qu'avec un fma (fused multiply and add). Or comme il n'y a que fma de disponible, on se retrouve avec:
temp <- a*b + 0
res <- temp*1+c
au lieu de:
res <- a*b + c
La difference c'est qu'il y a potentiellement deux erreures d'arrondis dans le premier cas, au lieu d'une seule dans le second.
Maintenant tu as tout a fait raison:
Ne confonds pas la norme et la toutouille des compilos.
Le compilo fait ce qu'on lui demande. Il faut lui dire ce que l'on attend de lui.
Mais tout n'est pas bon a jeter dans la toutouille d'un compilo, et on est parfois bien content que le compilo n'applique pas la norme dans sa version stricte.... Sinon adieu le multithreading.
Imagine que a soit une variable qui est accessible par plusieurs thread et que ton code utilises par exemple un semaphore.
Maintenant tu as la sequence:
c=e+f
g=h+i
Tu n'utilises pas a. Donc pas de pb. Oui, parce que les compilos sont gentils et ils ont surtout autre chose a faire que de nous embeter avec la lecture strict de la norme.
Parce que d'apres la norme, il est tout a fait correcte pour un compilo de generer la sequence suivante:
j=a
c=e+f
g=h+i
a=j
La sequence etant equivalente a la precedente, c'est valable. Tu vois le drame? Ben des fois Gcc fait des trucs bizarre dans ce genre. Linus c'est un peu fache.
C'etait juste pour ouvrir un peu le debat entre l'adequation d'un compilateur a une norme. Meme si les deux cas sont differents.