Version imprimable
Bonjour
voici mon problème : un même code, compilé sur une même machine (linux) avec les mêmes options de compilation, ne donne pas les mêmes résultats en fonction de la version de gcc utilisée pour compiler (3.3.6 ou 4.1.1).
Quels sont les types de calculs susceptibles de donner ce genre d'écart ?
Existe-t-il un moyen (option de compilation, ...) permettant d'être indépendant de la version de compilateur ?
Merci
Bonjour,
- Les écarts que tu constates sont dans le comportement ou la performance de ton application ?
- Quelles options de compilation utilises tu ?
Les écarts sont dans les résultats : à partir des mêmes entrées, les calculs ne donnent pas les mêmes résultats.
Mes options sont :
-m32 (la machine est 64 bits mais le code doit être 32 bits)
-O (mais je constate l'écart aussi sans cette option)
Es-tu sûr que ton code ne comporte aucun bug ?
C'est difficile de répondre sans qu'on sache quels sont tes calculs et comment se présente ton code.
Montre-nous le code pour qu'on puisse y voir plus clair.
Le code est un peu gros (4 fichiers, 40000lignes ...).
Par contre, il a été validé en comparant ses sorties avec celles générées par le même modèle développé sous Matlab. J'obtiens l'égalité bit-à-bit des sorties en compilant avec la version 4.1.1 mais pas avec la version 3.6.6 (les écarts sont importants, cela vient certainement d'un changement d'ordre de grandeur des calculs en cours de route : une erreur à la 10ème décimale peut devenir une erreur de plusieurs centaines).
Citation:
Envoyé par corentin59
Ça peut être n'importe quoi, mais je penche quand même pour un bug intermittent. Les astuces qui « tombent en marche » sur une plateforme répandue et qui plantent dès que l'on migre vers un système un peu plus exotiques sont légions en C. D'une version de GCC à l'autre sur une même machine, c'est déjà moins fréquent, mais c'est faisable. Citons, dans l'ordre de probabilité :Citation:
Envoyé par corentin59
- Des variables non initialisées. Vois par exemple ce cas tout récent. Son while (Q) devrait être en fait un while(n). Cependant, il fait « n=Q » en fin de boucle, ce qui fait que cette condition revient au même dès le deuxième tour de boucle. Néanmoins, dans son code, Q (et R) ne sont pas initialisés à la déclaration, et leur valeur est indéfinie. Par conséquent, si celle-ci est non nulle, l'opération se déroulera normalement et il ne s'apercevra de rien. Par contre, si elle est nulle, la boucle ne s'exécutera pas du tout. Si tu as des structures similaires dans ton programme et que le résultat d'une telle boucle est un nombre, tu obtiendras des résultats farfelus dont les conséquences ne se feront sentir que bien plus loin ;
- Des débordements de tableau. Selon la disposition de tes variables en mémoire, un écrasement involontaire peut soit n'avoir aucune conséquence si le tableau est en fin de plage, soit aller écrire des valeurs aléatoires dans les variables d'à côté. Ça peut être encore plus sournois si la variable en question est un indice de boucle : si la valeur n'est pas trop grande, ton programme peut faire quelques tours supplémentaires sans que personne ne s'en rende compte ;
- Des formats de nombres mal contrôlés. Il se peut qu'en faisant du cross-compiling, certaines options modifient le format des nombres utilisés ;
- Des alignements de structure mal contrôlés. Le compilateur peut mettre des blancs entre les champs de manière à rendre leur accès plus efficace. Si un programme fait l'hypothèse qu'ils sont tous contigüs et essaie de les lire en un seul bloc avec un pointeur, cela peut être source de surprises, également ;
- Des erreurs sur le format des caractères, char contre wchar, source ASCII ou UTF-8, …
- etc.
Toutefois, ça dépend aussi beaucoup des résultats que tu obtiens : si ce sont des valeurs complètement aléatoires, c'est un bug. S'il s'agit d'une progression mathématique cohérente mais qui n'est pas celle attendue, ton hypothèse est la plus probable.