URL: https://linuxfr.org/news/le-compilateur-gcc-5-1-harder-better-faster-stronger Title: Le compilateur GCC 5.1 : harder, better, faster, stronger Authors: patrick_g Stéphane Aulery, BAud, khivapia, Nils Ratusznik, Rolinh, Anonyme, Yves Bourguignon, palm123, Martin Peres, Benoît Sibaud, Clément David, Ontologia, Sytoka Modon, esdeem, Nicolas Boulay, Spyhawk, rpnpif, Xavier Teyssier et rogo Date: 2014年12月29日T15:25:14+01:00 License: CC By-SA Tags: gcc, richard_stallman, objective-c, libreoffice, fortran, ada et fedora Score: 72 La sortie de la nouvelle version majeure du [compilateur GCC](http://gcc.gnu.org/) du projet GNU [a été annoncée](https://gcc.gnu.org/ml/gcc-announce/2015/msg00000.html) le 22 avril dernier. Écrit à l’origine par Richard Stallman, le logiciel GCC (_GNU Compiler Collection_) est le [compilateur](http://fr.wikipedia.org/wiki/Compilateur) de référence du monde du logiciel libre. Il accepte des codes source écrits en C, C++, Objective-C, Fortran, Java, Go et Ada et fonctionne sur une [multitude d’architectures](http://en.wikipedia.org/wiki/GNU_Compiler_Collection#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 5.1 de GCC. ---- [Liste des nouveautés de GCC 5.1](https://gcc.gnu.org/gcc-5/changes.html) [Cauldron 2014](https://gcc.gnu.org/wiki/cauldron2014) [Phoronix : Just-In-Time (JIT) Compilation Support Merged For GCC 5](http://www.phoronix.com/scan.php?page=news_item&px=MTgzNjk) [Phoronix : OpenMP 4.0 Offloading For Intel MIC Lands In GCC 5](http://www.phoronix.com/scan.php?page=news_item&px=MTgzNzk) [Intel : New optimizations for X86 in upcoming GCC 5.0](https://software.intel.com/en-us/blogs/2014/11/24/what-is-new-for-x86-in-upcoming-gcc-50) [Phoronix : Automatic Feedback Directed Optimizer Merged Into GCC](http://www.phoronix.com/scan.php?page=news_item&px=MTgxOTg) [Phoronix : GCC 5 Will Have Full Support For Intel's Cilk Plus](http://www.phoronix.com/scan.php?page=news_item&px=MTc4NDY) [Phoronix : GCC 5.0 Adds DragonFlyBSD Support](http://www.phoronix.com/scan.php?page=news_item&px=MTc3ODU) [Phoronix : OpenACC Changes Merged Today For GCC 5](http://www.phoronix.com/scan.php?page=news_item&px=GCC-5-OpenACC-Stage-3-Closing) ---- # Nouvelle numérotation On peut noter que le schéma de numérotation des versions de GCC a changé puisqu’on passe directement de la version 4.9 à la 5.1. Dorénavant toutes les versions majeures seront de la forme x.1 et les versions mineures (corrections de bug) incrémenteront le dernier chiffre. Ainsi les prochaines versions mineures seront les 5.2 puis 5.3 tandis que la prochaine version majeure, d’ici un an environ, sera la 6.1. Intégration dans les distributions ================================== Pour se mettre en conformité avec `C++11`, cette nouvelle version de GCC contient une mise à jour de l’ABI (Application Binary Interface) pour les objets `std::string` et `std::list` de la bibliothèque standard C++ qui impose une re-compilation des logiciels codés en C++ ainsi que de toutes leurs dépendances en C++. Deux voies se dessinent pour l’intégration de cette version dans les distributions. L'approche pragmatique ---------------------- Certaines distributions ont prévu d'assurer un passage en douceur (voir [le plan pour Fedora 22](http://fedoramagazine.org/gcc-5-in-fedora-whats-an-abi-and-what-happens-when-we-change-it/)). Le compilateur fournira les dernières avancées du langage tout en générant du code utilisant la vieille ABI. Les logiciels utilisant les bibliothèques pre-C++11 ne devraient donc pas poser de problème. Notons que les deux versions de l’ABI sont prises en compte par libstdc++ grâce au [versionage des symboles](http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi), ce qui veut dire qu’il est possible de développer en utilisant la nouvelle version. Il suffit de définir une macro spéciale `_GLIBCXX_USE_CXX11_ABI` et le programme utilisera la convention `C++11`. Utiliser cette macro implique que les bibliothèques dépendantes utilisent aussi la nouvelle convention. Afin de simplifier la migration vers la nouvelle ABI, les bibliothèques C++ les plus utilisées comme `boost` devraient être compilées avec les deux versions, comme la libstdc++. L’effort de maintenance des paquetages serait alors plus important et il n’est pas dit que tous les mainteneurs fassent cet effort. Comme dans le cas de Fedora 23, il est souvent prévu de migrer vers la nouvelle version de l’ABI à terme. La transition se réaliserait alors sur plusieurs versions de la distribution. La migration totale ------------------- D'autres distributions ont décidé de ne gérer qu’une seule ABI (voir le plan pour [Arch Linux](http://www.reddit.com/r/archlinux/comments/2vgxrj/how_will_arch_deal_with_gcc_5) et [Gentoo](https://wiki.gentoo.org/wiki/Upgrading_GCC#ABI_Changes)). La migration risque d’être plus douloureuse pour tout logiciel non fourni par la distribution. On pensera aux logiciels privateurs, mais aussi aux binaires que l’on cherche parfois à ne pas recompiler. Toutefois cette approche a l’avantage de très largement simplifier la maintenance de libstdc++. Les symboles disponibles ne sont alors que ceux définis dans le standard, sans gestion de version. Afin de réduire le risque, la gestion des symboles ABI C++98 pourrait être conservée dans la libstdc++, mais _quid_ des bibliothèques ? Les empaqueteurs feront-ils l’effort de prendre en compte l’ancienne ABI ? Prise en charge de DragonFly BSD ================================ GCC est inclus depuis longtemps dans le système de base de DragonFly. Cependant, John Marino, le développeur DragonFly qui s’occupe notamment de la maintenance des deux compilateurs inclus dans base, devait maintenir un ensemble de patches pour le bon fonctionnement de GCC. Il a fini par [les soumettre](https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01128.html) en amont et ces derniers ont été acceptés. DragonFly est donc depuis pris en charge par GCC de manière officielle. Depuis le 10 février dernier, le futur GCC 5.1 est [inclus](http://lists.dragonflybsd.org/pipermail/commits/2015-February/417828.html) dans la version en développement de DragonFly. Il remplace GCC 4.4 qui était jusqu'alors inclus aux côtés de GCC 4.7. Le 22 avril, soit le jour de la sortie de la version stable du compilateur, GCC 5.1 [remplace](http://lists.dragonflybsd.org/pipermail/commits/2015-April/418427.html) GCC 4.7 en tant que compilateur par défaut, ce dernier devenant le compilateur alternatif. Nouvelles optimisations ======================= ### Optimisation à l'édition des liens (link-time optimization) Une passe de fusion des types C++ a été implémentée, qui permet une meilleure dévirtualisation des méthodes virtuelles utilisées par les mécanismes d’héritage. Il est maintenant possible de spécifier l’optimisation (Ofast, O2...) au niveau des fonctions et non plus au niveau du programme global. Les performances (utilisation mémoire et temps de calcul) de cette phase d’optimisation ont été améliorées, dans la continuité des progrès effectués depuis la première version de GCC (4.6) à proposer l’optimisation à l’édition des liens. Selon [l'excellent post d'Honza Hubička](http://hubicka.blogspot.cz/2015/04/GCC5-IPA-LTO-news.html) qui cite des chiffres d'Andi Kleen lors d'un build du noyau Linux, on passe d'un ralentissement de 108% de la phase de build avec GCC 4.8 à seulement 2-15% avec GCC 5.1. Toujours dans le même article d'Honza (courrez le lire... on vous dit qu'il est excellent !) on apprend que la fonction LTO améliorée permet une réduction de 17% du code de LibreOffice (36% si on active en plus le profilage automatique). ### Optimisation par profilage automatique Donner un profil d’utilisation de l’application, au niveau code, est utile pour le compilateur. Il peut s’agir de la détection des boucles les plus fréquentes, des cas les plus probables de branches difficiles à déterminer, etc. Par exemple, s’il sait qu’un `if` / `then` / `else` tombe dans le `else` dans 80 % des cas, le compilateur pourra placer le code du `else` directement à la suite du `if` (inversant ainsi le `then` et le `else`) pour réduire les sauts de code et la pression sur le cache d’instructions. Une infrastructure d’instrumentation du code basée sur [gprof](http://fr.wikipedia.org/wiki/Gprof) a toujours existé dans GCC (`fprofile-generate`, `fprofile-use`). Google en a proposé une nouvelle, basée sur l’outil de profilage [perf](http://en.wikipedia.org/wiki/Perf_%28Linux%29) proposé par Linux. Selon les notes de version, le benchmark SPEC2006 sur architecture x86-64 voit son score amélioré de 4.7% avec le nouveau auto-FDO de Google alors que l'amélioration était de 7.3% avec la fonction classique FDO (feedback directed optimization). Si les optimisations sont de moins bonne qualité que l’infrastructure classique de GCC, le temps d’exécution du programme instrumenté (et donc le temps de récupération du profil) est très largement amélioré. D’autres améliorations concernent la robustesse du profilage aux modifications du code source après coup. Cette activité étant chronophage, on ne veut pas avoir à la répéter trop souvent. ### Allocation des registres De manière similaire à ce qui se passe sur carte graphique, il peut être profitable de recalculer une valeur plutôt que d’aller la rechercher en mémoire. Une nouvelle passe (nommée "control-flow sensitive global register rematerialization") réalise ce travail au niveau de l’allocation des registres. Cette nouvelle passe d'optimisation permet un gain de 1% (ARM) et 0.5% (x86-64) sur le benchmark SPEC2000. ###Vectorisation GCC 5.1 apporte une nouvelle optimisation dans le cas des séquences consécutives de loads/stores. Selon la description qu'en donne [le développeur Intel Evgeny Stupachenko](https://software.intel.com/en-us/blogs/2014/11/24/what-is-new-for-x86-in-upcoming-gcc-50), ces séquences sont maintenant vectorisées automatiquement par GCC 5.1 ce qui entraine un gros gain de performance (multiplication par 6,5 par rapport à GCC 4.9 sur architecture Silvermont et par 3 sur architecture Haswell). ### Assainissement du code De nouvelles instrumentations (développées initialement pour LLVM) permettent de détecter des bugs à l’exécution. La version 4.9 de GCC proposait un mécanisme de détection d’accès mémoire interdits ou de certains comportements indéfinis par la spécification du langage. Dans GCC 5.1, il s’agit de détecter des opérations particulières sur les flottants (comme diviser par zéro), des accès à des tableaux en dehors des bornes, d’autres formes d’accès mémoire illégaux... # Nouveautés concernant les langages Prise en charge des interfaces de programmation destinées à la parallélisation OpenMP version 4.0 (sur CPU classique et Xeon Phi) et OpenACC 2.0 (destinées aux cartes graphiques). ### Langages C et C++ Gestion des extensions Intel CilkPlus (parallélisation de code). Par rapport à OpenMP qui est à l'origine plutôt orienté "parallélisation de boucles", CilkPlus est plutôt orienté "parallélisation de tâches" : par un simple mot-clef ajouté, un appel de fonction est lancé dans un _thread_ indépendant. Ajout de fonctions intégrées pour la récupération de débordement en arithmétique entière. Cette information n’est pas accessible simplement en C/C++ alors qu’elle est toujours remontée par le processeur. Ces fonctions ont été implémentées pour la compatibilité avec Clang. Rappelons que de nombreuses fonctions intégrées permettent d’utiliser directement une instruction assembleur précise, comme les instructions SSE. De nombreuses fonctionnalités de C++ 2014 sont maintenant prises en charge tant par le compilateur que par la bibliothèque standard. ### Go GCC prend complètement en charge Go 1.4.2. Il fournit également les deux outils [go](http://golang.org/cmd/go/) et [gofmt](http://golang.org/cmd/gofmt/). ### Fortran La [couverture des fonctionnalités de Fortran 2003](https://gcc.gnu.org/wiki/Fortran2003Status) est presque complète avec l’ajout de trois modules d’arithmétiques IEEE (IEEE_FEATURES, IEEE_EXCEPTIONS and IEEE_ARITHMETIC). Il reste encore deux modules en cours d’implémentation (types dérivés paramétrables, entrée/sortie pour les types dérivés) et six modules dont l’implémentation est partielle sur un total de cinquante-sept. [Pour Fortran 2008](https://gcc.gnu.org/wiki/Fortran2008Status), GCC propose une implémentation complète mais expérimentale des `coarrays` avec l’option `-fcoarray=lib`. C’est un bond en avant depuis une première prise en compte partielle en 2010. Il s'appuie sur le projet [OpenCoarrays](http://www.opencoarrays.org/) pour l'implémentation multi-image, qui utilise en sous main les bibliothèques MPI et [GASnet](http://gasnet.lbl.gov/) (Global-Address Space Networking) pour les communications inter-nœuds. Pour Fortran 2015, GCC prend en charge `IMPLICIT NONE` (external, type) et étend l'instruction `ERROR STOP` aux procédures pures. Les développeurs Fortran bénéficient d’autres petites améliorations comme : - la coloration (partielle) de la sortie du compilateur avec l’option `-fdiagnostics-color` ; - l’option `-Wtabs`, modifiée pour avertir par défaut des tabulations qui empoisonnent le code () ; - l’option `-Werror=line-truncation`, activée par défaut pour prévenir de la troncature automatique des lignes ; - l’option `-Wuse-without-only` qui prévient de l’importation complète, et potentiellement erronée, de tous éléments publics d’un module ; - une correction importante des fonctions `READ` / `WRITE` pour les programmes localisés ; - des extensions pour le calcul parallèle (TS18508). # Principales nouveautés concernant les architectures matérielles cibles ### ARM et ARM 64 bits (AArch64) Adaptation de la génération du code pour certains modèles, adaptations à diverses variantes, support de nouveaux processeurs. ### AVR Cette architecture utilisée par bon nombre de microcontrôleurs est gérée de manière différente par GCC 5. La grande variabilité des fonctionnalités nécessite maintenant d'utiliser un fichier spécifique pour l'appareil ciblé. ### x86 et amd64 Support des futures instructions AVX vectorielles sur 512 bits des futurs processeurs Intel (et sans doute AMD). Actuellement, les dernières générations gèrent des registres allant jusqu'à 256 bits (AVX et AVX2). Ces instructions sont notamment utilisées par le compilateur lors de la vectorisation des boucles. Support des futures instructions de protection mémoire [[en:Intel MPX]] qui aideront à détecter des erreurs mémoire de type [[buffer overflow]] dont profitent typiquement les codes malveillants. Voir [cette page dédiée sur le wiki GCC](https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler) qui décrit en détail cette amélioration substantielle de la sécurité du code. Nouvelles options pour le profiling de code, l'alignement, et la gestion du registre RAX: quand les instructions SSE ne sont pas utilisées (typiquement dans le noyau Linux qui les désactive automatiquement), il arrive qu'il ne soit pas nécessaire de mettre ce registre à jour. Le registre RAX sert en effet à déterminer, selon la convention d'appel, comment sauver les registres lors d'un appel de fonction. ### MIPS Prise en charge de nouveaux processeurs et nouvelles ABI. # Rapports de bugs Une nouvelle option a été ajoutée à GCC: quand une erreur interne de compilateur apparaît (ICE, toujours liée à un bug de GCC suite à une mauvaise gestion d'un bon ou mauvais code), il est maintenant possible de générer un rapport de bug utile aux développeurs de GCC. Ceci est valable pour la compilation de programmes C ou C++. # Appel à contribution pour la traduction française de GCC Malgré le statut de compilateur par défaut des plates-formes libres de GCC, sa localisation n’a pas reçu toute l’attention qu’elle méritait depuis la version 3.4.3 (en 2008). Certainement parce qu’entre temps le nombre de chaînes a traduire a considérablement augmenté, passant de 4 700 à plus de 11 000. L’équipe française du [Translation Project](http://translationproject.org/team/fr.html) a récemment recommencé à travailler sur la [localisation de GCC](http://translationproject.org/domain/gcc.html). Mais vu l’ampleur du travail, toute contribution sera la bienvenue. Alors si vous appréciez un environnement parlant la langue de Molière n'hésitez pas à proposer votre aide sur la [liste de diffusion de Traduc.org](http://listes.traduc.org/mailman/listinfo/traduc). # Articles de Nick Clifton 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](http://nickclifton.livejournal.com). Ce développeur GCC propose presque chaque mois une synthèse des nouveautés. Lire rétrospectivement les articles concernant GCC 5.1 permet de mieux mesurer les avancées de cette version : - [_May 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/16188.html) - [_June 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/16414.html) - [_July 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/16681.html) - [_August 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/17060.html) - [_September 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/17282.html) - [_October 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/17556.html) - [_November 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/17770.html) - [_December 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/17948.html) - [_January 2015 GNU Toolchain Update_](http://nickclifton.livejournal.com/18217.html) - [_February 2015 GNU Toolchain Update_](http://nickclifton.livejournal.com/18447.html) - [_March 2015 GNU Toolchain Update_](http://nickclifton.livejournal.com/18769.html) - [_April 2015 GNU Toolchain Update_](http://nickclifton.livejournal.com/19126.html)