Un conseil change de compilo (pas de version hein!) pour voir ...
Tu pourrais avoir de nouveaux message d'erreur indicatifs.
Version imprimable
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 :
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 çaCitation:
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)
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