GCC 16 veröffentlicht

 (gcc.gnu.org)
1 Punkte von GN⁺ 2026-05-01 | 2 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

2 Kommentare

 
dieafterwork 2026-05-01

Endlich..
 
GN⁺ 2026-05-01
Hacker-News-Kommentare

  • Ich möchte P2590R2 Explicit lifetime management als ein Implementierungsfeature hervorheben, das die Leute übernehmen sollten, das aber in der Praxis wohl nicht oft genutzt werden wird
    Es ist für std::start_lifetime_as gedacht und stellt eine nicht-UB-Art dar, Pointer zu strukturierten Typen zu type-punnen
    Fast jeder Zero-Copy-Code, der externe I/O-Buffer verarbeitet, sieht ungefähr wie reinterpret_cast(buffer.get()) aus, und das ist undefined behavior; wenn man nun reinterpret_cast durch start_lifetime_as ersetzt, ist es keine schlechte Praxis mehr
    https://en.cppreference.com/cpp/memory/start_lifetime_as

    • Es gab bereits eine legale Möglichkeit dafür, und alle hätten sie verwenden sollen. Dabei wird der Pointer per No-op-memmove gelaundert
      Ein reinterpret_cast zu verwenden, ist hier ein Bug
      start_lifetime_as macht noch etwas mehr, als nur einen sauberen Standardnamen für den Memory-Laundering-Zauberspruch zu liefern. Semantisch berührt es den Speicher nicht, während ein No-op-memmove den Speicher im Wesentlichen doch berührt. In der Praxis ist der Unterschied klein, weil der Compiler erkennen kann, dass memmove ein No-op ist, und es wegoptimieren kann
    • Wenn man die Alignment-Einschränkungen ignoriert, hängt es von der Implementierung von read ab. Wenn sie aus Sicht des Compilers vollständig opaque ist, dann konstruiert so etwas wie der Kernel oder die Netzwerkkarte tatsächlich Foo in diesem Buffer, womit der Cast völlig gerechtfertigt ist
      start_lifetime_as ist nützlich, wenn die Buffer-Lifetime für den Compiler transparent ist und dadurch Aliasing-Annahmen zerstören könnte
    • Die Erklärung auf cppreference wirkt etwas fragwürdig
      Es scheint zu bedeuten, dass T ein vollständig neues Objekt ist, mit Subobjekten darin, von denen eines Typ U hat. U wird wie bei bit_cast initialisiert, vermutlich war gemeint, dass von den Bits gecastet wird, die bereits an dieser Adresse liegen. Aber da obj ohne Definition auftaucht, muss wohl etwas gemeint sein, das sich an der richtigen Adresse befindet
      Unklar ist allerdings, was E ist. Auf der Seite steht „E is the lvalue of type U denoting obj“, aber obj wäre vermutlich von einem Typ wie char, und wenn es bereits Typ U hätte, bräuchte man kein bit_cast
    • Bei char-Buffern ist Type-Punning erlaubt
    • Der Code ist nicht nur schlechte Praxis, sondern wegen Alignment-Problemen auch nicht korrekt

  • Bis ich es gerade nachgeschlagen habe, wusste ich nicht, dass der GCC-Release-Zeitplan so regelmäßig ist: https://gcc.gnu.org/develop.html

    • Große Projekte setzen schon lange auf regelmäßige Releases
      Bis in die 90er glaubte man, man könne per Waterfall große Releases bauen, in die einfach alle gewünschten Features hineinkommen. Aber wenn ein Projekt größer wird, arbeitet immer jemand an einem Feature, das noch nicht fertig ist. Mit regelmäßigen Releases kann man den Kunden trotzdem Releases liefern
      Dieser Ansatz zwingt Entwickler, bei denen unklar ist, ob etwas rechtzeitig fertig wird, Schalter zum Deaktivieren instabiler Features einzubauen, und realistisch gesehen ist das fast das Beste, was man tun kann
    • Die letzten größeren GCC-Releases waren ziemlich regelmäßig, ähneln dem Fedora-Frühjahrsrelease und scheinen in einen größeren Rhythmus zu passen. Der Hinweis ist Red Hat
    • So ist es, seit die Leute von Cygnus das Projekt neu aufgestellt haben. Heute führt die Linie über Red Hat zu IBM
    • Soweit ich mich erinnere, war das seit der Umstellung von GCC auf GPL3
      Früher ging es langsamer, und ich habe viel zu viel Zeit damit verbracht, C++-Bugs in GCC 2.95 zu umgehen
      Dass ich mich noch an die problematische Version erinnere, sagt schon einiges

  • Ich nutze es schon seit einiger Zeit. In Debian sid gibt es ein Trunk-Paket
    Es enthält c++26 reflection, und ich mache damit ein paar magische Dinge; in manchen Fällen wie SerDes ist es deutlich besser
    Ich wünschte nur, es gäbe im Ökosystem einen LSP-Server

    • Beim Ausführen von GCC-16-Binaries unter Debian 12 und 13 macht libstd Probleme

  • Das sogenannte json-Format von -fdiagnostics-format= wurde in diesem Release entfernt, und wenn man in GCC maschinenlesbare Diagnostics braucht, soll man stattdessen SARIF verwenden
    Gleichzeitig heißt es aber auch, dass man Diagnostics mit -fdiagnostics-add-output=experimental-html als HTML-Ausgabe erzeugen kann
    Mich würde interessieren, was hinter der Entscheidung steckt, JSON-Ausgabe zu entfernen und HTML-Ausgabe hinzuzufügen

    • SARIF wirkt wie JSON mit formellem Schema. Die bisherige JSON-Ausgabe hatte offenbar ein eigenes, nicht standardisiertes Schema

  • Anfängerfrage: Verwendet GCC intern irgendwo LLVM, oder hat es eine eigene Codegenerierung und Optimierungspipeline? Mich würde auch interessieren, auf welchem Niveau es im Vergleich zu LLVM liegt

    • GCC verwendet LLVM nicht
      Es unterstützt mehr Targets als LLVM und erzeugt in den meisten Fällen ähnliche oder bessere Binaries
    • Die Wikipedia-artige Antwort lautet, wie schon erwähnt, dass GCC viel älter ist als LLVM
      Laut Wikipedia stammt GCC vom 22. März 1987, die erste LLVM-Version von 2003
      Ein weiterer großer Unterschied ist die Lizenz. GCC steht unter GPL, LLVM unter der Apache License, daher teilen die beiden Projekte keinen Code
    • Nein
    • Die anderen Antworten mit „Nein!“ stimmen, aber früher gab es ein GCC-Plugin, das ein LLVM-Backend aus GCC heraus nutzte
      Apple verwendete um 2012 herum, während des Übergangs von GCC zu LLVM, llvm-gcc; das war eine Kombination aus GCC-Frontend und LLVM-Backend
      https://dragonegg.llvm.org
    • GCC ist viel älter als LLVM, und die beiden teilen keinen Code

  • Ignoriert -Ofast immer noch -fno-fast-math?

  • Ich habe in den letzten etwa drei Monaten die unstable-Quellen verwendet
    Es gibt Programme, die sich mit aktuellem GCC nicht kompilieren lassen, mit älteren GCC-Versionen aber problemlos, daher passt im Moment insgesamt gcc 15.x besser zu mir
    Wenn man allerdings bedenkt, dass mehr als 3000 Programme kompiliert werden, läuft das meiste gut, und nur für einen Teil braucht man Patches. Solche Patches findet man oft bei LFS/BLFS, und wenn man einzelne Probleme per sed behebt, funktioniert es meist
    Ich hoffe, dass diese Probleme behoben wurden. Wir alle brauchen Stabilität und dass Dinge „einfach funktionieren“

    • Hast du für diese Probleme Bug-Reports eingereicht?