Sortie de LLVM, Clang, lld, lldb 8.0.0

Posté par  (site web personnel) . Édité par Ontologia, Benoît Sibaud, Sylvestre Ledru, bubar🦥, Davy Defaud, palm123 et Bruno Michel. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
35
21
mar.
2019
C et C++

Après cinq versions candidates, l’étiquette finale a été apposée sur la branche 8.0.0 de la famille LLVM.

Cette dépêche reprend les points importants des notes de sortie associées. C’est une sélection totalement biaisée, libre à vous de lire les journaux des modifications respectifs pour avoir tous les détails !

LLVM

[Notes de version]

  • possibilité (sous x86) de fournir un profil d’accès mémoire afin de limiter le nombre de défauts de cache [RFC] ;
  • le back‐end Webassembly gagne le statut stable !
  • les personnes développant des extensions LLVM doivent maintenant utiliser add_llvm_library au lieu de add_llvm_loadable_module pour enregistrer leurs extensions.

Clang

[Notes de version]

  • possibilité de fournir un fichier de renommage pour utiliser les informations de profilage d’une version A d’un binaire pour recompiler une version B [doc] ;
  • possibilité de forcer la valeur des variables déclarées sur la pile ou en mises en registre, au lieu de les laisser non initialisées, en utilisant -ftrivial-auto-var-init=pattern ;
  • quelques warnings de plus :
    • -Wextra-semi-stmt pour détecter les points virgules inutiles, mais en ignorant certains cas liés à l’expansion de macros,
    • -Wempty-init-stmt détecte les initialisations vides dans le contexte de conditions/boucles (c’est du C++17, [spec]) ;
  • ajout du builtin __builtin_rotateleft32 ;
  • introduction de -mspeculative-load-hardening pour se prémunir de la famille de failles dite Spectre [rtd] ;
  • OpenMP 5 mieux géré, et pas mal d’améliorations du côté d’OpenCL ;
  • l’undefined behavior sanitizer, déclenché par -fsanitize=undefined, a gagné plusieurs extensions, dont une qui vérifie les contraintes d’alignement ;
  • clang-format voit sa gestion des reformatages de macros améliorée.

Extra Clang Tools

[Notes de version]

clangd

clangd est un démon qui fournit un service de type complétion, etc., à ces clients.

  • meilleure intégration avec le Language Server Protocol ;
  • plusieurs optimisations (taille et vitesse) pour la gestion des grosses bases de code.

clang-tidy

clang-tidy est un outil de vérification de code.

  • un bon paquet de tests pour l’utilisation de la bibliothèque abseil ;
  • un autre paquet de tests pour la modernisation de code (p. ex. : remplacement de tableaux à taille fixe par des std::array) ;
  • quelques tests autour des CppCoreGuidelines.

lld

[Notes de version]

  • choix de l’adresse de chargement des binaires comme un multiple d’une superpage, pour améliorer la vitesse de chargement dans les cas où le système cible prend en charge les *superpage*s — si comme moi tu ne sais pas ce qu’est une super‐page, clic clic ;
  • autre choix assez amusant : la section .note qui contient de précieuses informations (comme le build-id) est maintenant placée en début de fichier pour être présente dans les core files, même s’ils sont tronqués ;
  • des améliorations pour le format COFF et pour l’environnement MinGW, où l’on voit que Windows n’est pas une plate‐forme laissée de côté par LLD.

lldb

  • coloration syntaxique (pour C) et complétion de code.

Notes de fin

Cette version de LLVM est la dernière compilable avec GCC 4.8, les versions minimales requises augmentent, pour les raisons évoquées dans ce fil de discussion.

Et c’est aussi probablement la dernière version sous Subversion, le choix a été fait de passer à un dépôt unique (a.k.a. monorepo) sous Git. Pas mal de doc à ce sujet ici, là ou encore dans ce coin.

Aller plus loin

  • # Flang

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

    Bonjour,
    si j'ai bien compris LLVM est une infrastructure pour construire des compilateurs et Clang le compilateur C correspondant. En ce moment, je commence à m'intéresser au compilateur Fortran Flang qui utilise LLVM (même si je n'ai pas réussi à l'installer pour l'instant avec le gestionnaire de paquets Spack dont ils parlent sur leur site).

    • Quels sont les rapports entre Flang et LLVM: est-ce qu'il fait partie du projet LLVM ou est-ce un projet à part ?
    • Quelqu'un a-t-il déjà utilisé Flang ? Qu'en pensez-vous ?

    J'utilise depuis des années gfortran qui fait partie de GCC et j'en suis très content. Mais c'est toujours intéressant de compiler un code sur plusieurs compilateurs, ça permet parfois de détecter des anomalies.

    • [^] # Re: Flang

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

      C'est dans Debian Buster (testing pour le moment):

      $ apt install flang
      Ca n'est pas dans le projet LLVM (pour le moment?)

      • [^] # Re: Flang

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

        Ca n'est pas dans le projet LLVM (pour le moment?)

        À ce sujet, la lecture de ce thread est intéressante.

      • [^] # Re: Flang

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

        Merci beaucoup pour l'info,
        effectivement, j'ai une machine virtuelle avec une Debian Sid et je vois un paquet :

        flang-7/unstable 20181226-2 amd64
        Fortran compiler front-end for LLVM

        Je testerai la semaine prochaine.

        • [^] # Re: Flang

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

          Je viens d'installer le paquet flang-7 sur une Debian Sid. Ca marche bien sur les petits programmes que j'ai essayés. Par contre avec mon projet gtk-fortran, il compile (longuement) quelques fichiers puis affiche des erreurs :

          F90-S-0087-Non-constant expression where constant expression required (/home/osboxes/gtk-fortran/src/gtkenums-auto.f90: 355)
          ...
          C'est un fichier qui contient des énumérateurs Fortran dont la valeur est pour quelques-uns définie par une expression:

          enum, bind(c) !GModuleFlags
          enumerator :: G_MODULE_BIND_LAZY = ISHFTC(1, 0)
          enumerator :: G_MODULE_BIND_LOCAL = ISHFTC(1, 1)
          enumerator :: G_MODULE_BIND_MASK = INT(z'03')
          end enum
          D'après la norme Fortran (>=2003), on peut utiliser des scalar-int-constant-expr pour définir les énumérateurs. Et une telle expression est définie ainsi :

          A constant expression is an expression with limitations that make it suitable for use as initializer, or named constant. It is an expression in which each operation is intrinsic…

          Les fonctions ISHFTC() et INT() sont pourtant des fonctions intrinsèques du langage. Avec gfortran, ça passe sans problème. Avec ifort 2015 également.

          J'imagine qu'il me faudra attendre un peu que le nouveau compilateur f18 soit opérationnel et disponible sous forme de paquet.

  • # Speculative Load Hardening

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

    Petite précision : le SLH ne permet de se prémunir uniquement de Spectre v1, et encore, pas totalement, la couverture des branchements conditionnels n'est pas complète. C'est cependant mieux que rien.

    Une option non documentée de llc permet en outre d'insérer automatiquement l'instruction LFENCE, préconisée par Intel pour contrer Spectre v1, et ce sur tous les branchement conditionnels, pour le coup. L'impact sur les performances reste néanmoins très élevé pour cette dernière solution, mais c'est la seule connue actuellement offrant des garanties de complétude.

    Mes messages engagent qui je veux.

    • [^] # Re: Speculative Load Hardening

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 22 mars 2019 à 11:14.

      N'est-il pas possible de compiler uniquement un fichier sensible avec l'option LFENCE ? Faire un seul fichier C qui manipule des clefs ou token crypto, et compiler uniquement celui-là avec l'option pour éviter les pénalités d’exécution.

      Ou alors, est-il impossible de faire un link entre 2 objets ayant des options de compilations différentes ?

      "La première sécurité est la liberté"

      • [^] # Re: Speculative Load Hardening

        Posté par  . Évalué à 2.

        N'est-il pas possible de compiler uniquement un fichier sensible avec l'option LFENCE ? Faire un seul fichier C qui manipule des clefs ou token crypto, et compiler uniquement celui-là avec l'option pour éviter les pénalités d’exécution.

        Spectre permet d’accéder à n'importe quelle zone mémoire allouée à un processus. Du coup, ça ne servirait à rien de compiler seulement une partie du source avec cette option.

  • # typo

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 22 mars 2019 à 07:25.

    Merci pour cette contribution

    Je note des petites erreurs de typo
    - un profile , il y a un e de trop, angliscisme :)
    - en ignorants , un s de trop
    - de faille dite , un s manquant et circonflexe (potentiellement un s aussi selon si on parle de la famille ou des failles)

    Ce message peut s'auto détruire une fois corrigé, merci :)

Suivre le flux des commentaires

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