La version 4.8 du compilateur GCC est disponible

Posté par  (site web personnel) . Édité par GeneralZod, Quentin Pradet, Sylvestre Ledru, claudex, Thomas Douillard, Benoît Sibaud, rootix, lamiricore et rewind. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
85
25
mar.
2013
GNU

La nouvelle version majeure du compilateur GCC du projet GNU vient de sortir.
Écrit à l'origine par Richard Stallman, le logiciel GCC (GNU Compiler Collection) est le compilateur de référence du monde du logiciel libre. Il accepte des codes source écrits en C, C++, Objective-C, Fortran, Java et Ada et fonctionne sur une multitude d'architectures.

Dans la suite de la dépêche, vous pourrez découvrir les nouveautés et les optimisations mises en œuvre dans cette version 4.8 de GCC

Sommaire

Refonte du code

GCC 4.8 est la première version stable développée en C++, opération qui s'inscrit dans le cadre de l'effort pour rendre le code de GCC plus compréhensible et plus facile à maintenir.

Néanmoins tout n'est pas permis puisque, selon les développeurs, une utilisation de toutes les fonctions de C++ pourrait dégrader la lisibilité. Seul un sous-ensemble de C++ est utilisé afin de réellement simplifier le code. Le sous-ensemble de C++ choisi rend donc le code plus clair et plus abordable pour les nouveaux contributeurs. Trois exemples illustrent les modifications effectuées :

  • des conteneurs C++ standards (tels que std::vector ou std::unordered_map) sont préférés aux équivalents idiosyncrasiques de GCC ;
  • l'utilisation raisonnée de templates implique un typage plus strict et un code plus sûr, ce qui n'était pas possible avec le préprocesseur utilisé en C ;
  • une partie du travail du ramasse-miettes de GCC peut être remplacée par les smarts pointers C++ ou des pools mémoire.

Pour ces différents cas de figures et quelques autres, Ian Taylor a présenté des cas concrets de conversion en C++ de code GCC, ce qui met en évidence les bénéfices d'une telle opération.

Améliorations générales

Deux outils originellement développés par Google pour Clang ont été intégrés à GCC :

  • Address Sanitizer (ASan): un détecteur d'erreur d'accès mémoire rapide. Activable avec le switch -fsanitize=address, il permet de détecter des erreurs telles que :
    • accès à une zone mémoire après libération
    • heap/stack/global buffer overflow
  • ThreadSanitizer (TSan): outil basé sur valgrind (équivalent à Hellgrind) qui détecte les accès concurrents à une ressource (data race condition). Activable avec le switch -fsanitize=thread.

Une nouvelle optimisation expérimentale permet de mieux paralléliser les boucles de code. Cette optimisation s'active via -floop-nest-optimizeet l'algorithme utilisé se base sur l'outil PLUTO qui, au vu des comparaisons disponibles sur le site, semble très prometteur.

Un autre niveau d'optimisation, activable avec -Og, permet de compiler rapidement le code source tout en conservant un maximum d'informations permettant le déboguage. Selon Richard Guenther c'est ce niveau qui est à privilégier lors du développement du code avant tout à la fin, d'optimiser plus radicalement avec -O2 ou -O3.

C et dérivés

  • Amélioration des diagnostics (GCC revient au niveau de clang):

    • Lors d'une erreur ou d'un warning, la portion fautive est soulignée avec le symbole ^ indiquant la colonne.
    • Les macros sont étendues lors d'une erreur les impliquant.

  • -pedantic est déprécié, il faut maintenant lui préférer -Wpedantic.

  • Suite à une remarque de Linus Torvalds sur l'utilité de -Wshadow, les variables locales cachant des fonctions ne déclenchent plus de warning.

C++

  • introduction de la version 7 de l'ABI C++ (la version 2 reste par défaut)
  • amélioration du support de C++11
    • héritage de constructeur: on peut explicitement demander d'importer les constructeurs de la classe mère. Néanmoins, il faut faire attention au cas où on rajoute une nouvelle variable membre.
// cas 1
struct Base { Base(int); };

struct Derived : Base {
    using Base::Base; // importe Base::Base(int)
    Derived(double); // ajoute un nouveau constructeur
};

// cas 2
struct Base { Base(int); };

struct Derived : Base {
   using Base::Base;
   Derived(double);

   int x; // KO: n'existe pas dans Base et n'est donc pas initialisé
};

// cas 3
struct Derived : Base {
   using Base::Base;
   Derived(double);

   int x{0}; // OK: toujours initialisé en utilisant la syntaxe d'initialisation uniforme
};
  • support complet du modèle mémoire de C++11 qui garantit qu'un accès à une zone mémoire est sûr en lecture ou sinon requiert l'acquisition d'un verrou
  • support du thread-local storage avec l'implémentation du mot clé thread_local
  • introduction du switch -std=c+1y qui permet de tester les fonctionnalités prévues dans la prochaine norme C++17. Actuellement, une seule fonctionnalité est implémentée, il s'agit de la déduction du type de retour pour les fonctions (c'est l'équivalent de auto, introduit avec C++11, pour les variables)

Architectures

GCC 4.8 supporte maintenant la version 64 bits de l'architecture ARM. Cette version est un port séparé par rapport à ARM 32 bits parce que la nouvelle architecture a été largement refondue et nettoyée (voir l'excellente analyse de RealWorldTech).
Toujours concernant AArch64, un support initial pour les implémentations des Cortex-A53 et Cortex-A57 est disponible avec les options -mcpu=cortex-a53 et -mcpu=cortex-a57.

Portage vers GCC 4.8

Cette version de GCC introduit en plus des changements mentionnés plus hauts des corrections qui peuvent empêcher des projets existants de compiler. La plupart de ces changements sont de simples warnings qui peuvent se transformer en erreurs quand ils sont combinés avec -Werror :

  • -Wmaybe-uninitialized détecte de nouveaux cas de variables non-initialisées,
  • -Wsizeof-pointer-access signale de nouveaux cas problématiques d'accès mémoire
  • et -Wunused-local-typedefs invoque un warning quand un typedef local n'est pas utilisé en C++.

Un autre cas courant est la détection de comportements indéfinis (undefined behavior) grâce à des changements dans la façon de transformer les boucles.

Des développeurs ont recompilé la totalité des paquets de rawhide, la version de développement de Fedora, ce qui a permis de détecter quelques bugs dans GCC 4.8 mais aussi dans 67 des 11687 paquets, soit 0.6%.

Suivre le développement de GCC

Si vous voulez suivre le développement de GCC sans nécessairement vous plonger dans le détail des commits ou des annonces sur les listes de diffusion, un bon moyen est de suivre le blog de Nick Clifton. Ce développeur GCC propose presque chaque mois une synthèse des nouveautés de la chaine de compilation GNU.
Lire rétrospectivement les articles concernant GCC 4.8 permet de mieux mesurer tout le travail et les ajouts qui sont incorporés dans cette version :

Aller plus loin

  • # Fortran !

    Posté par  (site web personnel) . Évalué à 10.

    GCC, c'est aussi Fortran (et même Go avec un début de l'implémentation 1.1). Ada suit son rythme propre…

    Pour Fortran, les fichiers d'en tête généré automatiquement sont modifiés… Dommage, il va falloir tout recompiler petit à petit. Ce serait bien de normaliser ces fichiers entre compilateur.

    J'ai noté l'ajout de BACKTRACE qui doit donner la liste des fonctions actives à un instant donné. Pratique au développement. http://gcc.gnu.org/onlinedocs/gfortran/BACKTRACE.html

    Le support complet de variable polymorphique (CLASS*). Fortran continue son bonhomme de chemin comme langage objet dédié au calcul. A chaque version, la norme 2003 et 2008 ont de plus en plus d'élément implémenté.

    http://gcc.gnu.org/wiki/Fortran2003Status
    http://gcc.gnu.org/wiki/Fortran2008Status

  • # et java ?

    Posté par  . Évalué à 6.

    Est ce dans les habitudes des développeurs java d'utiliser le compilateur GCJ au lieu du JDK  ?

    • [^] # Re: et java ?

      Posté par  (site web personnel) . Évalué à 10.

      Pas vraiment… C'est pas à jour sur la spécification Java. Il y a des pans entiers de Java qui sont pas gérés (Swing au hasard).
      Le passage de Java en GPL a mis une bonne claque à GCJ (cf le peu de news sur http://gcc.gnu.org/java/)
      Dans Debian (et donc Ubuntu), tout est compilé avec les OpenJDK 6 ou 7 (sauf pour les architectures où OpenJDK est pas porté).

    • [^] # Re: et java ?

      Posté par  . Évalué à 10.

      GCJ n'évolue plus depuis la libération d'openJDK, la plupart des développeurs qui travaillaient dessus sont passés sur openJDK. GCJ s'est arrêté à Java 5 (pas tout à fait à 100%) alors que Java 8 pointe le bout de son nez et que Java 6 est passé en support communautaire.

  • # Warnings

    Posté par  . Évalué à 2.

    Beaucoup de monde râlait à cause des warnings et messages d'erreur kikoolol de clang, maintenant que GCC s'y met j'aimerais bien savoir ce que vont en dire ces récalcitrants :D

    • [^] # Re: Warnings

      Posté par  (site web personnel) . Évalué à 6.

      je ne vois pas trop ce qu'on peut reprocher aux messages d'erreur de clang , c'est l'emploi de la couleur qui les rend "kikoolol" ?

      • [^] # Re: Warnings

        Posté par  . Évalué à 4.

        Faut croire que ça n'a pas plu à tout le monde. C'est comme avec cmake, yen a qui trouvent ça vraiment dégeux. Pour ma part j'aime bien, c'est beaucoup plus clair.

        • [^] # Re: Warnings

          Posté par  . Évalué à 3.

          Dégueu par rapport à quoi ? Si c'est par rapport au merdier autoconf/automake/auto-chaipasquoi, comment dire …

          • [^] # Re: Warnings

            Posté par  . Évalué à 2. Dernière modification le 25 mars 2013 à 20:13.

            En effet. Je ne saurais dire ce qui ne "va pas" dans ces outils modernes.

            • [^] # Re: Warnings

              Posté par  . Évalué à 4.

              Bah c'est le problème du moderne, ça pousse parfois à l'évolution donc du coup certains vont blo

            • [^] # Re: Warnings

              Posté par  . Évalué à 4. Dernière modification le 26 mars 2013 à 21:57.

              Moi je sais ce qui ne va pas. Cela met trop en avant les erreurs/warning de compilation.
              Je travaille dans la gestion de configuration logicielle( je n'ai pas une formation de développeur à la base, mais on doit quand même lire rapidement les logs surtout quand c'est écrit en rouge ou en gras), et les développeurs/responsables de projet n'aiment pas quand on les appelle pour demander:
              "c'est normal d'avoir 150 erreurs de compilation et 1500 warning?"
              et qu'ils se sentent obligés de répondre:
              "oui c'est normal, on a pas implémenté tel ou tel truc, mais ne vous inquiétez pas, ça ne part pas chez le client, c'est juste pour aller en validation afin de tester telle ou telle fonctionnalité, mais par contre il ne faut surtout pas mettre alpha, beta ou rc dans la version au cas où…".
              Et ils se sentent obligé de mettre un "BUILD OK" en gras à la fin malgré toute la merde qu'il y a avant afin qu'on arrête de poser des questions…

              • [^] # Re: Warnings

                Posté par  . Évalué à 2. Dernière modification le 27 mars 2013 à 11:20.

                Hum. Il faudrait peut-être leur dire de désactiver les warnings pour les parties de code non implémentées pour éviter les erreurs, non ?

                Parce que de toute façon, que ça soit en rouge ou en blanc sur noir, je ne vois qu'une différence : d'une part ça passe inaperçu et à peu près tout le monde s'en fout et de l'autre part, on a les erreurs, on les voit, personne ne s'en fout mais ceux qui savent se foutent de ceux qui ne sont pas sensés s'en occuper, c'est à dire vous, et laissent planer des erreurs alors qu'il est possible de les masquer. Et en parlant de masquer, on peut déjà désactiver la couleur avec clang. Comme ça on a des erreurs, mais tout le monde s'en fout :)

                PS : par « tout le monde s'en fout », je ne dis pas que c'est négatif.

              • [^] # Commentaire supprimé

                Posté par  . Évalué à -10. Dernière modification le 26 août 2013 à 13:56.

                Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 1.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Warnings

                Posté par  . Évalué à 3.

                Personnellement, je préfèrerais que ce soit carrément dans le code. Comme avec l'annotation SuppressWarnings, quitte à avoir un warning qui dit qu'il existe des SuppressWarnings dans le code. Du coup il n'y aurait plus qu'un warning par unité de compilation au lieu d'une série, comme ça tu montre que tu sais quel warning tu ignore et c'est dis au même endroit que le code. Tu peut voir facilement s'il existe toujours des warnings supprimés et qui conque qui compile sans en savoir plus comprend très bien que les warnings de suppression de warnings sont des cas gérés.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Warnings

        Posté par  . Évalué à 1.

        De toute façon GCC n'utilise pas de couleurs.

        • [^] # Re: Warnings

          Posté par  (site web personnel) . Évalué à 8.

          ah oui je me souviens que j'avais vu la discussion sur la ml gcc a propos de l'introduction de la couleur. Ca avait été abandonné sur le principe de "oh mon dieu mais que vont devenir les daltoniens" ..

          • [^] # Re: Warnings

            Posté par  . Évalué à 1.

            La couleur ça peut être sympa quand c'est bien utilisé.
            Par contre, dans beaucoup de cas le choix des couleurs par défaut est trop contrasté et tend à être à la fois illisible en terminal noir et en terminal blanc.

            Si c'est bien fait, j'applaudirai!

            • [^] # Re: Warnings

              Posté par  . Évalué à 2.

              Et quand on a un terminal noir sur jaune clair, je ne te raconte pas ce que donne le rose !

              • [^] # Re: Warnings

                Posté par  . Évalué à 4. Dernière modification le 27 mars 2013 à 10:57.

                Et encore c'est que tu n'as jamais vu ce que çà donne avec un terminal en braille.

            • [^] # Re: Warnings

              Posté par  . Évalué à 2.

              C'est une palette qui se personnalise (16 couleurs en général), dans gnome-terminal la palette Tango est pas mal.

    • [^] # Re: Warnings

      Posté par  . Évalué à 6.

      On doit pas fréquenter les mêmes développeurs, la plupart se plaignent plutôt des messages cryptiques de GCC

      • [^] # Re: Warnings

        Posté par  . Évalué à 10.

        c'est ça de faire des programmes qui ne compilent pas du premier coup ;-)

      • [^] # Re: Warnings

        Posté par  . Évalué à 1.

        Rend moi ma moitié ! :D

  • # Déprécié ?

    Posté par  (site web personnel) . Évalué à 7.

    -pedantic est déprécié

    Attention aux faux-ami, et à ne pas confondre deprecated (obsolète) et depreciated (déprécié, terme financier).

    • [^] # Re: Déprécié ?

      Posté par  (site web personnel) . Évalué à 7.

      obsolète n'est pas non plus la bonne traduction de deprecated.
      obsolète en Anglais c'est plutôt out of date.
      Dans deprecated il y a l'action d'avoir rendu obsolète.

      Sur l'article Dépréciation (informatique) deprecated est traduit par déprécié ou même frappé de dépréciation.

      Sur JargonF, deprecated est traduit par déconseillé.

      Comment connaitre la traduction proposée par Traduc.Org ?

      Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

      • [^] # Re: Déprécié ?

        Posté par  (site web personnel) . Évalué à 7.

        Sur le forum de WordReference, uhhovr propose de traduire deprecated par déclaré obsolète.

        Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

        • [^] # Re: Déprécié ?

          Posté par  . Évalué à 0.

          C'est pas mal comme traduction, mais là aussi "déclaré" frôle l'anglicisme. Du coup j'en conclue que quitte à sombrer, autant "déprecier" directement.

          "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

          • [^] # Re: Déprécié ?

            Posté par  . Évalué à 2.

            J'ai appris un nouveau terme aujourd'hui! vous les gars sont très intelligents.

            Les possibilités sont aussi interminable que votre imagination.

  • # ASan et TSan

    Posté par  . Évalué à 8.

    À la première lecture, je n'avais pas compris à quoi servait ASan et TSan vu qu'ils ne font que réimplémenter des fonctionnalités de valgrind.
    En fait l'information importante c'est qu'en instrumentant le code, l'overhead runtime est bien plus faible qu'avec valgrind: ASan parle d'un facteur 2 en ralentissement, alors que memcheck de valgrind annonce entre 40 et 120.

    Je n'ai pas encore testé mais avoir un memcheck rapide c'est vraiment Bien!

    • [^] # Re: ASan et TSan

      Posté par  (site web personnel) . Évalué à 7.

      c'est clair que le -fsanitize=address est infiniment plus rapide que valgrind, a l'usage c'est vraiment agreable, y'a pas de ralentissement notable ! En contrepartie il y a des choses qu'il ne detecte pas , genre l'utilisation de memoire non initialisée

Suivre le flux des commentaires

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