URL: https://linuxfr.org/news/sortie-de-la-version-4-9-du-compilateur-gcc Title: Sortie de la version 4.9 du compilateur GCC Authors: patrick_g Davy Defaud, BAud, Sébastien Koechlin, barmic, khivapia, Florent Zara, palm123, Storm, Xavier Teyssier, Nÿco et Sylvestre Ledru Date: 2014年01月29日T17:41:17+01:00 License: CC By-SA Tags: fortran, firefox, lwn, gcc, richard_stallman et objective-c Score: 64 La nouvelle version majeure du [compilateur GCC](http://gcc.gnu.org/) du projet GNU vient de sortir. É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). ![logo GCC](http://gcc.gnu.org/img/gccegg-65.png) 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.9 de GCC. ---- [L’annonce de la sortie par Jakub Jelinek](http://gcc.gnu.org/ml/gcc/2014-04/msg00195.html) [La liste des nouveautés ](http://gcc.gnu.org/gcc-4.9/changes.html) [Le site du projet GCC](http://gcc.gnu.org/) [La dépêche LinuxFr.org sur GCC 4.8](http://linuxfr.org/news/la-version-4-8-du-compilateur-gcc-est-disponible) ---- # Optimisations générales ##Ubsan `UndefinedBehaviorSanitizer` est un projet initialement développé pour LLVM et qui fait son apparition dans GCC. Il rejoint ainsi `ThreadSanitizer` et `AddressSanitizer` qui sont entrés dans GCC 4.8. Contrairement à [[valgrind]] qui lance le programme dans une machine virtuelle, il s’agit comme pour tous les _Sanitizers_ d’instrumenter le code binaire généré. `UndefinedBehaviorSanitizer` détecte les erreurs qui donnent lieu à un comportement indéfini à l’exécution. Il s’agit, par exemple, des divisions par zéro, des erreurs de _cast_ de type non aligné, de valeurs en dehors des bornes représentables par le type (énumérations ou flottants). Cette option s'active avec `-fsanitize=undefined` et elle est disponible pour les langages C et C++. ##Protection de la pile Les problèmes de débordement de pile sont un problème récurrent dans les programmes, en particulier avec le langage _C_ qui alloue dans le même espace mémoire les variables locales à une fonction, la sauvegarde des registres et la [pile d’exécution](http://fr.wikipedia.org/wiki/Pile_d%27ex%C3%A9cution) contenant toutes les adresses de retour. Une personne mal intentionnée (ou un chercheur en sécurité) peut parfois fournir plus de données que le programme n’est prévu pour en traiter, et cela entraîne un écrasement des autres données. En visant soigneusement, on s’arrange alors pour écraser l’adresse de retour avec une valeur soigneusement calculée pour exécuter des commandes non prévues. Le processeur, à la fin de la fonction, pensant revenir à la fonction appelante, va exécuter du code écrit par l’attaquant, qui n’a rien à voir avec le programme d’origine. L’idée de base pour se protéger de ce genre de chose est de déposer une valeur secrète juste avant l’adresse de retour, cette valeur est appelée « [canari](http://fr.wikipedia.org/wiki/Technique_du_canari) » à l’image des oiseaux utilisés par les mineurs pour détecter les nappes de gaz. Lorsque la fonction se termine, cette valeur est contrôlée. S’il y a eu débordement, la valeur du « canari » est écrasée, elle ne correspond plus et le programme est arrêté avant d’utiliser l’adresse de retour corrompue. GCC dispose déjà de deux fonctions permettant de mettre un tel mécanisme en place. L’option `-fstack-protector-all`, comme son suffixe l’indique, provoque l’ajout d’un canari pour tous les appels de fonction. Cet ajout est coûteux, car il y a plus d’instructions à exécuter, le code est plus long et va diminuer l’efficacité des différents caches. L’option `-fstack-protector` provoque l’ajout d’un canari sur toutes les fonctions qui contiennent une variable locale de type chaîne de caractères prévue pour 8 octets ou plus (valeur paramétrable avec l’option `--param=ssp-buffer-size=n`). Cette option est nettement moins coûteuse, mais laisse pas mal de trous. Les ingénieurs de Google ont donc développé une troisième alternative appelée `-fstack-protector-strong` pour améliorer la couverture des canaris sans avoir à l’ajouter à toutes les fonctions d’un programme. Elle est déjà utilisée avec succès dans _Chrome OS_ depuis au moins 10 mois. Par rapport à `-fstack-protector`, cette option protège également plusieurs autres situations à risque : * toutes les fonctions qui utilisent des variables locales contenant des tableaux (En _C_, tous les tableaux sont susceptibles de déborder par rapport à la taille allouée, les chaînes de caractères n’en sont qu’un cas particulier), y compris si le tableau est dans une structure ou une union ; * toutes les fonctions qui utilisent un pointeur vers une autre variable (l’adresse d’une autre variable) ; * et toutes les fonctions qui stockent des variables dans les registres. La version 3.14 du noyau Linux a été également modifiée pour permettre de le compiler avec les différentes options (il n’y a pas d’option pour `-fstack-protector-all`) : * `CONFIG_CC_STACKPROTECTOR_NONE` n’utilise pas de canaris ; * `CONFIG_CC_STACKPROTECTOR_REGULAR` (anciennement `CONFIG_CC_STACKPROTECTOR`) pour `-fstack-protector` ; * `CONFIG_CC_STACKPROTECTOR_STRONG` pour `-fstack-protector-strong`. Ingo Molnar a mesuré quelques valeurs par rapport à l’usage de ces options (ces valeurs ne sont pas absolues et dépendent bien évidemment de la configuration générale du noyau) : * `-fstack-protector` augmente la taille du noyau de 0,33 % et protège 2,81 % des fonctions ; * `-fstack-protector-strong` augmente la taille du noyau de 2,4 %, mais protège 20,5 % des fonctions. Bien que cette méthode ne soit pas parfaite, elle bloque un nombre significatif de problèmes de sécurité dans les applications. Comme toutes ces méthodes, elle a le double désavantage de faire payer à tous les utilisateurs les éventuels bogues de sécurité des applications et de ne pas inciter à la correction de ces problèmes. On peut s’attendre à ce que dans le futur, un certain nombre de distributions soient compilées avec cette option. Pour aller plus loin : - [l’article de Kees Cook](http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/) ; - [l’explication de LWN](https://lwn.net/Articles/584225/). ##Améliorations LTO La technique LTO (pour _**L**ink **T**ime **O**ptimization_) qui a été [introduite dans GCC 4.5](https://linuxfr.org/news/sortie-de-gcc-45#lto) reçoit encore une fois son lot d’améliorations incrémentales. Cette fonction LTO permet des passes d’optimisations supplémentaires lors de l’édition des liens, au prix d’un temps de compilation et d’une empreinte mémoire largement augmentés. La version 4.9 de GCC vise à réduire ces coûts afin de permettre une utilisation plus aisée par les distributions. On note en particulier une réécriture de l’algorithme de « _type merging_ », un travail sur les méthodes virtuelles afin de les éliminer le plus tôt possible, un chargement du corps des fonctions à la demande et un déchargement le plus tôt possible. Tout ces correctifs (et les nombreux autres non cités) constituent une importante amélioration globale de LTO et suppriment des goulets d’étranglements qui existaient dans les versions précédentes de GCC. Selon les notes de version, l’occupation mémoire d’une compilation LTO de Firefox (avec les symboles de débogage) passe ainsi de 15 Gio à seulement 3,5 Gio. Le temps passé à faire l’édition des liens dégringole, quant à lui, de 1 700 secondes à 350 secondes. Point important à noter, plusieurs correctifs ont été proposés à Linus afin d’intégrer la possibilité de compiler le noyau en mode LTO. Ces correctifs sont écrits par Andi Kleen et Michal Marek et [ont été proposées pour le futur noyau 3.15](http://lkml.iu.edu/hypermail/linux/kernel/1404.0/03450.html). Linus a jugé que ces correctifs étaient encore trop expérimentaux et a demandé des tests prouvant qu’une compilation LTO du noyau apportait vraiment des bénéfices :> _So I think I’ll let this wait a bit longer, unless people start talking about the upsides._> _How much smaller is the end result? How much faster is it? How much more beautiful is it? Does it make new cool things possible? Are those cool things really close on the horizon and really want this merged even though it’s not really quite ready yet?_> _So please: convince me._ Après divers échanges sur la LKML il s’avère que, pour l’instant, la fonction LTO de GCC n’apporte que peu de bénéfices en termes de performances sur un projet déjà extrêmement optimisé comme l’est le noyau. En revanche, on observe une réduction de la taille finale du noyau, ce qui intéresse les gens travaillant dans l’embarqué. Andi Kleen ajoute également que les bancs d’essai utilisés sont peu sensibles aux performances du compilateur et qu’on sous‐estime généralement le gain apporté par LTO. # Langages ##ISO C11 La prise en charge de la [norme C11](http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29) s’améliore encore dans cette version 4.9 de GCC. On note en particulier l’arrivée des types `_Atomic`, `_Generic` ainsi que de `_Thread_local`. Cette norme C11 est maintenant considérée comme aussi bien prise en charge que l’ancienne C99. ##C++1y On retrouve dans cette nouvelle mouture de GCC plusieurs nouveautés concernant la prise en charge de la future version de C++ (connue sous le nom de C++14). Le récapitulatif est disponible sur [_cette page_](http://gcc.gnu.org/projects/cxx1y.html), mais on peut citer les _polymorphic lambdas_ ([N3649](http://isocpp.org/files/papers/N3649.html)) ou encore la déduction automatique du type de retour d’une fonction ([N3638](http://isocpp.org/files/papers/N3638.html)). Plus anecdotique, on peut maintenant séparer de longs nombres par un guillemet droit simple afin d’améliorer la lisibilité. On aura ainsi : ```C int j = 1'048'576'752'870; ``` au lieu de : ```c int j = 1048576752870; ``` ##OpenMP GCC 4.9 apporte la prise en charge de la version 4.0 de l’interface de programmation OpenMP. [OpenMP 4.0](http://openmp.org/wp/2013/07/openmp-40/) est sorti en fin d’année 2013 avec beaucoup de nouveautés, notamment en termes de prise en charge des accélérateurs ou des directives SIMD. La branche _GOMP 4.0_ de GCC, qui suivait l’évolution de la norme, a permis son inclusion rapide dans la branche principale de GCC. Une nouvelle option `-fopenmp-simd` permet d’activer la prise en charge des directives SIMD d’OpenMP sans avoir à suivre les autres directives. Il est également possible de régler plus finement le modèle utilisé pour évaluer le coût de vectorisation des boucles de code. Il suffit de passer l’option `-fsimd-cost-model=` avec l’une des trois valeurs suivantes : `unlimited`, `dynamic` et `cheap`. Rappelons que la prise en charge d’OpenMP est une des grandes différences qui distinguent encore GCC et LLVM/Clang, puisque LLVM ne propose aucune prise en charge d’OpenMP dans sa branche principale. # Architectures ##AArch64 Avant la déferlante attendue des processeurs ARM 64 bits, on note que GCC 4.9 améliore encore sa couverture du jeu d’instructions ARMv8, avec la prise en charge des [fonctions intrinsèques](http://fr.wikipedia.org/wiki/Fonction_intrins%C3%A8que) `crypto` et `CRC`, mais aussi l’amélioration des performances des intrinsèques de vectorisation SIMD. La prise en charge de l’architecture AArch64 profite également de l’activation de la passe d’optimisation REE (_Redundant Extension Elimination_) ainsi que de du LRA (_local register allocator_). Le réglage fin de la génération du code émis par GCC est amélioré pour les cœurs de processeur Cortex-A53 et Cortex-A57. Il est également possible d’indiquer au compilateur que l’on vise une architecture de type _big.LITTLE_ via l’option `-mcpu=cortex-a57.cortex-a53`. ##POWER8 Le titanesque et surpuissant [POWER8](http://en.wikipedia.org/wiki/POWER8) d’IBM est maintenant pris en charge par GCC 4.9, via l’option `-mcpu=power8`. GCC a également été modifié afin de prendre en charge le module HTM (_Hardware Transactional Memory_) de ces nouveaux processeurs POWER8. C’est dans la [bibliothèque _libitm_](http://gcc.gnu.org/wiki/TransactionalMemory) qu’a été ajouté un raccourci (_fast path_) qui profite à fond des circuits spécialisés présents dans le processeur. ##Extension AVX512 Les futurs processeurs Intel _Xeon Phi_ [_Knights Landing_](http://en.wikipedia.org/wiki/Knights_Landing_%28microarchitecture%29#Knights_Landing) et les Intel _Core_ de la génération _Skylake_ ont beau n’être prévus que pour 2015 ou 2016, cette version 4.9 de GCC prend déjà en charge l’extension [AVX-512](http://en.wikipedia.org/wiki/AVX512) qui sera incluse dans leurs cœurs de calcul. AVX-512 est une extension complexe puisqu’elle propose un cœur obligatoire (_AVX-512 Foundation_) et plusieurs options _Conflict Detection Instructions_, _Exponential and Reciprocal Instructions_, _Prefetch Instructions_) qui seront activées ou pas selon la gamme de processeur. GCC 4.9 prend en charge toutes ces extensions (le code assembleur, les intrinsèques, l’autovectorisation) qui s’activent via différentes options (par exemple, `-mavx512f` pour AVX-512 Foundation). # En bref * La colorisation automatique des diagnostics émis par le compilateur [est maintenant disponible](http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html#index-fdiagnostics-color-239). L’option `-fdiagnostics-color=auto` permet ainsi de visualiser plus facilement les alertes (_warnings_) ou les erreurs, ainsi que l’emplacement exact du problème. * GCC 4.9 prend maintenant en charge la version 1.2.1 du langage Go (il s’agit de la toute dernière version sortie le 3 mars 2014). * On trouve également dans GCC 4.9 la prise en charge de [Cilk Plus](https://en.wikipedia.org/wiki/Cilk_Plus), l’extension de _C_ et _C++_ créée par Intel afin de faciliter l’écriture de code parallèle. L’utilisation se fait via l’option `-fcilkplus` et suit la version 1.2 de l’[ABI](http://fr.wikipedia.org/wiki/Application_binary_interface) _Cilk Plus_. * La bibliothèque d’exécution (_runtime library_) pour le langage _C++_ se nomme _libstdc++_. Elle a reçu diverses améliorations dans cette nouvelle version de GCC. Outre les nombreux changements liés à la prise en charge du futur _C++14_ (par exemple, `std::exchange()`, `std::make_unique` ou encore `std::shared_lock`), l’ajout le plus notable est la prise en charge de `` qui fait partie des nouveautés introduites par _C++11_. * De nouvelles options font leur apparition afin d’optimiser le code pour des processeurs récents ou à venir. On trouve ainsi `-march=silvermont` pour le [nouveau cœur _Atom_](https://en.wikipedia.org/wiki/Silvermont) avec exécution dans le désordre, `-march=broadwell` pour la [déclinaison 14 nm de l’architecture _Haswell_](https://en.wikipedia.org/wiki/Broadwell_%28microarchitecture%29), ou encore `-march=bdver4` pour les futurs cœurs [_Excavator_](https://en.wikipedia.org/wiki/Excavator_%28microarchitecture%29) d’AMD. # 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 chaîne de compilation GNU. Lire rétrospectivement les articles concernant GCC 4.9 permet de mieux mesurer tout le travail et les ajouts qui sont incorporés dans cette version : - [_April 2013 GNU Toolchain Update_](http://nickclifton.livejournal.com/13264.html) ; - [_May 2013 GNU Toolchain Update_](http://nickclifton.livejournal.com/13551.html) ; - [_June 2013 GNU Toolchain Update_](http://nickclifton.livejournal.com/13602.html) ; - [_July 2013 GNU Toolchain Update_](http://nickclifton.livejournal.com/13891.html) ; - [_August 2013 GNU Toolchain Update_](http://nickclifton.livejournal.com/14247.html) ; - [_September 2013 GNU Toolchain Update_](http://nickclifton.livejournal.com/14424.html) ; - [_October 2013 GNU Toolchain Update_](http://nickclifton.livejournal.com/14813.html) ; - [_November 2013 GNU Toolchain Update_](http://nickclifton.livejournal.com/15001.html) ; - [_January 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/15132.html) ; - [_February 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/15412.html) ; - [_March 2014 GNU Toolchain Update_](http://nickclifton.livejournal.com/15809.html).

AltStyle によって変換されたページ (->オリジナル) /