GCC 16 yayımlandı

 (gcc.gnu.org)
1 puan yazan GN⁺ 2026-05-01 | 2 yorum | WhatsApp'ta paylaş
  • GNU Compiler Collection’ın yeni sürümü, varsayılan C++ standardını gnu++20’ye değiştirerek C++20 uygulamasını artık deneysel görmeyen önemli bir dönüm noktası oluyor
  • C++26 reflection, contracts ve constexpr özellikleri, C++23 özellikleri ve deneysel C++23·C++26 library desteği eklendi; template hataları ile type trait constraint failure tanıları katmanlı mesajlarla daha ayrıntılı hale geldi
  • OpenMP ve OpenACC; GPU bellek ayırma, target memset ve device memcpy API’lerini genişletti; Ada, Fortran, Modula-2 ve Algol 68 front end’lerine de yeni dil özellikleri ve deneysel derleyiciler geldi
  • x86-64; AMD Zen6, Intel Wildcat Lake ve Intel Nova Lake desteği kazandı; AMD GPU, LoongArch, IBM z Systems, Solaris ve Windows tarafında da hedefe özgü özellikler ve ABI değişiklikleri eklendi
  • JSON tanı biçiminin kaldırılması, SARIF ve HTML tanılarının güçlendirilmesi, static analyzer iyileştirmeleri ve libgdiagnostics’e 37 entrypoint eklenmesiyle araç entegrasyonu ve tanı altyapısı önemli ölçüde genişledi

Uyumluluk değişiklikleri ve ortak iyileştirmeler

  • Solaris’te int8_t vb., C99 standardına uyum için signed char oldu; bu geriye dönük uyumlu olmayan bir değişiklik
  • Solaris’te -pthread seçeneği artık _REENTRANT değerini önceden tanımlamıyor
  • -fdiagnostics-format= için json biçimi kaldırıldı; makine tarafından okunabilir tanılar için SARIF kullanılmalı
  • Link-Time Optimization, -flto-toplevel-asm-heuristics ile üst düzey asm ifadelerini daha iyi ele alıyor
  • speculative devirtualization, genel dolaylı fonksiyon çağrılarını işliyor ve birden fazla hedef tahminini destekliyor
  • vectorizer, reduction için döngü içi paralelliği belirlemede daha esnek hale geldi; yineleme sayısı bilinmeyen döngüler ile uncounted loop vektörleştirmesini destekliyor
    • Ayrıca masking kullanan vector length agnostic loop’larda hizalama için peeling, mutual peeling for alignment ve early break döngülerinde vector induction hesaplamasının kaldırılmasını da destekliyor
  • GCC Command Options ve option index, daha önce eksik olan çok sayıda seçeneği içerecek şekilde düzeltildi
  • GCC-specific attributes belgeleri, GCC’nin desteklediği tüm C/C++ dialect’lerinde geçerli olan standart attribute sözdizimini daha fazla vurgulayacak şekilde modernize edildi
    • attribute materyali tekrarları azaltacak şekilde yeniden düzenlendi ve yeni bir attribute index eklendi
    • parameter ve option spec file belgeleri, GCC geliştiricileri ile özel GCC yapılandırmalarına ihtiyaç duyan kullanıcılar için GCC internals manual içine taşındı

Dillere göre başlıca değişiklikler

  • OpenMP ve OpenACC

    • OpenMP bellek ayırma desteği güçlendirildi; pinned trait allocator ve ompx_gnu_pinned_mem_alloc, kullanılabildiğinde CUDA API kullanıyor ve Nvidia GPU'larda ilgili bellek erişim performansını iyileştiriyor
    • GNU uzantısı olan ompx_gnu_managed_mem_alloc allocator ve ompx_gnu_managed_mem_space, host üzerinde device tarafından erişilebilir bellek ayırıyor
      • unified-shared memory desteklenmese bile device erişimi mümkün oluyor ve tüm host belleğinin device-accessible olduğu sistemlerde de diğer belleklerden farklı page-migration davranışı gösterebiliyor
    • OpenMP 5.0, C/C++ için sınırlı declare mapper desteği ekledi; uses_allocators clause ise OpenMP 5.2 söz dizimi değişikliklerini ve OpenMP 6.0 semicolon desteğini de içeriyor
    • OpenMP 5.1, C/C++ için map clause ve target update construct içindeki iterator modifier'a ilk desteği ekliyor
    • OpenMP 5.2, C/C++ için begin declare variant directive desteği sunuyor
    • OpenMP 6.0, omp_target_memset ve omp_target_memset_async API routine'lerini ekledi; ayrıca no_openmp_constructs assumptions clause da kullanılabiliyor
    • OpenMP 5.0, 5.1 ve 5.2'de deprecated olan directive ve clause'lar varsayılan olarak deprecation warning üretir; bu davranış -Wno-deprecated-openmp ile kapatılabilir
      • deprecated named constant veya API routine kullanıldığında da warning verilir; bu da -Wno-deprecated-declarations ile kapatılabilir
    • OpenACC, C/C++/Fortran için acc_memcpy_device ve acc_memcpy_device_async API routine'lerini ekledi
    • OpenACC 3.0'ın wait directive'i if clause alabiliyor; OpenACC 3.3'ün Fortran API routine'leri acc_attach ve acc_detach, OpenACC 2.6 C/C++ karşılıklarını tamamlıyor
    • OpenACC 3.4'te Fortran data clause içinde named constant PARAMETER kullanımı hem spesifikasyonda hem de GCC'de izinli, ancak GCC'de derleme zamanı ve çalışma zamanı davranışını etkilemiyor

  • Ada, Fortran, Modula-2, Algol 68

    • Ada GNAT uzantılarına Constructor ve Destructor eklendi; böylece standart Ada'dan oldukça farklı bir construction/finalization mekanizması sağlanıyor
    • Ada için Implicit with, Structural Generic instantiation ve Extended_Access aspect'leri eklendi
      • Extended_Access, unconstrained array subtype'ını işaret eden general access type declaration üzerinde belirtilebiliyor; pointer representation'ı değiştiriyor ve Ada'nın ayırmadığı belleğin foreign language ile birlikte kullanılmasını kolaylaştırıyor
    • Ada, -gnatd_V veya verbose mode'daki -gnatd_W ile derleyici hata ayıklaması için VAST kullanabiliyor; ayrıca Ada 2022 Reduction Expressions semantic analysis, Ada.Containers.Bounded_Indefinite_Holders, accessibility rule uygulaması ve Android desteği iyileştirildi
    • Fortran, single node machine üzerinde native shared memory multithreading kullanan coarray'leri ve Fortran 2018 TEAM özelliğini ele alıyor
    • Fortran 2003 Parameterized Derived Types desteği iyileştirildi ve LEN parameter işleme çalışıyor, ancak PR82649 nedeniyle gelecekte representation değişikliği gerekiyor
    • Fortran 2018, IMPORT statement genişletmeleri, REDUCE intrinsic ve yeni GENERIC statement desteği sunuyor
    • Fortran 2023, sinpi gibi ek trigonometrik fonksiyonları, split intrinsic subroutine'ini ve opsiyonel lower bound argümanı alabilen c_f_pointer desteğini getiriyor
    • -fexternal-blas64 seçeneği, MATMUL içinde 64-bit integer argümanlarla external BLAS routine çağırır; yalnızca 64-bit sistemlerde ve -ffrontend-optimize etkin olduğunda geçerlidir
    • Modula-2, import list, module name ve nested scope symbol işleme sırasında spelling hint veriyor; ayrıca yeni bir wide set uygulaması ve M2WIDESET library module'ü sunuyor
      • wide set değişikliği ABI'yi değiştiriyor ve önceki GCC sürümlerinden object file'larla link-time error oluşturabiliyor
    • Modula-2'nin varsayılan library'sine BinDict binary dictionary module'ü eklendi; çeşitli module'lere Write ve WriteLn procedure'leri sağlandı ve -fm2-pathname-root= seçeneğiyle external library module erişimi iyileştirildi
    • GCC, deneysel Algol 68 derleyicisi ga68'i içeriyor ve Revised Report ile IFIP WG2.1 Algol 68 Support alt komitesince onaylanan errata'yı uygulamayı hedefliyor
      • Bazı GNU extension'ları ve POSIX prelude da uygulanıyor; dil bilgisi için Algol 68 website, front end bilgisi için wiki incelenebilir

C++ ve libstdc++

  • C++ derlemesinin varsayılan dil sürümü -std=gnu++17 yerine -std=gnu++20 oldu
    • Önceki C++ standartlarına bağımlı kodların build flag’ine -std= eklemesi veya kodu port etmesi gerekiyor; ayrıntılar için porting notes bölümüne bakın
    • C++20 modules desteği hâlâ experimental ve -fmodules ile etkinleştirilmeli
  • C++26 özellikleri arasında reflection, annotations for reflection, base class subobject splicing, function parameter reflection, contracts, constexpr exceptions, constexpr virtual inheritance gibi birçok özellik implemente edildi
    • P2996R13 Reflection -std=c++26 -freflection ile etkinleştiriliyor
    • P2686R4 için kısmi destek var; structured binding constexpr olabilir, ancak constexpr automatic variable referanslarına henüz izin verilmiyor
  • C++23 özelliklerinden P2036R3, P2590R2 ve P2246R1 implemente edildi
  • C++ hata mesajları, template ile ilgili sorunlar gibi durumlarda artık hiyerarşik bir yapı kullanıyor; message nesting, girinti ve bullet point’lerle gösteriliyor
  • experimental C++20 modules desteği, source file derlenmeden önce <bits/stdc++.h> header unit’i ile std ve std.compat module’larını build etmek için --compile-std-module seçeneğini ekliyor
    • <bits/stdc++.h> header unit’i build edilmişse, import edilebilir standard library header’larının #include kullanımları şeffaf biçimde <bits/stdc++.h> import’una dönüştürülüyor
    • Bildirilen birçok bug düzeltildi
  • Standard library type trait’lerindeki constraint failure diagnostics, is_constructible_v, is_invocable_v gibi trait’lerin neden false döndüğünü daha ayrıntılı açıklıyor
  • libstdc++ içinde 128-bit integer destekleyen target’larda std::is_integral<__int128> ve benzeri trait’ler artık her zaman true oluyor
    • Önceden GNU dialect’te true iken strict dialect’te böyle değildi
  • P0952R2: A new specification for std::generate_canonical, C++11 sonrası etkilenen tüm mode’larda implemente edildi ve gözlemlenen output’u etkiliyor
    • Eski davranış _GLIBCXX_USE_OLD_GENERATE_CANONICAL tanımıyla geri getirilebilir
  • std::variant ABI’si, C++20 ve üzeri mode’larla tutarlı olacak şekilde güncellendi ve belirli C++17 mode class layout’larını etkiliyor
    • Eski davranış _GLIBCXX_USE_VARIANT_CXX17_OLD_ABI tanımıyla geri getirilebilir; etki yalnızca C++17 mode için geçerli
  • std::regex execution, system stack yerine heap-based stack kullanacak şekilde yeniden yazıldı; böylece daha büyük string matching işlemlerinde stack overflow önleniyor
  • C++20 implementasyonu artık experimental değil ve Windows üzerinde std::chrono::current_zone() çalışıyor
  • GCC 16 öncesindeki C++20 desteği experimental olduğundan, C++20 bileşenlerini kullanan programların older release’lerle uyumlu olmadığı varsayılmalı
    • ABI değişiklikleri arasında <atomic> waiting/notifying function’ları, <semaphore> semaphore türü, <syncstream> synchronization, std::format args ve std::formatter representation’ı, <compare> içindeki std::partial_ordering ve bazı <ranges> adaptor representation’ları yer alıyor
  • experimental C++23 library desteği; std::mdspan, ranges::starts_with, ranges::ends_with, ranges::shift_left, ranges::shift_right ve std::allocator_traits::allocate_at_least özelliklerini içeriyor
  • experimental C++26 library desteği; std::simd, std::inplace_vector, std::optional<T&>, std::copyable_function, std::function_ref, std::indirect, std::polymorphic, shared pointer için std::owner_equal ve <debugging> header’ını içeriyor

Hedef ve işletim sistemi desteği

  • IA-32/x86-64

    • AMD Zen6 tabanlı CPU'lar -march=znver6 ile destekleniyor ve Zen5'te etkin olan ISA extension'larının üzerine AVX512_BMM, AVX_NE_CONVERT, AVX_IFMA, AVX_VNNI_INT8, AVX512_FP16 etkinleştiriliyor
    • AVX512 desteği açıkken ve znver4, znver5, znver6 tuning kullanıldığında, auto-vectorization code size'ı azaltmak ve performansı iyileştirmek için masked vector epilog kullanımını deniyor
    • Intel Wildcat Lake -march=wildcatlake, Intel Nova Lake ise -march=novalake ile destekleniyor
      • -march=novalake, Panther Lake tabanlı ISA extension'larına ek olarak APX_F, AVX10.1, AVX10.2, PREFETCHI'yi etkinleştiriyor
    • GCC 16'dan itibaren çeşitli -march= switch'lerinde AMX-TRANSPOSE, USER_MSR, CLDEMOTE, KL, WIDEKL, PREFETCHI etkinleştirmesi kaldırıldı
    • -mavx10.1-256, -mavx10.1-512, -mevex512 kaldırıldı; -mavx10.1 behavior change warning de birlikte ortadan kalktı
    • AMX-TRANSPOSE desteği GCC 16'da kaldırıldı ve GCC artık -mamx-transpose seçeneğini kabul etmiyor
    • Yeni --enable-x86-64-mfentry configure seçeneği, x86-64 profillemede mcount yerine __fentry__ kullanan -mfentry'yi etkinleştiriyor; glibc hedeflerinde varsayılan olarak açık geliyor
    • --enable-tls=DIALECT, varsayılan TLS dialect kontrolünü destekliyor; varsayılan değer gnu, izin verilen değerler ise gnu ve TLS descriptor için gnu2

  • AMD GPU, LoongArch, IBM z Systems

    • AMD GPU offloading'de OpenMP target region ve OpenACC compute region başlatma ek yükü önemli ölçüde azaltıldı
    • AMD Instinct MI300 gfx942 cihazı için deneysel destek eklendi; buna generic gfx9-4-generic ile büyük ölçüde uyumlu gfx950 de dahil
    • AMD GPU varsayılan multilib build set'i gfx908, gfx90a, gfx9-generic, gfx9-4-generic, gfx10-3-generic, gfx11-generic olarak değiştirildi
      • Generic arch varsa, specific device için multilib artık varsayılan olarak derlenmiyor
      • Generic architecture, ROCm 6.4.0 ve üzerini gerektiriyor
      • Yeni varsayılan multilib set'i, LLVM 20 ve üzeri assembler ile linker gerektiriyor
      • GCC'nin AMD kurulum notlarına ve yapılandırma notlarına bakın
    • LoongArch, _BitInt (N) ve unsigned _BitInt (N) gibi bit hassasiyetli tamsayı türlerini destekliyor
    • LoongArch, CPU özelliğine göre function version oluşturup çalışma anında en uygun sürümü otomatik seçen Function Multi-Versioning'i target_clones attribute'u ile destekliyor
    • LoongArch32 architecture desteği eklendi; buna varsayılan ilp32d ABI ile ilp32f ve ilp32s ABI'leri de dahil
      • Standart 32-bit sürüm LA32 ile azaltılmış 32-bit sürüm LA32R'nin ikisini de kapsıyor ve embedded uygulamalar için 32-bit target code üretimini mümkün kılıyor
      • Bu özellik Binutils ve glibc desteğine bağlı
    • S/390, System z ve IBM z Systems, bit hassasiyetli tamsayı türleri ile _Float16 floating-point türünü destekliyor
      • _Float16 işlemleri yazılımla veya float instruction'larıyla gerçekleştiriliyor
    • S/390 ailesine, Linux kernel'in canary address loading runtime patching desteği için -mstack-protector-guard=global ile global stack protector eklendi; ayrıca -mstack-protector-guard-record da eklendi
    • S/390 ailesindeki -m31 desteği deprecated oldu ve gelecekteki bir sürümde kaldırılacak

  • İşletim sistemi

    • Solaris, -gsctf seçeneğiyle Solaris CTF yani Compact C Type Format üretimini kolayca destekliyor
    • Windows, native TLS yani Thread-Local Storage desteği sunuyor
      • Etkinleştirmek için configure sırasında --enable-tls belirtilmesi ve GNU binutils 2.44 veya üzeri gerekiyor

Tanılama, eklentiler, statik analiz

  • GCC, -fdiagnostics-add-output=experimental-html ile HTML biçiminde tanılama çıktısını destekliyor
  • SARIF çıktısı dump directory ayarını takip ediyor; build-dir/foo.o çıktı örneğinde GCC 16, SARIF'i build-dir/foo.c.sarif dosyasına yazıyor
    • GCC 15 aynı örnekte foo.c.sarif dosyasına yazıyordu
  • SARIF çıktısı logical location nesting'i yakalıyor ve birçok durumda fix object'i içinde description property'sini içeriyor
  • SARIF threadFlowLocation öğesinin kinds property alanı, standart dışı control flow gösterimi için yeni olarak throw, catch, unwind, setjmp, longjmp değerlerini kazanıyor
  • GCC diagnostics, directed graph bağlayabiliyor ve global directed graph da raporlayabiliyor
    • graph, text sink içinde yok sayılıyor ancak SARIF sink içinde yakalanıyor; experimental-html ise bunu dot kullanarak SVG tabanlı olarak render ediyor
    • SARIF veya HTML diagnostic sink üzerinde cfgs=yes ayarlanırsa, tüm optimization pass'lerdeki tüm function'lar için GCC intermediate representation yakalama özelliği etkinleşiyor
  • GCC diagnostics, XML ve JSON dosyaları içindeki logical location'lara referans verebiliyor
    • sarif-replay aracı bunu kullanarak SARIF input issue raporlamasında JSON pointer sağlıyor
  • GCC_DIAGNOSTICS_LOG environment içinde ayarlanırsa, diagnostic subsystem stderr'e veya adlandırılmış bir dosyaya metin günlük çıktısı veriyor
    • Bu, tanılamaların tam olarak ne zaman ve neden reddedildiği gibi iç kararların izlenmesi için kullanılıyor
  • EXPERIMENTAL_SARIF_SOCKET environment içinde ayarlanırsa, GCC başlangıçta bu socket'e bağlanmayı deniyor ve oluşan her tanılama için JSON-RPC notification gönderiyor
  • Eklenti geliştiricileri için, loosely-coupled sender ve receiver arasında strongly-typed message ileten bir publish/subscribe framework eklendi
    • Bu sürümde eklentilerin subscribe olabildiği topic'ler yalnızca belirli function'ların optimization pass başlangıç/duruş event'leri ve static analyzer ile ilgili event'ler
  • GCC diagnostic sink, finalizer hook'una sahip bir extension object'ine sahip olabiliyor; eklentiler bunu SARIF output file içine ek bilgi yakalamak için kullanabiliyor
  • GCC 16'da diagnostic machinery büyük ölçüde yeniden düzenlendi ve yalnızca diagnostic-core.h kullanan eklentilerin etkilenmemesi gerekiyor
    • Tanılamaları daha karmaşık kullanan eklenti bakımcılarının porting guide belgesine bakması gerekiyor
  • Static analyzer, C++ Named Return Value Optimization ve exception için ilk desteği ele alıyor; böylece basit C++ örneklerinde kullanılabiliyor
    • Ancak ölçeklenme sorunları nedeniyle bu sürümde production C++ kodunda kullanılması muhtemelen zor
  • -fanalyzer, -fexceptions etkin olduğunda nothrow attribute'u olmayan external function call'ların exception fırlatabileceğini varsayıyor
    • Yeni -fanalyzer-assume-nothrow seçeneği bu varsayımı devre dışı bırakıyor
    • Bu, C++ birlikte çalışabilirliği için C kodunda -fexceptions kullanan ancak kullanılan C API'sinin exception fırlatma olasılığı düşük olan projelerde uyarı artışını önlemek için tasarlandı
  • -fanalyzer için user code representation veri yapıları, anlaşılmasını ve debugging'i kolaylaştırmak için yeniden yazıldı; diagnostic location da bir miktar iyileştirildi
    • Buna karşılık analyzer'ın memory usage'ı arttı
  • -fanalyzer içindeki memory contents simulation veri yapıları yeniden uygulandı; böylece daha hızlı ve bakımı daha kolay hale geldi
  • analyzer, GCC'nin value_range machinery'sini kullanmaya başlayarak bazı false positive'leri ortadan kaldırıyor

libgdiagnostics ve düzeltilen sorunlar

İlgili okumalar

2 yorum

 
dieafterwork 2026-05-01

Nihayet..
 
GN⁺ 2026-05-01
Hacker News yorumları

  • İnsanların benimsemesi gereken ama pratikte muhtemelen pek kullanılmayacak bir uygulama özelliği olarak P2590R2 Explicit lifetime management'ı işaret etmek istiyorum
    Bu, std::start_lifetime_as içindir ve bir pointer'ı yapılandırılmış bir tipe type-pun yapmak için UB olmayan bir yöntemdir
    Harici I/O buffer'larını işleyen neredeyse tüm zero-copy kodları kabaca reinterpret_cast(buffer.get()) gibi görünür ve bu undefined behavior'dır; artık reinterpret_cast yerine start_lifetime_as koyarsanız bu artık kötü bir şey sayılmaz
    https://en.cppreference.com/cpp/memory/start_lifetime_as

    • Bunu yasal olarak yapmanın zaten bir yolu vardı ve herkesin onu kullanıyor olması gerekirdi. Yöntem, pointer'ı no-op memmove ile laundering etmekti
      Burada reinterpret_cast kullanmak bir bug'dır
      start_lifetime_as, bellek laundering büyüsüne temiz bir standart isim vermenin dışında bir şey daha yapıyor. Anlamsal olarak belleğe dokunmuyor, oysa no-op memmove özünde belleğe dokunur. Pratikte derleyici memmove'un no-op olduğunu görüp optimize edebildiği için büyük bir fark azdır
    • alignment kısıtlarını yok sayarsanız bu read implementasyonuna bağlıdır. Derleyici açısından tamamen opaque ise, kernel ya da network kartı gibi bir şeyin gerçekten o buffer'ın içinde Foo oluşturduğu kabul edilir ve cast tamamen meşru hale gelir
      start_lifetime_as, buffer lifetime'ı derleyiciye şeffaf olduğunda ve aliasing varsayımlarını bozabildiğinde faydalıdır
    • cppreference açıklaması biraz şüpheli görünüyor
      Bunun anlamı, T'nin tamamen yeni bir nesne olduğu, içinde subobject'ler bulunduğu ve bunlardan birinin U tipinde olduğudur gibi görünüyor. U, bit_cast gibi initialize ediliyor; muhtemelen bu, cast'in zaten o adreste duran bitlerden yapıldığı anlamına gelmek isteniyordu. Ama obj tanımsız şekilde ortaya çıktığı için, doğru adreste bulunan bir şeyi kastettiğini varsaymak gerekiyor
      Ancak E'nin ne olduğu belirsiz. Sayfada “E is the lvalue of type U denoting obj” yazıyor, ama obj muhtemelen char gibi bir tipte olmalı; zaten U tipinde olsaydı bit_cast gerekmezdi
    • char buffer'larda type punning'e izin verilir
    • O kod sadece kötü değil, alignment sorunu nedeniyle doğru da değil

  • Az önce bakana kadar GCC sürüm takviminin bu kadar düzenli olduğunu bilmiyordum: https://gcc.gnu.org/develop.html

    • Büyük projeler çok uzun zamandır düzenli sürüm modeline geçti
      90'lara kadar insanlar, istenen tüm özellikleri koydukları büyük sürümleri waterfall tarzında çıkarabileceklerini sanıyordu, ama proje büyüyünce her zaman hâlâ hazır olmayan bir özellik üzerinde çalışan biri olur. Düzenli sürüm yapınca en azından müşterilere bir sürüm sunabilirsiniz
      Bu yaklaşım, hazır olup olmayacağı belirsiz geliştiricileri kararsız özellikleri kapatacak bir toggle yapmaya zorlar ve gerçekçi olarak bu yapılabilecek en iyi şeye yakındır
    • Son GCC major sürümleri oldukça düzenliydi; Fedora'nın ilkbahar sürümüyle de benzeşiyor ve daha büyük bir ritme oturmuş gibi görünüyor. İpucu Red Hat
    • Bu, Cygnus ekibinin projeyi toparlamasından sonra böyle oldu. Bugün çizgi RedHat→IBM'e uzanıyor
    • Hatırladığım kadarıyla bu, GCC'ye GPL3 uygulandıktan sonraydı
      Eskiden daha yavaştı ve GCC 2.95'in C++ bug'larını dolaşmak için çok fazla zaman harcadım
      Sorunlu sürümü hâlâ hatırlıyor olmam bile çok şey anlatıyor

  • Bir süredir zaten kullanıyorum. Debian sid'de trunk paketi var
    İçinde c++26 reflection var ve reflection ile biraz sihirli şeyler yapıyorum; ser-des gibi bazı durumlarda çok daha iyi
    Keşke ekosistemde bir LSP sunucusu da olsa

    • Debian 12 ve 13'te GCC 16 binary'lerini çalıştırırken libstd sorun çıkarıyor

  • -fdiagnostics-format= için sözde json formatı bu sürümde kaldırıldı ve GCC'de machine-readable diagnostics istiyorsanız SARIF kullanmanız söyleniyor
    Ama bir yandan da -fdiagnostics-add-output=experimental-html ile diagnostics'in HTML çıktısı alınabildiği söyleniyor
    JSON çıktısı kaldırılırken HTML çıktısının eklenmesi kararının arka planını merak ediyorum

    • SARIF, resmi bir şeması olan bir JSON gibi görünüyor. Önceden verilen JSON çıktısı ise muhtemelen tescilli, standart dışı bir şemaydı

  • Acemi bir soru ama, GCC içeride herhangi bir yerde LLVM kullanıyor mu, yoksa kendi code generation ve optimization pipeline'ına mı sahip? LLVM ile karşılaştırınca seviyesi nasıl?

    • GCC LLVM kullanmıyor
      LLVM'den daha fazla target destekliyor ve çoğu durumda benzer ya da daha iyi executable üretiyor
    • Wikipedia tarzı cevap vermek gerekirse, daha önce de söylendiği gibi GCC, LLVM'den çok daha eski
      Wikipedia'ya göre GCC 22 Mart 1987, LLVM'in ilk sürümü ise 2003
      Bir diğer büyük fark da lisans. GCC GPL, LLVM ise Apache License kullanıyor; bu yüzden iki proje kod paylaşmıyor
    • Kullanmıyor
    • Diğer cevaplardaki “hayır!” doğru, ama eskiden GCC içinde LLVM backend kullanan bir GCC eklentisi vardı
      Apple, GCC'den LLVM'e geçiş döneminde, 2012 civarında llvm-gcc kullanıyordu; bu da GCC front end ile LLVM back end birleşimiydi
      https://dragonegg.llvm.org
    • GCC, LLVM'den çok daha eskidir ve ikisi kod paylaşmaz

  • -Ofast hâlâ -fno-fast-math seçeneğini yok sayıyor mu?

  • Son yaklaşık 3 ay boyunca unstable source kullandım
    Yeni GCC ile derlenmeyen ama eski GCC ile gayet iyi derlenen programlar var; bu yüzden şu anda genel olarak gcc 15.x bana daha uygun geliyor
    Yine de 3000'den fazla program derlediğinizi düşünürseniz çoğu çalışıyor, yalnızca bazılarının patch'lenmesi gerekiyor. Bu tür patch'ler çoğu zaman LFS/BLFS'de bulunabiliyor ve tekil sorunları sed ile düzeltince genelde çalışıyor
    Umarım bu sorunlar düzeltilmiştir. Hepimizin istikrar ve “çalışsın yeter” anlayışına ihtiyacı var

    • Bu sorunlar için bug report gönderdiniz mi?