Discussion :

[millie]

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

[Sylvain Togni]

Ç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.

[Invité]

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

[Matthieu Brucher]

Tu compiles bien en -Wall sans warning ?

[millie]

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...

[Matthieu Brucher]

Tu peux utiliser efence pour vérifier ?

[millie]

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

[loufoque]

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.

[millie]

-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 :


Et sans, j'obtiens à tous les coups ceci :



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

[Invité]

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

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

[alskaar]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
    #define new    new(__FILE__, __LINE__)

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

[millie]

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.

[millie]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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))

[droggo]

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 ?

[Jean-Marc.Bourguet]

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.

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.

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?

[millie]

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

oui oui

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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Jean-Marc.Bourguet]

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.

[millie]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[mchk0123]

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) ?

[millie]

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.