Sortie de GCC 8.1

Posté par  (site web personnel) . Édité par ZeroHeure, Davy Defaud, gusterhack, RyDroid, palm123, jcr83, _seb_ et Bruno Michel. Modéré par bubar🦥. Licence CC By‑SA.
68
18
mai
2018
GNU

La sortie de la nouvelle version majeure du compilateur GCC du projet GNU a été annoncée le 2 mai 2018. É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 sources écrits en C, C++, Objective-C, Fortran, Go et Ada. De plus, il fonctionne sur une multitude d’architectures.

La suite de la dépêche vous propose une revue de certaines améliorations et nouvelles fonctionnalités de cette nouvelle version.

Sommaire

Général

Nouveaux diagnostics

GCC 8.1 propose de nombreuses améliorations dans les diagnostics qui sont émis en cas de problème à la compilation. L’emplacement des erreurs de syntaxe est mieux indiqué et dans la plupart des cas GCC suggérera même ce qu’il faut insérer pour corriger l’erreur. Les en‐têtes (#include) manquants sont également indiqués par des messages plus explicites et des suggestions sont faites pour corriger la plupart des cas. Le développeur David Malcolm a écrit un excellent article qui détaille toutes ces améliorations des diagnostics de GCC 8.1.

Sécurité

La nouvelle option -fstack-clash-protection génère automatiquement du code pour empêcher les attaques de type stack clash, de façon à allouer une seule page de la pile à la fois et à y accéder immédiatement après l’allocation.

Les futurs processeurs Intel seront dotés d’une nouvelle technologie de sécurité nommée Control‐flow Enforcement Technology (CET). En gros, cela consiste à stopper les attaques de type Return‐oriented Programming en ayant une pile fantôme (shadow stack) qui va gérer les adresses de retour et générer une erreur en cas de problème. La gestion de CET est déjà présente dans GCC 8.1 via les options -mcet, -mibt, -mshstk et -fcf-protection.

PGO

L’infrastructure PGO (Profile Guided Optimization) a été largement améliorée dans cette version de GCC. PGO consiste à compiler une première fois le code avec l’option -fprofile-generate afin de l’instrumenter. On fait ensuite tourner le code en conditions réelles pour mesurer les performances et générer un profil précis de l’application. Puis, on réalise une seconde passe de compilation, cette fois‐ci avec l’option -fprofile-use, pour générer un code optimisé.
Dans GCC 8.1, les profils générés sont plus précis et plus fiables. L’option -freorder-blocks-and-partition qui sépare les fonctions dans des régions dites hot et cold est maintenant activée dès le niveau de compilation -O2. Cela permet à GCC d’optimiser plus agressivement les portions de code qui sont les plus sensibles aux performances.

Divers

Deux nouvelles passes optimisant la transformation des boucles dans le code (loop nest optimization) ont été ajoutées dans cette version de GCC. On trouve donc -floop-unroll-and-jam qui se charge du déroulage et de la fusion de boucles et -floop-interchange qui s’occupe d’améliorer la localisation spatiale des données. Ces deux passes sont activées par défaut à partir du niveau d’optimisation -O3.

Une nouvelle directive pragma GCC unroll a été implémentée pour les langages de la famille C, ainsi que pour Fortran et Ada. Cela offre à l’utilisateur un contrôle plus fin des optimisations de déroulage de boucles.

Les fonctionnalités d’optimisation inter‐procédurales sont revues avec une amélioration de la précision des métriques qui estiment la pertinence de l’« inlining » et du « cloning ».

La fonction LTO (Link‐time optimization) préserve mieux les informations de débogage dans les exécutables ELF. Cela permet, par exemple, à la fonction pretty-printers de la bibliothèque C++ libstdc++ de fonctionner même dans le cas d’un exécutable optimisé via LTO.

Langages de programmation

Fortran

La version principale de libfortran a été changée pour la version 5.
GCC 8.1 apporte la prise en charge des Parameterized derived types (une fonction présente dans la norme Fortran 2003) et améliore également la prise en charge de la norme Fortran 2008.

Golang

GCC 8.1 fournit une implémentation complète des paquets utilisateur de Go 1.10.1.
Le ramasse‐miettes est maintenant complètement concurrent et la fonctionnalité d’escape analysis est implémentée, ce qui réduit le nombre d’allocations dans le tas en allouant à la place les valeurs dans la pile.

C/C++

Plusieurs nouvelles options font leur apparition pour la compilation de code C et C++ afin d’avertir l’utilisateur sur d’éventuels problèmes (ces options sont bien évidemment incluses dans -Wall ou -Wextra). On retrouve donc :

  • -Wmultistatement-macros, qui avertit au sujet des macros qui ont des multiples déclarations utilisant collectivement plusieurs instructions comme if, else, while, switch, ou bien for ;
  • -Wstringop-truncation, qui avertit lors d’appels non sûrs à des fonctions de manipulation de chaînes de caractères ;
  • -Wif-not-aligned, qui s’occupe des utilisations invalides d’objets ayant l’attribut warn_if_not_aligned ;
  • -Wmissing-attributes, qui émet un warning quand il manque un ou plusieurs attributs dans une déclaration de fonction ;
  • -Wpacked-not-aligned, qui avertit quand un struct ou un union est déclaré avec l’attribut packed de façon incorrecte ;
  • -Wcast-function-type, qui avertit quand un pointeur de fonction est « casté » de façon incompatible ;
  • -Wsizeof-pointer-div, qui émet une alerte (warning) en cas de division de la taille d’un pointeur par la taille des éléments qu’il pointe ;
  • -Wcast-align=strict, qui alerte l’utilisateur quand un pointeur est « casté » et que cela implique une augmentation des contraintes d’alignement.

Cibles matérielles

x86-64

En ce qui concerne les processeurs Intel, cette nouvelle version de GCC apporte la prise en charge de la famille Cannon Lake (gravure en 10 nm) qui va être déployée au cours de l’année 2018. Il suffit d’utiliser l’option -march=cannonlake pour profiter des optimisations spécifiques (et cela active les extensions AVX512VBMI, AVX512IFMA et SHA).

Le successeur de Cannon Lake, qui se nomme Ice Lake et qui sortira normalement en 2019, est également présent dans cette version de GCC. En passant l’option -march=icelake on active automatiquement les extensions AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID et AVX512VPOPCNTDQ.

ARM et AArch64

La prise en charge de la version 64 bits de l’architecture ARM a bien évolué dans GCC 8.1.
C’est tout d’abord la variante Armv8.4-A qui fait son entrée (option -march=armv8.4-a) et qui apporte un EL2 sécurisé, l’accélération matérielle des algorithmes de hachage SHA2-512, SHA-3, SM3, et SM4 ainsi que l’amélioration des fonctions de virtualisation et de partitionnement mémoire (Memory Partitioning and Monitoring, soit MPAM).

On retrouve également dans cette version de GCC la prise en charge des processeurs Cortex-A75 et Cortex-A55, ainsi que la variante DynamIQ big.LITTLE, qui associe ces deux processeurs.

Les options de prise en charge d’architecture de type -march et -mcpu acceptent maintenant des extensions optionnelles, comme par exemple la prise en charge du calcul en virgule flottante ou les extensions vectorielles. Cela apporte beaucoup de flexibilité puisqu’il suffira, par exemple, de spécifier -mcpu=cortex-a53+nofp pour générer du code adapté au processeur Cortex-A53 mais sans gestion du calcul sur les flottants. Voir la documentation à ce sujet.

L’extension vectorielle Scalable Vector Extension (SVE) est maintenant prise en charge en tant qu’option à partir de la variante ARMv8.2-A (et supérieur).
À la différence de l’AVX d’Intel, cette extension SVE ne nécessite plus de modifier le code quand la largeur des registres vectoriels augmente d’une génération de processeur à l’autre (d’où le Scalable dans le nom). Avec un code source tirant parti du modèle de programmation vector‐length agnostic il suffira d’utiliser l’option -march=armv8.2-a+sveet GCC pourra générer du code vectorisé qui sera automatiquement adapté à l’architecture sous‐jacente de 128 bits jusqu’à 2 048 bits.

Aller plus loin

  • # Écrit à l'origine par ...

    Posté par  . Évalué à 10.

    Je n'ai aucun problème à remercier RMS de son travail sur GCC mais tout de même ne mentionner que lui alors que cela fait 21 années qu'il n'a pas écrit une ligne de code pour ce compilateur …

    On peut trouver les contributeurs à GCC ici RMS reste malgré tout 12ieme en terme de nombre de commit (métrique que je ne considère pas comme étant absolue),
    mais 21 ans en info c'est long, très long. Aussi je pense que le GCC d'aujourd'hui ne doit plus avoir grand chose à voir avec le GCC d'il y a 21 ans …
    Je pense que tant qu'à parler des développeurs de ce soft, il serait bien de parler de Jeff Law qui bosse dessus depuis 26 ans ou Jason Merrill qui bosse dessus depuis 20 ans …

    Personnellement, je n'ai pas le niveau et la connaissance de leurs développements, mais je pense que c'est remarquable de rester aussi si longtemps et de manière très active dans un projet aussi complexe.

    • [^] # Re: Écrit à l'origine par ...

      Posté par  . Évalué à 4.

      mais tout de même ne mentionner que lui

      C'est le seul créateur de Gcc, on ne peut pas lui enlever cela. D'ailleurs, il est bien écrit "Écrit à l’origine par Richard Stallman" . Par ailleurs, il est vrai que mentionner les noms de ceux qui ont fait évoluer gcc n'aurait pas été du luxe…

      • [^] # Re: Écrit à l'origine par ...

        Posté par  . Évalué à 10.

        Oui, sauf que gcc a été forke dans les années 90 par des gens saoules par la gouvernance de stallman, et ensuite réintègré comme gcc officiel 2 ans plus tard. Ou encore, que des membres du steering committee de gcc on declare en substance que si rms était présent à une réunion, c’etait plus productif de ne pas discuter de problèmes techniques, et de reporter à la prochaine réunion ou stallman ne serait pas là, plutôt que de risquer qu’il comprenne de travers, se braque, et tue dans l’oeuf toute tentative d’evolution.

        Donc en gros, oui, rms a plus rien à voir avec gcc depuis plus de 20 ans.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # Compilation de firefox avec gcc 8

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

    A Mozilla, on a compile le trunk de Firefox avec gcc 8 depuis un moment avec -Werror
    On a créé ce meta bug pour lister tous les bugs trouvés ainsi:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1409283

    Le plus courant est -Wclass-memaccess (pas mentionné dans cet article?)

    On a ignoré -Wmultistatement-macros: pénible pour certaines de nos utilisations.

    -Wformat-truncation a été amélioré, on a pu corriger quelques problèmes qui pouvaient (rarement) causé des problèmes.

    Et, surtout, Firefox étant un bon test case, on a pu déposé des bugs upstream comme https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82728 (régression avec -Wunused-but-set-variable)

    Bref, on recommande de faire pareil pour les logiciels importants… C'est bénéfique à la fois pour le compilateur et pour le projet (des vrais bugs sont trouvés ainsi).

    • [^] # Re: Compilation de firefox avec gcc 8

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

      Bref, on recommande de faire pareil pour les logiciels importants… C'est bénéfique à la fois pour le compilateur et pour le projet (des vrais bugs sont trouvés ainsi).

      C'est d'ailleurs globalement le cas du noyau et de la glibc qui ont forcément un lien particulier avec GCC et ces projets tirent partis des uns des autres pour progresser ensemble.

Suivre le flux des commentaires

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