GCC 16 veröffentlicht

 (gcc.gnu.org)
1 Punkte von GN⁺ 3 시간 전 | Noch keine Kommentare. | Auf WhatsApp teilen
  • Die neue Version der GNU Compiler Collection markiert einen wichtigen Wendepunkt: Der Standard für C++ wurde standardmäßig auf gnu++20 umgestellt, und die C++20-Implementierung gilt nicht länger als experimental.
  • Unterstützung für Reflection, Contracts und constexpr-Funktionen aus C++26, für Funktionen aus C++23 sowie für experimentelle C++23- und C++26-Bibliotheken wurde hinzugefügt; außerdem sind Diagnosen für Template-Fehler und type trait constraint failures durch hierarchische Meldungen detaillierter geworden.
  • OpenMP und OpenACC wurden um GPU-Speicherallokation, target memset und die device memcpy API erweitert; auch die Frontends für Ada, Fortran, Modula-2 und Algol 68 erhalten neue Sprachfunktionen und experimentelle Compiler.
  • x86-64 unterstützt nun AMD Zen6, Intel Wildcat Lake und Intel Nova Lake; auch für AMD-GPU, LoongArch, IBM z Systems und Solaris/Windows kamen zielspezifische Funktionen und ABI-Änderungen hinzu.
  • Mit der Entfernung des JSON-Diagnoseformats, dem Ausbau von SARIF- und HTML-Diagnosen, Verbesserungen am static analyzer und 37 neuen Entry Points in libgdiagnostics wurde die Tool-Integration und Diagnose-Infrastruktur deutlich erweitert.

Kompatibilitätsänderungen und allgemeine Verbesserungen

  • Auf Solaris wurden int8_t und ähnliche Typen zur Einhaltung des C99-Standards zu signed char geändert; dies ist eine inkompatible Änderung.
  • Auf Solaris definiert die Option -pthread _REENTRANT nicht mehr vorab.
  • Das json-Format von -fdiagnostics-format= wurde entfernt; für maschinenlesbare Diagnosen soll SARIF verwendet werden.
  • Link-Time Optimization geht mit -flto-toplevel-asm-heuristics besser mit asm-Anweisungen auf oberster Ebene um.
  • Speculative Devirtualization verarbeitet nun allgemeine indirekte Funktionsaufrufe und unterstützt die Vorhersage von mehr als einem Ziel.
  • Der Vectorizer erkennt die Parallelität innerhalb von Reduction-Loops flexibler und unterstützt die Vektorisierung von Loops mit unbekannter Iterationszahl sowie uncounted loops.
    • Unterstützt werden außerdem Alignment-Peeling für vector-length-agnostic loops mit Masking, mutual peeling for alignment sowie das Entfernen der Vector-Induction-Berechnung in Loops mit frühem Abbruch.
  • GCC Command Options und der Option Index wurden korrigiert, um viele zuvor fehlende Optionen aufzunehmen.
  • Die Dokumentation zu GCC-specific attributes wurde modernisiert, um die standardisierte Attribute-Syntax stärker hervorzuheben, die in allen von GCC unterstützten C/C++-Dialekten zulässig ist.
    • Das Material zu Attributen wurde neu strukturiert, um Wiederholungen zu reduzieren, und ein neuer Attribute Index wurde hinzugefügt.
    • Die Dokumentation zu Parameter- und Option-Spec-Files wurde in das GCC internals manual verschoben, das sich an GCC-Entwickler und Nutzer mit Bedarf an individuellen GCC-Konfigurationen richtet.

Wichtige Änderungen nach Sprache

  • OpenMP und OpenACC

    • Die Unterstützung für OpenMP-Speicherallokation wurde erweitert: Der pinned-Trait-Allocator und ompx_gnu_pinned_mem_alloc verwenden, wenn verfügbar, die CUDA API und verbessern so die Leistungsfähigkeit beim Zugriff auf diesen Speicher auf Nvidia-GPUs
    • Die GNU-Erweiterungen ompx_gnu_managed_mem_alloc als Allocator und ompx_gnu_managed_mem_space allokieren vom Host aus device-zugänglichen Speicher
      • Der Zugriff durch das Device ist auch dann möglich, wenn unified-shared memory nicht unterstützt wird; auch auf Systemen, in denen sämtlicher Host-Speicher device-zugänglich ist, kann sich das Page-Migration-Verhalten von anderem Speicher unterscheiden
    • OpenMP 5.0 ergänzt eine eingeschränkte Unterstützung für declare mapper in C/C++, und die uses_allocators-Clause umfasst sowohl Syntaxänderungen aus OpenMP 5.2 als auch die Unterstützung von Semikolons aus OpenMP 6.0
    • OpenMP 5.1 ergänzt eine erste Unterstützung des iterator-Modifiers in der map-Clause und im target update-Konstrukt für C/C++
    • OpenMP 5.2 unterstützt die Directive begin declare variant in C/C++
    • OpenMP 6.0 fügt die API-Routinen omp_target_memset und omp_target_memset_async hinzu; außerdem kann die Assumptions-Clause no_openmp_constructs verwendet werden
    • In OpenMP 5.0, 5.1 und 5.2 als deprecated markierte Directives und Clauses erzeugen standardmäßig Deprecation-Warnungen; diese lassen sich mit -Wno-deprecated-openmp abschalten
      • Auch bei der Nutzung deprecated benannter Konstanten oder API-Routinen wird eine Warnung ausgegeben; diese lässt sich mit -Wno-deprecated-declarations abschalten
    • OpenACC ergänzt die API-Routinen acc_memcpy_device und acc_memcpy_device_async für C/C++/Fortran
    • Die wait-Directive aus OpenACC 3.0 akzeptiert eine if-Clause, und die Fortran-API-Routinen acc_attach und acc_detach aus OpenACC 3.3 ergänzen ihre Gegenstücke aus OpenACC 2.6 für C/C++
    • In OpenACC 3.4 ist die Verwendung der benannten Konstante PARAMETER in Fortran-Data-Clauses laut Spezifikation und in GCC erlaubt, hat in GCC aber keine Auswirkungen auf das Verhalten zur Compile-Zeit oder Laufzeit

  • Ada, Fortran, Modula-2, Algol 68

    • Die Ada-GNAT-Erweiterungen wurden um Constructor und Destructor ergänzt und bieten damit einen Konstruktions-/Finalisierungsmechanismus, der deutlich von Standard-Ada abweicht
    • Für Ada wurden die Aspekte Implicit with, Structural Generic instantiation und Extended_Access hinzugefügt
      • Extended_Access kann bei allgemeinen Access-Type-Deklarationen angegeben werden, die auf einen unconstrained Array-Subtype zeigen, verändert die Pointer-Repräsentation und erleichtert die Anbindung von Speicher, der nicht von Ada allokiert wurde, an Fremdsprachen
    • Ada kann VAST für das Compiler-Debugging mit -gnatd_V oder -gnatd_W im Verbose-Modus verwenden; außerdem wurden die semantische Analyse von Reduction Expressions in Ada 2022, Ada.Containers.Bounded_Indefinite_Holders, die Implementierung von Accessibility-Regeln und die Android-Unterstützung verbessert
    • Fortran unterstützt Coarrays, die auf Einzelknotenmaschinen natives Shared-Memory-Multithreading verwenden, sowie das TEAM-Feature aus Fortran 2018
    • Die Unterstützung für Parameterized Derived Types aus Fortran 2003 wurde verbessert; die Verarbeitung von LEN-Parametern funktioniert, erfordert wegen PR82649 aber künftig Änderungen an der Repräsentation
    • Fortran 2018 unterstützt Erweiterungen des IMPORT-Statements, die REDUCE-Intrinsic und das neue GENERIC-Statement
    • Fortran 2023 unterstützt zusätzliche trigonometrische Funktionen wie sinpi, die intrinsic subroutine split sowie c_f_pointer mit optionaler unterer Grenze als Argument
    • Die Option -fexternal-blas64 ruft bei MATMUL externe BLAS-Routinen mit 64-Bit-Integer-Argumenten auf und ist nur auf 64-Bit-Systemen sowie bei Verwendung von -ffrontend-optimize wirksam
    • Modula-2 gibt bei Import-Listen, Modulnamen und der Verarbeitung von Symbolen in verschachtelten Scopes Rechtschreibhinweise aus und führt eine neue Wide-Set-Implementierung sowie das Bibliotheksmodul M2WIDESET ein
      • Die Änderungen an Wide Sets verändern die ABI und können dadurch beim Linken Fehler mit Objektdateien aus früheren GCC-Versionen verursachen
    • Zur Standardbibliothek von Modula-2 kommt das binäre Wörterbuchmodul BinDict hinzu; mehrere Module erhalten die Prozeduren Write und WriteLn, und der Zugriff auf externe Bibliotheksmodule wurde mit der Option -fm2-pathname-root= verbessert
    • GCC enthält mit ga68 einen experimentellen Algol-68-Compiler, der die Umsetzung des Revised Report sowie der von der IFIP-WG2.1-Unterkommission Algol 68 Support genehmigten Errata zum Ziel hat
      • Außerdem werden einige GNU-Erweiterungen und eine POSIX-Prelude implementiert; Sprachinformationen finden sich auf der Algol-68-Website, Informationen zum Frontend im Wiki

C++ und libstdc++

  • Die Standard-Sprachversion für die C++-Kompilierung wurde von -std=gnu++17 auf -std=gnu++20 geändert
    • Code, der von älteren C++-Standards abhängt, muss entweder das Build-Flag -std= ergänzen oder portiert werden; siehe dazu die Porting-Hinweise
    • Die Unterstützung für C++20-Module ist weiterhin experimentell und muss mit -fmodules aktiviert werden
  • Viele C++26-Funktionen wurden implementiert, darunter Reflection, Annotations for Reflection, Base-Class-Subobject-Splicing, Function-Parameter-Reflection, Contracts, constexpr-Exceptions und constexpr Virtual Inheritance
    • P2996R13 Reflection wird mit -std=c++26 -freflection aktiviert
    • Teile von P2686R4 werden teilweise unterstützt; Structured Bindings können constexpr sein, aber Referenzen auf automatische constexpr-Variablen sind noch nicht erlaubt
  • C++23-Funktionen aus P2036R3, P2590R2 und P2246R1 wurden implementiert
  • C++-Fehlermeldungen haben bei Problemen wie Template-bezogenen Fehlern nun eine hierarchische Struktur; die Verschachtelung der Meldungen wird durch Einrückung und Aufzählungspunkte dargestellt
  • Die experimentelle Unterstützung für C++20-Module baut mit der zusätzlichen Option --compile-std-module die Header Unit <bits/stdc++.h> sowie die Module std und std.compat, bevor die Quelldatei kompiliert wird
    • Wenn die Header Unit <bits/stdc++.h> gebaut wurde, werden #include-Anweisungen für importierbare Standardbibliotheks-Header transparent in einen Import von <bits/stdc++.h> umgewandelt
    • Viele gemeldete Bugs wurden behoben
  • Constraint-Failure-Diagnostics für Type Traits der Standardbibliothek geben nun detaillierter an, warum is_constructible_v, is_invocable_v usw. false ergeben
  • Auf Targets mit Unterstützung für 128-Bit-Integer liefert in libstdc++ std::is_integral<__int128> und ähnliche Traits nun immer true
    • Zuvor war das in GNU-Dialekten true, in strikten Dialekten jedoch nicht
  • P0952R2: A new specification for std::generate_canonical wurde in allen seit C++11 betroffenen Modi implementiert und beeinflusst die beobachtbare Ausgabe
    • Das frühere Verhalten kann durch Definition von _GLIBCXX_USE_OLD_GENERATE_CANONICAL wiederhergestellt werden
  • Die ABI von std::variant wurde aktualisiert, um mit Modi ab C++20 konsistent zu sein, was das Klassenlayout in bestimmten C++17-Modi beeinflusst
    • Das frühere Verhalten kann durch Definition von _GLIBCXX_USE_VARIANT_CXX17_OLD_ABI wiederhergestellt werden; die Auswirkung betrifft nur den C++17-Modus
  • Die Ausführung von std::regex wurde so umgeschrieben, dass statt des System-Stacks ein Heap-basierter Stack verwendet wird, um Stack Overflows bei größerem String-Matching zu vermeiden
  • Die C++20-Implementierung ist nicht länger experimentell, und std::chrono::current_zone() funktioniert unter Windows
  • Da die C++20-Unterstützung vor GCC 16 experimentell war, sollte man davon ausgehen, dass Programme mit C++20-Komponenten nicht mit älteren Releases kompatibel sind
    • Zu den ABI-Änderungen gehören Waiting-/Notifying-Funktionen aus <atomic>, der Semaphore-Typ aus <semaphore>, Synchronisierung in <syncstream>, std::format-Argumente und die Darstellung von std::formatter, std::partial_ordering aus <compare> sowie die Darstellung einiger Adaptor-Typen aus <ranges>
  • Die experimentelle Unterstützung für die C++23-Bibliothek umfasst std::mdspan, ranges::starts_with, ranges::ends_with, ranges::shift_left, ranges::shift_right und std::allocator_traits::allocate_at_least
  • Die experimentelle Unterstützung für die C++26-Bibliothek umfasst std::simd, std::inplace_vector, std::optional<T&>, std::copyable_function, std::function_ref, std::indirect, std::polymorphic, std::owner_equal für Shared Pointer sowie den Header <debugging>

Unterstützung für Targets und Betriebssysteme

  • IA-32/x86-64

    • CPUs auf Basis von AMD Zen6 werden mit -march=znver6 unterstützt und aktivieren zusätzlich zu den für Zen5 aktivierten ISA-Erweiterungen AVX512_BMM, AVX_NE_CONVERT, AVX_IFMA, AVX_VNNI_INT8 und AVX512_FP16
    • Wenn AVX512-Unterstützung aktiviert ist und znver4, znver5 oder znver6 als Tuning verwendet wird, versucht die Auto-Vektorisierung, masked vector epilogs zu verwenden, um die Codegröße zu reduzieren und die Performance zu verbessern
    • Intel Wildcat Lake wird mit -march=wildcatlake, Intel Nova Lake mit -march=novalake unterstützt
      • -march=novalake aktiviert zusätzlich zu den ISA-Erweiterungen auf Basis von Panther Lake auch APX_F, AVX10.1, AVX10.2 und PREFETCHI
    • Ab GCC 16 wurde bei mehreren -march=-Schaltern die Aktivierung von AMX-TRANSPOSE, USER_MSR, CLDEMOTE, KL, WIDEKL und PREFETCHI entfernt
    • -mavx10.1-256, -mavx10.1-512 und -mevex512 wurden entfernt, ebenso die Warnung über geändertes Verhalten von -mavx10.1
    • Die Unterstützung für AMX-TRANSPOSE wurde in GCC 16 entfernt, und GCC akzeptiert -mamx-transpose nicht mehr
    • Die neue Configure-Option --enable-x86-64-mfentry aktiviert -mfentry, das für x86-64-Profiling __fentry__ statt mcount verwendet; auf glibc-Targets ist dies standardmäßig aktiviert
    • --enable-tls=DIALECT unterstützt die Steuerung des Standard-TLS-Dialekts; der Standardwert ist gnu, erlaubte Werte sind gnu und gnu2 für TLS-Deskriptoren

  • AMD GPU, LoongArch, IBM z Systems

    • Beim AMD-GPU-Offloading wurde der Launch-Overhead von OpenMP-Target-Regionen und OpenACC-Compute-Regionen deutlich reduziert
    • Experimentelle Unterstützung für AMD Instinct MI300 gfx942-Geräte wurde hinzugefügt, ebenso gfx950, das mit gfx9-4-generic weitgehend kompatibel ist
    • Das Standard-Multilib-Build-Set für AMD GPU wurde auf gfx908, gfx90a, gfx9-generic, gfx9-4-generic, gfx10-3-generic und gfx11-generic geändert
      • Wenn eine generische Architektur vorhanden ist, werden Multilibs für spezifische Geräte standardmäßig nicht mehr gebaut
      • Generische Architekturen erfordern ROCm 6.4.0 oder neuer
      • Das neue Standard-Multilib-Set erfordert Assembler und Linker aus LLVM 20 oder neuer
      • Siehe die AMD installation notes und configuration notes von GCC
    • LoongArch unterstützt bitgenaue Integer-Typen wie _BitInt (N) und unsigned _BitInt (N)
    • LoongArch unterstützt mit dem Attribut target_clones Function Multi-Versioning, das Funktionsversionen für CPU-Features erstellt und zur Laufzeit automatisch die optimale Version auswählt
    • Unterstützung für die LoongArch32-Architektur wurde hinzugefügt, einschließlich des Standard-ABI ilp32d sowie der ABIs ilp32f und ilp32s
      • Dabei werden sowohl die Standard-32-Bit-Version LA32 als auch die reduzierte 32-Bit-Version LA32R abgedeckt, wodurch die Erzeugung von 32-Bit-Target-Code für Embedded-Anwendungen möglich wird
      • Diese Funktion hängt von der Unterstützung durch Binutils und glibc ab
    • S/390, System z und IBM z Systems unterstützen bitgenaue Integer-Typen und den Gleitkommatyp _Float16
      • _Float16-Operationen werden per Software oder mit float-Instruktionen ausgeführt
    • Für die S/390-Familie wurde ein globaler Stack-Protector mit -mstack-protector-guard=global hinzugefügt, um Runtime-Patching beim Laden von Canary-Adressen im Linux-Kernel zu unterstützen; außerdem wurde -mstack-protector-guard-record ergänzt
    • Die Unterstützung für -m31 in der S/390-Familie ist deprecated und wird in einer zukünftigen Version entfernt

  • Betriebssysteme

    • Solaris unterstützt mit der Option -gsctf unkompliziert die Erzeugung von Solaris CTF, also Compact C Type Format
    • Windows unterstützt natives TLS, also Thread-Local Storage
      • Zur Aktivierung sind beim Configure --enable-tls sowie GNU binutils 2.44 oder neuer erforderlich

Diagnose, Plugins, statische Analyse

  • GCC unterstützt mit -fdiagnostics-add-output=experimental-html Diagnoseausgabe im HTML-Format
  • Die SARIF-Ausgabe folgt dem Dump-Verzeichnis; im Ausgabebeispiel build-dir/foo.o schreibt GCC 16 SARIF nach build-dir/foo.c.sarif
    • GCC 15 schrieb im gleichen Beispiel nach foo.c.sarif
  • Die SARIF-Ausgabe erfasst die Verschachtelung logischer Orte und enthält in vielen Fällen eine description-Property im fix-Objekt
  • Die kinds-Property von SARIF-threadFlowLocation erhält neu die Werte throw, catch, unwind, setjmp und longjmp zur Darstellung nicht standardisierter Kontrollflüsse
  • GCC-Diagnosen können gerichtete Graphen verknüpfen und auch globale gerichtete Graphen melden
    • Graphen werden im Text-Sink ignoriert, aber im SARIF-Sink erfasst; experimental-html rendert sie SVG-basiert mit dot
    • Wenn bei SARIF- oder HTML-Diagnose-Sinks cfgs=yes gesetzt wird, wird die Erfassung der GCC-Zwischendarstellung für alle Funktionen in allen Optimierungspässen aktiviert
  • GCC-Diagnosen können auf logische Orte innerhalb von XML- und JSON-Dateien verweisen
    • Das Tool sarif-replay nutzt dies, um beim Melden von Problemen in SARIF-Eingaben JSON-Pointer bereitzustellen
  • Wenn GCC_DIAGNOSTICS_LOG in der Umgebung gesetzt ist, gibt das Diagnose-Subsystem ein Text-Log nach stderr oder in eine benannte Datei aus
    • Das dient dazu, interne Entscheidungen nachzuverfolgen, etwa wann und warum Diagnosen verworfen werden
  • Wenn EXPERIMENTAL_SARIF_SOCKET in der Umgebung gesetzt ist, versucht GCC beim Start, sich mit diesem Socket zu verbinden, und sendet für jede auftretende Diagnose eine JSON-RPC-Benachrichtigung
  • Für Plugin-Autoren wurde ein Publish/Subscribe-Framework hinzugefügt, das stark typisierte Nachrichten zwischen lose gekoppelten Sendern und Empfängern überträgt
    • In diesem Release können Plugins nur Themen abonnieren, die Start-/Stopp-Ereignisse von Optimierungspässen bestimmter Funktionen sowie Ereignisse rund um den statischen Analysator betreffen
  • GCC-Diagnose-Sinks können ein extension-Objekt mit einem finalizer-Hook besitzen; Plugins können dies nutzen, um zusätzliche Informationen in der SARIF-Ausgabedatei zu erfassen
  • In GCC 16 wurde die Diagnose-Infrastruktur umfassend aufgeräumt; Plugins, die nur diagnostic-core.h verwenden, sollten nicht betroffen sein
    • Maintainer von Plugins mit komplexerer Diagnose-Nutzung sollten den Porting Guide beachten
  • Der statische Analysator verarbeitet eine erste Unterstützung für C++ Named Return Value Optimization und Exceptions und kann dadurch bei einfachen C++-Beispielen verwendet werden
    • Wegen Skalierungsproblemen dürfte er sich in diesem Release aber kaum für produktiven C++-Code eignen
  • -fanalyzer nimmt bei aktiviertem -fexceptions an, dass externe Funktionsaufrufe ohne nothrow-Attribut Exceptions auslösen können
    • Die neue Option -fanalyzer-assume-nothrow deaktiviert diese Annahme
    • Das soll den Anstieg von Warnungen in Projekten umgehen, die -fexceptions im C-Code für C++-Interoperabilität verwenden, obwohl die genutzte C-API wahrscheinlich keine Exceptions auslöst
  • Die Datenstruktur für die Repräsentation von User Code in -fanalyzer wurde neu geschrieben, damit sie leichter zu verstehen und zu debuggen ist; außerdem wurden Diagnose-Orte leicht verbessert
    • Dafür steigt der Speicherverbrauch des Analysators
  • Die Datenstruktur zur Simulation von Speicherinhalten in -fanalyzer wurde neu implementiert und ist nun schneller und leichter wartbar
  • Der Analysator beginnt, die value_range-Infrastruktur von GCC zu nutzen, wodurch einige False Positives entfernt werden

libgdiagnostics und behobene Probleme

Verwandte Beiträge

Noch keine Kommentare.

Noch keine Kommentare.