Sortie de GCC 16

 (gcc.gnu.org)
1 points par GN⁺ 2 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp
  • La nouvelle version de la GNU Compiler Collection marque un tournant important en faisant passer le standard C++ par défaut à gnu++20 et en ne considérant plus l’implémentation de C++20 comme expérimentale
  • La prise en charge de la reflection, des contracts et des fonctionnalités constexpr de C++26, des fonctionnalités C++23, ainsi que des bibliothèques expérimentales C++23 et C++26 a été ajoutée, et les diagnostics d’erreurs de template et d’échec de contraintes de type trait sont désormais plus détaillés grâce à des messages hiérarchisés
  • OpenMP et OpenACC étendent l’allocation mémoire GPU, target memset et l’API device memcpy, tandis que les front ends Ada, Fortran, Modula-2 et Algol 68 reçoivent eux aussi de nouvelles fonctionnalités de langage et des compilateurs expérimentaux
  • x86-64 prend en charge AMD Zen6, Intel Wildcat Lake et Intel Nova Lake, et des fonctionnalités spécifiques aux cibles ainsi que des changements d’ABI ont aussi été ajoutés pour les GPU AMD, LoongArch, IBM z Systems, Solaris et Windows
  • La suppression du format de diagnostic JSON, le renforcement des diagnostics SARIF et HTML, les améliorations du static analyzer et l’ajout de 37 points d’entrée à libgdiagnostics élargissent fortement l’intégration avec les outils et l’infrastructure de diagnostic

Changements de compatibilité et améliorations communes

  • Sur Solaris, int8_t et autres deviennent signed char afin de respecter la norme C99 ; il s’agit d’un changement incompatible
  • Sur Solaris, l’option -pthread ne prédéfinit plus _REENTRANT
  • Le format json de -fdiagnostics-format= a été supprimé, et il faut utiliser SARIF pour les diagnostics lisibles par machine
  • La Link-Time Optimization gère mieux les instructions asm de niveau supérieur avec -flto-toplevel-asm-heuristics
  • La speculative devirtualization traite les appels de fonctions indirects généraux et prend en charge plus d’une cible spéculée
  • Le vectorizer identifie plus souplement le parallélisme intra-boucle des reductions, et prend en charge la vectorisation des boucles dont le nombre d’itérations est inconnu ainsi que des uncounted loops
    • Sont aussi pris en charge : le peeling d’alignement des vector length agnostic loops utilisant le masking, le mutual peeling for alignment, ainsi que la suppression du calcul d’induction vectorielle dans les boucles avec early break
  • GCC Command Options et l’index des options ont été corrigés pour inclure de nombreuses options auparavant absentes
  • La documentation sur les attributs spécifiques à GCC a été modernisée afin de mieux mettre en avant la syntaxe standard des attributes autorisée dans tous les dialectes C/C++ pris en charge par GCC
    • Les informations sur les attributes ont été réorganisées afin de réduire les répétitions, et un nouvel index des attributes a été ajouté
    • La documentation sur les fichiers spec de paramètres et d’options a été déplacée vers le manuel interne de GCC destiné aux développeurs GCC et aux utilisateurs ayant besoin d’une configuration GCC personnalisée

Principales évolutions par langage

  • OpenMP et OpenACC

    • La prise en charge de l’allocation mémoire OpenMP a été renforcée : le trait allocator pinned et ompx_gnu_pinned_mem_alloc utilisent l’API CUDA lorsqu’elle est disponible, ce qui améliore les performances d’accès à cette mémoire sur les GPU Nvidia
    • L’allocator d’extension GNU ompx_gnu_managed_mem_alloc et ompx_gnu_managed_mem_space allouent une mémoire accessible au device depuis l’hôte
      • l’accès par le device est possible même si la unified-shared memory n’est pas prise en charge, et sur les systèmes où toute la mémoire hôte est accessible au device, le comportement de migration de pages peut aussi différer de celui des autres mémoires
    • OpenMP 5.0 ajoute une prise en charge limitée de declare mapper en C/C++, et la clause uses_allocators inclut les changements de syntaxe d’OpenMP 5.2 ainsi que la prise en charge du point-virgule d’OpenMP 6.0
    • OpenMP 5.1 ajoute une prise en charge initiale du modificateur iterator pour la clause map et le construct target update en C/C++
    • OpenMP 5.2 prend en charge la directive begin declare variant en C/C++
    • OpenMP 6.0 ajoute les routines d’API omp_target_memset et omp_target_memset_async, et la clause d’hypothèses no_openmp_constructs peut aussi être utilisée
    • Les directives et clauses dépréciées dans OpenMP 5.0, 5.1 et 5.2 émettent par défaut un avertissement de dépréciation, désactivable avec -Wno-deprecated-openmp
      • un avertissement est également émis lors de l’utilisation d’une constante nommée dépréciée ou d’une routine d’API, désactivable avec -Wno-deprecated-declarations
    • OpenACC ajoute les routines d’API acc_memcpy_device et acc_memcpy_device_async pour C/C++/Fortran
    • La directive wait d’OpenACC 3.0 accepte une clause if, et les routines d’API Fortran acc_attach et acc_detach d’OpenACC 3.3 complètent leurs homologues C/C++ d’OpenACC 2.6
    • Avec OpenACC 3.4, l’utilisation de la constante nommée PARAMETER dans les clauses de données Fortran est autorisée par la spécification et par GCC, mais dans GCC cela n’affecte pas le comportement à la compilation ni à l’exécution

  • Ada, Fortran, Modula-2, Algol 68

    • Les extensions GNAT d’Ada ajoutent Constructor et Destructor, offrant un mécanisme de construction/finalisation sensiblement différent de l’Ada standard
    • Les aspects Implicit with, Structural Generic instantiation et Extended_Access ont été ajoutés à Ada
      • Extended_Access peut être spécifié dans une déclaration de type d’accès général pointant vers un sous-type de tableau non contraint, modifie la représentation du pointeur et facilite l’interopérabilité avec des langages étrangers pour la mémoire non allouée par Ada
    • Ada peut utiliser VAST pour le débogage du compilateur avec -gnatd_V ou -gnatd_W en mode verbeux, et l’analyse sémantique des Reduction Expressions d’Ada 2022, Ada.Containers.Bounded_Indefinite_Holders, l’implémentation des règles d’accessibilité et la prise en charge d’Android ont été améliorées
    • Fortran gère les coarrays utilisant le multithreading natif en mémoire partagée sur une machine à nœud unique, ainsi que la fonctionnalité TEAM de Fortran 2018
    • La prise en charge des Parameterized Derived Types de Fortran 2003 a été améliorée, et le traitement du paramètre LEN fonctionne, mais un futur changement de représentation reste nécessaire conformément à PR82649
    • Fortran 2018 prend en charge l’extension de l’instruction IMPORT, l’intrinsèque REDUCE et la nouvelle instruction GENERIC
    • Fortran 2023 prend en charge les ajouts de fonctions trigonométriques comme sinpi, la sous-routine intrinsèque split et c_f_pointer avec une borne inférieure optionnelle en argument
    • L’option -fexternal-blas64 appelle des routines BLAS externes avec des arguments entiers 64 bits dans MATMUL, et n’est valable que sur les systèmes 64 bits avec -ffrontend-optimize
    • Modula-2 fournit des suggestions orthographiques lors du traitement des listes d’import, des noms de modules et des symboles en portée imbriquée, et introduit une nouvelle implémentation des wide sets ainsi que le module de bibliothèque M2WIDESET
      • cette évolution des wide sets modifie l’ABI et peut provoquer des erreurs d’édition de liens avec des fichiers objet produits par des versions antérieures de GCC
    • La bibliothèque par défaut de Modula-2 ajoute le module de dictionnaire binaire BinDict, fournit les procédures Write et WriteLn dans plusieurs modules, et améliore l’accès aux modules de bibliothèques externes avec l’option -fm2-pathname-root=
    • GCC inclut ga68, un compilateur expérimental pour Algol 68, qui vise à implémenter le Revised Report et les errata approuvés par la sous-commission IFIP WG2.1 Algol 68 Support
      • certaines extensions GNU et un prélude POSIX sont aussi implémentés ; pour plus d’informations sur le langage, voir le site web Algol 68, et pour le front end, le wiki

C++ et libstdc++

  • La version du langage par défaut pour la compilation C++ passe de -std=gnu++17 à -std=gnu++20
    • Le code qui dépend d’anciens standards C++ doit ajouter l’option de build -std= ou être porté ; voir les notes de portage
    • La prise en charge des modules C++20 reste expérimentale et doit être activée avec -fmodules
  • De nombreuses fonctionnalités C++26 sont implémentées, notamment la reflection, les annotations pour la reflection, le base class subobject splicing, la reflection des paramètres de fonction, les contracts, les exceptions constexpr et l’héritage virtuel constexpr
    • P2996R13 Reflection s’active avec -std=c++26 -freflection
    • Une partie de P2686R4 est prise en charge partiellement ; les structured bindings peuvent être constexpr, mais les références à des variables automatiques constexpr ne sont pas encore autorisées
  • Les fonctionnalités C++23 P2036R3, P2590R2 et P2246R1 sont implémentées
  • Les messages d’erreur C++ ont désormais une structure hiérarchique pour les problèmes liés aux templates notamment, avec indentation et puces pour indiquer l’imbrication des messages
  • La prise en charge expérimentale des modules C++20 ajoute l’option --compile-std-module pour construire la header unit <bits/stdc++.h> ainsi que les modules std et std.compat avant la compilation du fichier source
    • Si la header unit <bits/stdc++.h> est construite, les #include des en-têtes de bibliothèque standard importables sont convertis de manière transparente en import de <bits/stdc++.h>
    • De nombreux bugs signalés ont été corrigés
  • Les diagnostics d’échec de contraintes pour les type traits de la bibliothèque standard indiquent plus en détail pourquoi is_constructible_v, is_invocable_v et d’autres valent false
  • Pour les cibles où libstdc++ prend en charge les entiers 128 bits, std::is_integral<__int128> et les traits similaires valent désormais toujours true
    • Auparavant, c’était true avec le dialecte GNU mais pas avec le dialecte strict
  • P0952R2: A new specification for std::generate_canonical est implémenté dans tous les modes concernés depuis C++11, ce qui affecte la sortie observable
    • Le comportement précédent peut être restauré en définissant _GLIBCXX_USE_OLD_GENERATE_CANONICAL
  • L’ABI de std::variant a été mise à jour pour rester cohérente avec les modes C++20 et ultérieurs, ce qui affecte l’agencement de certaines classes en mode C++17
    • Le comportement précédent peut être restauré en définissant _GLIBCXX_USE_VARIANT_CXX17_OLD_ABI, et l’impact concerne uniquement le mode C++17
  • L’exécution de std::regex a été réécrite pour utiliser une pile basée sur le tas au lieu de la pile système, afin d’éviter les stack overflows lors de la recherche sur de plus grandes chaînes
  • L’implémentation de C++20 n’est plus expérimentale, et std::chrono::current_zone() fonctionne sous Windows
  • Comme la prise en charge de C++20 avant GCC 16 était expérimentale, les programmes utilisant des composants C++20 doivent être considérés comme incompatibles avec les versions plus anciennes
    • Les changements d’ABI concernent notamment les fonctions d’attente/notification de <atomic>, le type semaphore de <semaphore>, la synchronisation de <syncstream>, les arguments de std::format et la représentation de std::formatter, std::partial_ordering de <compare>, ainsi que la représentation de certains adaptateurs de <ranges>
  • La prise en charge expérimentale de la bibliothèque C++23 inclut std::mdspan, ranges::starts_with, ranges::ends_with, ranges::shift_left, ranges::shift_right et std::allocator_traits::allocate_at_least
  • La prise en charge expérimentale de la bibliothèque C++26 inclut std::simd, std::inplace_vector, std::optional<T&>, std::copyable_function, std::function_ref, std::indirect, std::polymorphic, std::owner_equal pour les shared pointers, ainsi que l’en-tête <debugging>

Prise en charge des cibles et des systèmes d’exploitation

  • IA-32/x86-64

    • Les CPU basés sur AMD Zen6 sont pris en charge via -march=znver6, qui active AVX512_BMM, AVX_NE_CONVERT, AVX_IFMA, AVX_VNNI_INT8 et AVX512_FP16 en plus des extensions ISA activées pour Zen5
    • Quand la prise en charge d’AVX512 est activée et que le tuning est znver4, znver5 ou znver6, l’auto-vectorisation tente d’utiliser des masked vector epilogs afin de réduire la taille du code et d’améliorer les performances
    • Intel Wildcat Lake est pris en charge via -march=wildcatlake, et Intel Nova Lake via -march=novalake
      • -march=novalake active en plus APX_F, AVX10.1, AVX10.2 et PREFETCHI au-dessus des extensions ISA basées sur Panther Lake
    • À partir de GCC 16, l’activation de AMX-TRANSPOSE, USER_MSR, CLDEMOTE, KL, WIDEKL et PREFETCHI a été supprimée de plusieurs switches -march=
    • -mavx10.1-256, -mavx10.1-512 et -mevex512 ont été supprimés, et l’avertissement sur le changement de comportement de -mavx10.1 a également disparu
    • La prise en charge de AMX-TRANSPOSE a été supprimée dans GCC 16, et GCC n’accepte plus -mamx-transpose
    • La nouvelle option de configuration --enable-x86-64-mfentry active -mfentry, qui utilise __fentry__ au lieu de mcount pour le profiling x86-64, et elle est activée par défaut pour les cibles glibc
    • --enable-tls=DIALECT permet de contrôler le dialecte TLS par défaut ; la valeur par défaut est gnu, et les valeurs autorisées sont gnu et gnu2 pour TLS descriptor

  • AMD GPU, LoongArch, IBM z Systems

    • En offloading AMD GPU, l’overhead de lancement des régions cibles OpenMP et des régions de calcul OpenACC a fortement diminué
    • Une prise en charge expérimentale du périphérique AMD Instinct MI300 gfx942 a été ajoutée, ainsi que gfx950, compatible avec gfx9-4-generic dans la plupart des cas
    • L’ensemble multilib build par défaut pour les AMD GPU devient gfx908, gfx90a, gfx9-generic, gfx9-4-generic, gfx10-3-generic, gfx11-generic
      • Lorsqu’une architecture générique est présente, les multilib pour périphériques spécifiques ne sont plus construits par défaut
      • Les architectures génériques nécessitent ROCm 6.4.0 ou plus
      • Le nouvel ensemble multilib par défaut nécessite l’assembleur et l’éditeur de liens de LLVM 20 ou plus
      • Voir les notes d’installation AMD de GCC et les notes de configuration
    • LoongArch prend en charge les types entiers à précision exacte comme _BitInt (N) et unsigned _BitInt (N)
    • LoongArch prend en charge la Function Multi-Versioning via l’attribut target_clones, qui permet de créer des versions de fonctions selon les fonctionnalités CPU et de sélectionner automatiquement à l’exécution la version optimale
    • La prise en charge de l’architecture LoongArch32 a été ajoutée, avec l’ABI par défaut ilp32d ainsi que les ABI ilp32f et ilp32s
      • Elle couvre à la fois la version 32 bits standard LA32 et la version 32 bits réduite LA32R, permettant la génération de code cible 32 bits pour les applications embarquées
      • Cette fonctionnalité dépend de la prise en charge par Binutils et glibc
    • S/390, System z et IBM z Systems prennent en charge les types entiers à précision exacte ainsi que le type flottant _Float16
      • Les opérations sur _Float16 sont effectuées en logiciel ou avec des instructions float
    • Sur la famille S/390, un global stack protector a été ajouté via -mstack-protector-guard=global afin de prendre en charge le runtime patching du chargement de l’adresse canari du noyau Linux, et -mstack-protector-guard-record a aussi été ajouté
    • La prise en charge de -m31 sur la famille S/390 est désormais deprecated et sera supprimée dans une future release

  • Systèmes d’exploitation

    • Solaris facilite la génération du Solaris CTF, c’est-à-dire Compact C Type Format, avec l’option -gsctf
    • Windows prend en charge le TLS natif, c’est-à-dire Thread-Local Storage
      • Pour l’activer, il faut spécifier --enable-tls lors de la configuration ainsi que GNU binutils 2.44 ou plus

Diagnostic, plugins, analyse statique

  • GCC prend en charge la sortie de diagnostic au format HTML avec -fdiagnostics-add-output=experimental-html
  • La sortie SARIF suit le dump directory ; dans l’exemple de sortie build-dir/foo.o, GCC 16 écrit le SARIF dans build-dir/foo.c.sarif
    • GCC 15 l’écrivait dans foo.c.sarif dans le même exemple
  • La sortie SARIF capture le logical location nesting et, dans de nombreux cas, inclut une propriété description dans l’objet fix
  • La kinds property de threadFlowLocation dans SARIF reçoit de nouvelles valeurs throw, catch, unwind, setjmp, longjmp pour représenter des flux de contrôle non standard
  • Les diagnostics GCC peuvent associer des graphes orientés et peuvent aussi signaler des graphes orientés globaux
    • Les graphes sont ignorés par les text sinks, mais capturés par le sink SARIF, et experimental-html les rend en SVG via dot
    • En définissant cfgs=yes sur le sink de diagnostic SARIF ou HTML, la capture de la représentation intermédiaire de GCC est activée pour toutes les fonctions de tous les passes d’optimisation
  • Les diagnostics GCC peuvent faire référence à des logical locations à l’intérieur de fichiers XML et JSON
    • L’outil sarif-replay s’en sert pour fournir un pointeur JSON lors du signalement de problèmes dans des rapports SARIF en entrée
  • Si GCC_DIAGNOSTICS_LOG est défini dans l’environnement, le sous-système de diagnostic émet un journal texte vers stderr ou vers un fichier nommé
    • Cela sert à suivre des décisions internes, par exemple quand et pourquoi un diagnostic est rejeté
  • Si EXPERIMENTAL_SARIF_SOCKET est défini dans l’environnement, GCC tente de se connecter à ce socket au démarrage et envoie une notification JSON-RPC pour chaque diagnostic produit
  • Pour les auteurs de plugins, un framework publish/subscribe a été ajouté afin de transmettre des messages strongly-typed entre émetteurs et récepteurs loosely-coupled
    • Dans cette version, les topics auxquels un plugin peut s’abonner se limitent aux événements de début/fin des passes d’optimisation d’une fonction donnée et aux événements liés à l’analyseur statique
  • Un sink de diagnostic GCC peut avoir un objet extension doté d’un hook finalizer, que les plugins peuvent utiliser pour capturer des informations supplémentaires dans le fichier de sortie SARIF
  • Dans GCC 16, la machinery de diagnostic a été largement réorganisée, et cela ne devrait pas affecter les plugins qui n’utilisent que diagnostic-core.h
    • Les mainteneurs de plugins qui utilisent les diagnostics de manière plus avancée doivent consulter le guide de portage
  • L’analyseur statique gère un support initial du C++ Named Return Value Optimization et des exceptions, ce qui le rend utilisable sur des exemples C++ simples
    • En raison de problèmes de passage à l’échelle, il risque toutefois d’être difficile à utiliser sur du code C++ de production dans cette version
  • -fanalyzer suppose que, lorsque -fexceptions est activé, les appels à des fonctions externes sans attribut nothrow peuvent lever une exception
    • La nouvelle option -fanalyzer-assume-nothrow désactive cette hypothèse
    • Cela permet d’éviter une hausse des avertissements dans les projets qui utilisent -fexceptions dans du code C pour l’interopérabilité C++, mais où l’API C employée a peu de chances de lever des exceptions
  • Les structures de données de représentation du code utilisateur de -fanalyzer ont été réécrites pour être plus faciles à comprendre et à déboguer, et l’emplacement des diagnostics a été légèrement amélioré
    • En contrepartie, l’utilisation mémoire de l’analyseur augmente
  • Les structures de données de simulation du contenu mémoire de -fanalyzer ont été réimplémentées pour être plus rapides et plus faciles à maintenir
  • L’analyseur commence à utiliser la machinery value_range de GCC, ce qui élimine certains faux positifs

libgdiagnostics et problèmes corrigés

À lire aussi

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.