Forum Programmation.c++ Bugs dans g++ ?

• # To bug or not to bug…

  Posté par Sylvain Sauvage le 28 février 2007 à 01:53. Évalué à 4.

  

  Il n'est pas évident qu'il s'agisse de bogues de l'optimisation mais plutôt de bogues qui sont révélés par l'optimisation.
  
  Certaines constructions peuvent sembler correctes au programmeur mais peuvent poser des problèmes après passage par le compilateur. Celles auxquelles j'ai le plus été confronté concernent les variables ou résultats temporaires. Ces temporaires sont supprimés s'ils ne servent pas (et ils servent avec -g, ne serait-ce que pour en connaître le nom pour le débogage).
  
  Pour donner un exemple, la classe std::string fournit la méthode c_str() pour récupérer le contenu de la chaîne sous forme de char*. Mais ce char* est temporaire et il est plus sage d'en faire une copie avant de s'en servir.

• # Valgrind forever

  Posté par Pierre Palatin (site web personnel) le 28 février 2007 à 08:31. Évalué à 4.

  

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

• # -Wall ?

  Posté par gaaaaaAab le 28 février 2007 à 11:27. Évalué à 1.

  

  Dans le genre flag de compilation qui sauve.
  Accessoirement, corriger *tous* les warnings, c'est *bien* :-)

• # Merci

  Posté par MiniMoi le 28 février 2007 à 11:39. Évalué à 1.

  

  Merci pour toutes ces réponses.
  Jer suis en train de voir ce que ça donne avec valgrind. Pour l'instant sur le code compilé avec -03 valgrind segfault (après le programme tout de même), je suis en train de voir ce que ça donne sur la version compilée en -g.
  
  Merci pour le truc des variables temporaires, je penchais aussi pour un problème de mémoire qui est accédée différemment selon les flags d'optimisation... Reste à trouver ça, parce que je e peux pas compiler le programme en -g (le prog tourne presque 3x plus vite avec -O3 !).
  
  Et sinon, aucun warning avec -Wall...

  • [^] # Re: Merci

    Posté par Obsidian le 28 février 2007 à 12:28. Évalué à 2.

    

    Ton programme est sous quelle licence ?
    
    Si c'est en GPL, mets-le en ligne, on trouvera plus vite !

• # Irrationel

  Posté par TazForEver le 28 février 2007 à 12:52. Évalué à 1.

  

  C'est facile d'incriminer l'outil immédiatement.
  Donne ton code, ouvre un bug gcc, montre une stacktrace.
  
  Y a 99,999999% de chance que ton code contienne juste un écrasement de pile plutôt que ce soit g++ qui génère du mauvais code.
  
  Rasoir d'Ockham.

  • [^] # Re: Irrationel

    Posté par MiniMoi le 28 février 2007 à 13:43. Évalué à 1.

    

    Je n'incriminais pas directement g++, contrairement à ce que le titre du post pourrait le faire croire...
    Je n'ai qu'une connaissance très partielle du C++ et du C, j'étais juste intrigué par le fait que le bug ne se produise qu'avec certaines options de compilation et certaines versions de g++...
    
    D'ailleurs depuis j'ai trouvé le bug, une écriture au-delà des limites d'un tableau...
    Ca vous donne pas envie de persévérer dans le C++ ce genre de choses. Dans ma jeunesse (classes prépa) OCaml signalait immédiatement ce genre de choses, je ne savais pas que g++ ne savait pas reconnaitre un probleme comme le précédent :
    
    
    for ( int i=3 ; i< 7 ; i++ )
    {
    temp_vect[i] = 14+i;
    }
    
    
    avec bien sur temp_vect[] qui n'est pas assez grand, et déclaré en variable globale...
    
    
    C'est bon à savoir, je ferais attention maintenant.
    Mais bon, les projets d'études quand on a a pas de cours de programmation, faits à plusieurs avec personne qui ne connait vraiment bien la programmation, ça donne forcément ce genre de problèmes...

    • [^] # Re: Irrationel

      Posté par lmg HS (site web personnel) le 28 février 2007 à 14:35. Évalué à 1.

      

      C'est un grand classique. Le C et le C++ privilégient les perfs aux vérifications. C'est à nous de faire attention.
      
      Ceci dit, au lieu de faire du C avec des classes, fais du C++. Au lieu d'utiliser un tableau, utilise un std::vector et assure-toi que la S(T)L que tu utilises est "checkée" -- certaines versions de l'opérateur [] des vecteurs vérifient que l'indice soit bon à l'aide d'un assert, ce qui aurait au moins planté le programme en mode debug.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.