Comportements différent suivant optimisation ou non

Bonjour,

C'est la première fois que je poste une question dans le forum là, c'est donc que mon problème est particulièrement bizarre.

Je suis en train de réaliser une bibliothèque de fonction (enfin, bref, peu importe) et j'ai un gros problème. Le comportement du programme est différent suivant que je mettes des optimisations (à partir de -O1) ou non (je travaille avec g++ sous Windows, je n'ai pas pu tester sur une autre architecture pour l'instant).

Mon programme est monothread et il n'y a pas d'accès asynchrone à la mémoire. En général, ce genre de problème arrive dans ces cas là, et il suffit de mettre les variables avec la qualificatif volatile. Mais ce n'est pas ça ici.

Quelqu'un aurait-il une idée de programme qui pourrait avoir un comportement différent avec -O1 (à part l'exemple que j'ai cité) ?

gorgonite m'avait parlé de possibilité d'optimisation bizarre sur les flottants, mais a priori, ce n'est pas ça (je n'ai en tout cas, aucun test sur des flottants).

Je ne mets pas le code car il est assez méchant, long et technique (traitement d'images assez bourrin).

Merci d'avance

Ça sens la variable non initialisée tout ça.
Ou tout autre comportement indéfini (lecture ou écriture en dehors de la zone allouée, ...).
Bref un bug qui passe inaperçu sans optimisation, mais pas avec.

je ne saurai te conseiller.

cela dit, il semblerait que du code qui differe selon l'optimisation, tous les compilos savent faire ca.

jette un petit coup d'oeil par ici et trouve le dernier paragraphe intitulé Optimize only what counts

Tu compiles bien en -Wall sans warning ?

Citation:

---

Envoyé par Miles

Tu compiles bien en -Wall sans warning ?

---

Oui, j'utilisais -Wall -W.

Je suis en train de regarder du côté du dépassement de la zone allouée...

Tu peux utiliser efence pour vérifier ?

Hum, là, je suis sous windows et pas sur mon ordinateur, donc ce n'est pas super pratique.

Enfin, normalement, la plupart des accès que je fais passe par une classe DataBuffer, où pour l'occasion, j'ai testé les dépassements. Et a priori, je n'en fais pas.

Mais ce qui m'étonne, c'est que le programme marche très bien sans optimisation :(

Rajoute -pedantic déjà dans tes avertissements.
Ou même un truc avec encore plus d'avertissements.

Ensuite, ça n'a rien de surprenant.
Du code qui produit un comportement indéfini peut très bien marcher dans certains contextes et pas dans d'autres.

-pedantic fait la tête avec mingw ;)

Non, il faut bien comprendre que le comportement n'est pas vraiment indéfini. Suivant qu'il soit avec optimisation ou non, il est toujours pareil.

En fait, avec les options d'optimisation, j'obtiens à tous les coups ceci :
http://humbert-florent.developpez.co...a20Outavec.jpg

Et sans, j'obtiens à tous les coups ceci :
http://humbert-florent.developpez.co...a20Outsans.jpg


Ce n'est pas totalement différent non plus, mais bon...

cette image me dit qqchose... tu utiliserais pas CxImage par hasard ?

en fait, apres une recherche sur google image, rien n'est moins sur

dans un précédant Thread nous avions eu un pb avec des Macros
de ce type :

Code:

---

1 2	#define new new(__FILE__, __LINE__)

---

dans le but de surcharger le delete et le new ... pour tester la mémoire

C'est une image libre de droit souvent utilisé pour des test pour des applications de traitement d'images (lenna sous wikipedia et tu verras ;))

Et j'utilises pas CxImage, je refais une bibliothèque complète de traitement d'images.

Citation:

---

Envoyé par alskaar

dans un précédant Thread nous avions eu un pb avec des Macros
de ce type :

Code:

---

1 2	#define new new(__FILE__, __LINE__)

---

dans le but de surcharger le delete et le new ... pour tester la mémoire

---

En fait, je n'ai à recompiler qu'un seul fichier (en -O1 ou non) pour avoir la différence.
Et dans ce fichier, il n'y a aucun appel à new (il y a des constructions de classes, mais les fichiers objets contenant ces classes sont les mêmes ! (vu que je recompile pas tout))

loha,

Pour moi, c'est typique d'une variable non initialisée (variable qui peut être un pointeur, mais c'est moins probable, sinon tu aurais probablement eu des "access violation", sauf si tu as de la malchance).

As-tu essayé ton programme avec une autre image ?

Si oui, le problème persiste-t-il ?

Citation:

---

Envoyé par millie

Je suis en train de réaliser une bibliothèque de fonction (enfin, bref, peu importe) et j'ai un gros problème. Le comportement du programme est différent suivant que je mettes des optimisations (à partir de -O1) ou non (je travaille avec g++ sous Windows, je n'ai pas pu tester sur une autre architecture pour l'instant).

Mon programme est monothread et il n'y a pas d'accès asynchrone à la mémoire. En général, ce genre de problème arrive dans ces cas là, et il suffit de mettre les variables avec la qualificatif volatile. Mais ce n'est pas ça ici.

---

En passant, volatile n'est pas la solution. Ca peut masquer le problème sur certains systèmes, mais il reste présent.

Citation:

---

Quelqu'un aurait-il une idée de programme qui pourrait avoir un comportement différent avec -O1 (à part l'exemple que j'ai cité) ?

---

Tout ce qui est comportement indéfini. Je suppose que tu as fait le tri des avertissements de -Wall -W?

L'ordre des évaluations peut changer, ce qui peut jouer.

Citation:

---

gorgonite m'avait parlé de possibilité d'optimisation bizarre sur les flottants, mais a priori, ce n'est pas ça (je n'ai en tout cas, aucun test sur des flottants).

---

Est-ce que ton code est sensible à la précision (test rapide: le faire fonctionner avec des float et avec des doubles)?

Est-ce qu'utiliser les options pour utiliser SSE2 pour les flottants plutôt que le coprocesseur compatible 8087 aide (-msse -fpmath=sse) ?

Et -ffloat-store?

Citation:

---

Envoyé par Jean-Marc.Bourguet

Tout ce qui est comportement indéfini. Je suppose que tu as fait le tri des avertissements de -Wall -W?

---

oui oui :D

Citation:

---

Est-ce que ton code est sensible à la précision (test rapide: le faire fonctionner avec des float et avec des doubles)?

---

Bon, là, j'ai pas encore essayé, il faudrait que je touche à pas mal de fichier.

Citation:

---

Est-ce qu'utiliser les options pour utiliser SSE2 pour les flottants plutôt que le coprocesseur compatible 8087 aide (-msse -fpmath=sse) ?

Et -ffloat-store?

---

En mettant juste les options là, je n'ai pas d'erreur.

J'ai également essayé avec ceux indiqué dans le man (pas de ma version aussi :s) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

-fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize -fcrossjumping -fif-conversion -fif-conversion2 -fguess-branch-probability -fcprop-registers -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm -fdelete-null-pointer-checks -fexpensive-optimizations -fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fcaller-saves -fpeephole2 -freorder-blocks -freorder-functions -fstrict-aliasing -falign-functions -falign-jumps -falign-loops -falign-labels -finline-functions -frename-registers

---

Et ça marche bien...

Je vais plutôt aller dans le man de mon compilateur :aie:

Citation:

---

Envoyé par millie

En mettant juste les options là, je n'ai pas d'erreur.

---

En compilant en optimisé avec ces options, tu n'as pas le problème que tu as sans? Si c'est le cas, c'est un problème de précision avec les flottants, on peut déjà oublier les autres possibilités.

Je voulais dire :
Mettre -ffloat-store ne me provoque pas d'erreur (donc, ça marche bien). L'erreur ne vient donc pas de là.


J'ai essayé avec les options qu'activent O1 (que m'a dit mon man), et ça marche !

C'est à dire :
Pour O1

Code:

---

1 2 3 4 5 6 7

-fmerge-constants -fthread-jumps -floop-optimize -fif-conversion -fif-conversion2 -fguess-branch-probability -fcprop-registers

---

Et Pour O2 :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

-fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm -fgcse-las -fdelete-null-pointer-checks -fexpensive-optimizations -fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fcaller-saves -fpeephole2 -freorder-blocks -freorder-functions -fstrict-aliasing -funit-at-a-time -falign-functions -falign-jumps -falign-loops -falign-labels -fcrossjumpingfR

---

O1 doit donc faire quelque chose en plus :?

Citation:

---

Envoyé par millie

J'ai essayé avec les options qu'activent O1 (que m'a dit mon man), et ça marche !

...

O1 doit donc faire quelque chose en plus :?

---

Et quand tu fais la même chose mais avec les options pour -O2 (puisque tu les as sous la main autant essayer) ?

Oui, j'ai essayé aussi, et ça marche.

J'ai essayé aussi avec ceux d'ici : http://gcc.gnu.org/onlinedocs/gcc-4....e-Options.html

Et ça marche :(:(

Par contre, avec mingw, juste avec -O en fait, ça ne marche plus. :? :?

C'est dommage que je ne sois pas chez moi, j'aurais essayé sur une autre plate-forme.

Un conseil change de compilo (pas de version hein!) pour voir ...
Tu pourrais avoir de nouveaux message d'erreur indicatifs.

Salut,

Se pourrait-il que le problème soit du soit à l'option de compilation utilisée lors de la compilation de la STL, soit à l'absence de bibliotheques large précision (ce que tente d'ailleurs de déterminer jean-marc)
:question:
Je pense en particulier, et bien qu'elles ne soient nécessaire que pour fortran (ou est-ce pour ada:question:) lors de la compilation de mingw, aux bibliothèques gmp et mpfr

Bien sur, la seule absence de ces bibliotheques a peu de chances d'être responsable de la différence selon le choix de l'option d'optimisation... mais... Sait-on jamais :question:

[EDIT]il me semble qu'en lancant gcc -v en ligne de commande, tu devrait trouver dans la liste des parametres de configuration, s'ils ont été déclarés, --with-gmp et --with-mpfr

g++ -v me donne simplement :

Citation:

---

Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debugThread model: win32
gcc version 3.4.5 (mingw special)

---

De toute façon, je crois que je vais attendre de pouvoir tester sur mon ordinateur, avec d'autres compilateurs, et sur d'autres plate-formes. Parce que là, j'ai assez perdu de temps avec ça

Si, comme j'ai cru comprendre, ca passe avec -O1 -float-store ou avec -O1 -msse -fpmath=sse et pas avec -O1, c'est du soit a un bug de gcc qui ne fait pas toujours ce qu'il devrait faire dans la gestion de la precision -- mais je vois que tu es sous Windows et il me semble que sous Windows le probleme est generalement masque par la configuration du coprocesseur, mais je peux me tromper --, c'est soit un probleme dans ton code qui est tres sensible a la precision (et il n'est pas improbable que regler le probleme dans ton code active le probleme de gcc). Jouer avec les options risque de simplement masquer le probleme jusqu'a ce qu'il reapparaisse apres un changement mineur dans le code ou un changement de compilateur.

Dans ce cas, il faudrait faire voir ton code a quelqu'un qui s'y connait en analyse numerique pour etudier les caracteristiques de ton algo.

Autant pour moi, je me suis mal exprimé :oops:

Dès que je mets -O ou -O1, ça ne marche plus.
Seulement avec -ffloat-store, ça marche (sans -O)
Avec -O -ffloat-store, ça ne marche plus.


Je vais essayer de me débrouiller, merci bien :D

Fais tourner avec valgrind, les trucs bizarres tu les verras direct.

Donc voilà, j'ai enfin pu tout essayer.

Sous linux avec O3, ça marche parfaitement.

J'ai fait tourné valgrind, j'avais oublié un destructeur quelque part :roll: (enfin rien de grave). J'ai corrigé et ça ne marche toujours pas (ça aurait été étonnant que l'erreur provienne de là).

Donc, comme de toute façon, mon programme est très modulaire et que ce module n'est pas vraiment important, je crois que je vais le mettre de côté (en fournissant éventuellement une version "buguée" sous windows).

Merci à tout le monde