Même si effectivement il y a toujours des bugs potentiels dans gcc et que donc c'est pas à exclure, amha considère que le problème est dans ton code, ce sera vrai dans 99% des cas...
Ce genre de comportement (bug avec certaines versions de gcc et pas d'autre et selon les options de compimation) est assez classique de problème de gestion de la mémoire. Donc à mon avis, la première chose à faire est de passer ton programme (avec infos de debug) à valgrind et de corriger *toutes* les erreurs que valgrind te dit.
Même remarque pour valgrind que pour gcc : souvent on se dit "ah ouais mais il a tort" - mais en pratique il se trompe très rarement, surtout sur du code pas trop tricky. La STL fait dire à valgrind des fois que il y a des leaks (pareil pour pthread) mais ce n'est pas les leaks qui sont probablématiques en l'occurrence :)
Un autre truc à tester, surtout si tu es friand de casts dans ton code, c'est de compiler avec du -fno-strict-aliasing ; les problèmes liés au strict aliasing représentent le bug le plus souvent signalé ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920 ), mais il ne s'agit *pas* d'un bug de gcc. Voir la page de man de gcc pour plus d'infos sur le pkoi du comment du strict-aliasing (en gros, une règle du C dit que deux pointeurs de type différent, par ex. int* et float*, pointent nécessairement sur des données différentes, ce qui permet à gcc de faire des optimisation plus agressives).
# Valgrind forever
Posté par Pierre Palatin . En réponse au message Bugs dans g++ ?. Évalué à 4.
Ce genre de comportement (bug avec certaines versions de gcc et pas d'autre et selon les options de compimation) est assez classique de problème de gestion de la mémoire. Donc à mon avis, la première chose à faire est de passer ton programme (avec infos de debug) à valgrind et de corriger *toutes* les erreurs que valgrind te dit.
Même remarque pour valgrind que pour gcc : souvent on se dit "ah ouais mais il a tort" - mais en pratique il se trompe très rarement, surtout sur du code pas trop tricky. La STL fait dire à valgrind des fois que il y a des leaks (pareil pour pthread) mais ce n'est pas les leaks qui sont probablématiques en l'occurrence :)
Un autre truc à tester, surtout si tu es friand de casts dans ton code, c'est de compiler avec du -fno-strict-aliasing ; les problèmes liés au strict aliasing représentent le bug le plus souvent signalé ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920 ), mais il ne s'agit *pas* d'un bug de gcc. Voir la page de man de gcc pour plus d'infos sur le pkoi du comment du strict-aliasing (en gros, une règle du C dit que deux pointeurs de type différent, par ex. int* et float*, pointent nécessairement sur des données différentes, ce qui permet à gcc de faire des optimisation plus agressives).