GCC 16 Dirilis

 (gcc.gnu.org)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Rilis baru GNU Compiler Collection menjadi titik balik penting dengan mengubah standar bawaan C++ menjadi gnu++20, dan implementasi C++20 tidak lagi dianggap eksperimental
  • Dukungan untuk fitur reflection, contracts, dan constexpr di C++26, fitur C++23, serta library C++23·C++26 eksperimental telah ditambahkan, dan diagnosis untuk error template serta kegagalan constraint type trait kini lebih rinci dengan pesan bertingkat
  • OpenMP dan OpenACC memperluas alokasi memori GPU, target memset, dan API device memcpy, dan front end Ada·Fortran·Modula-2·Algol 68 juga mendapat fitur bahasa baru dan compiler eksperimental
  • x86-64 mendukung AMD Zen6, Intel Wildcat Lake, dan Intel Nova Lake, dan di sisi AMD GPU·LoongArch·IBM z Systems·Solaris·Windows juga ditambahkan fitur spesifik target dan perubahan ABI
  • Penghapusan format diagnosis JSON serta penguatan diagnosis SARIF·HTML, peningkatan static analyzer, dan penambahan 37 entrypoint di libgdiagnostics secara besar memperluas integrasi alat dan infrastruktur diagnosis

Perubahan kompatibilitas dan peningkatan umum

  • Di Solaris, int8_t dan sejenisnya menjadi signed char untuk mematuhi standar C99, dan ini merupakan perubahan yang tidak kompatibel
  • Di Solaris, opsi -pthread tidak lagi melakukan predefine _REENTRANT
  • Format json pada -fdiagnostics-format= telah dihapus, dan diagnosis yang dapat dibaca mesin harus memakai SARIF
  • Link-Time Optimization kini menangani pemrosesan pernyataan asm tingkat atas dengan lebih baik melalui -flto-toplevel-asm-heuristics
  • speculative devirtualization menangani pemanggilan fungsi tidak langsung umum dan mendukung tebakan lebih dari satu target
  • Vectorizer menjadi lebih fleksibel dalam mengidentifikasi paralelisme di dalam loop untuk reduction, dan mendukung vektorisasi loop dengan jumlah iterasi yang tidak diketahui serta uncounted loop
    • Juga mendukung alignment peeling untuk vector length agnostic loop yang memakai masking, mutual peeling for alignment, dan penghapusan perhitungan vector induction pada loop early break
  • GCC Command Options dan option index telah diperbaiki agar mencakup banyak opsi yang sebelumnya terlewat
  • Dokumentasi GCC-specific attributes dimodernisasi agar lebih menekankan sintaks attribute standar yang diizinkan di semua dialek C/C++ yang didukung GCC
    • Materi attribute disusun ulang untuk mengurangi pengulangan, dan attribute index baru ditambahkan
    • Dokumentasi parameter dan option spec file dipindahkan ke GCC internals manual untuk pengembang GCC dan pengguna yang memerlukan konfigurasi GCC kustom

Perubahan utama per bahasa

  • OpenMP dan OpenACC

    • Dukungan alokasi memori OpenMP diperkuat sehingga allocator trait pinned dan ompx_gnu_pinned_mem_alloc menggunakan CUDA API saat tersedia, serta meningkatkan performa akses memori tersebut pada GPU Nvidia
    • Ekstensi GNU berupa allocator ompx_gnu_managed_mem_alloc dan ompx_gnu_managed_mem_space mengalokasikan memori yang dapat diakses device dari host
      • Akses device tetap dimungkinkan meskipun unified-shared memory tidak didukung, dan bahkan pada sistem tempat semua memori host dapat diakses device, perilaku page-migration dapat berbeda dari memori lain
    • OpenMP 5.0 menambahkan dukungan declare mapper terbatas di C/C++, dan clause uses_allocators juga mencakup perubahan sintaks OpenMP 5.2 hingga dukungan semicolon OpenMP 6.0
    • OpenMP 5.1 menambahkan dukungan awal modifier iterator untuk map clause dan construct target update di C/C++
    • OpenMP 5.2 mendukung directive begin declare variant di C/C++
    • OpenMP 6.0 menambahkan routine API omp_target_memset dan omp_target_memset_async, dan assumptions clause no_openmp_constructs juga dapat digunakan
    • Directive dan clause yang deprecated di OpenMP 5.0, 5.1, dan 5.2 secara default akan memunculkan deprecation warning, yang dapat dimatikan dengan -Wno-deprecated-openmp
      • Warning juga muncul saat menggunakan named constant atau routine API yang deprecated, dan dapat dimatikan dengan -Wno-deprecated-declarations
    • OpenACC menambahkan routine API acc_memcpy_device dan acc_memcpy_device_async untuk C/C++/Fortran
    • Directive wait pada OpenACC 3.0 menerima clause if, dan routine API Fortran acc_attach serta acc_detach pada OpenACC 3.3 melengkapi counterpart C/C++ OpenACC 2.6
    • Pada OpenACC 3.4, penggunaan named constant PARAMETER pada clause data Fortran diperbolehkan oleh spesifikasi maupun GCC, tetapi di GCC tidak memengaruhi perilaku saat compile-time maupun runtime

  • Ada, Fortran, Modula-2, Algol 68

    • Ekstensi Ada GNAT menambahkan Constructor dan Destructor yang menyediakan mekanisme construction/finalization yang cukup berbeda dari Ada standar
    • Aspect Implicit with, Structural Generic instantiation, dan Extended_Access ditambahkan ke Ada
      • Extended_Access dapat ditentukan pada general access type declaration yang menunjuk ke unconstrained array subtype, mengubah representasi pointer, dan mempermudah interoperabilitas dengan bahasa asing untuk memori yang tidak dialokasikan Ada
    • Ada dapat menggunakan VAST untuk debugging compiler melalui -gnatd_V atau -gnatd_W dalam verbose mode, serta mengalami peningkatan pada semantic analysis Ada 2022 Reduction Expressions, Ada.Containers.Bounded_Indefinite_Holders, implementasi accessibility rule, dan dukungan Android
    • Fortran menangani coarray yang menggunakan multithreading shared memory native pada mesin single node dan fitur TEAM dari Fortran 2018
    • Dukungan Fortran 2003 Parameterized Derived Types ditingkatkan, dan penanganan parameter LEN sudah berfungsi tetapi masih memerlukan perubahan representasi di masa mendatang sesuai PR82649
    • Fortran 2018 mendukung perluasan statement IMPORT, intrinsic REDUCE, dan statement GENERIC baru
    • Fortran 2023 mendukung tambahan trigonometric function seperti sinpi, intrinsic subroutine split, serta c_f_pointer yang menerima optional lower bound sebagai argumen
    • Opsi -fexternal-blas64 memanggil routine BLAS eksternal dengan argumen integer 64-bit dari MATMUL, dan hanya berlaku pada sistem 64-bit serta saat -ffrontend-optimize diterapkan
    • Modula-2 memberikan spelling hint saat memproses import list, nama module, dan simbol nested scope, serta memperkenalkan implementasi wide set baru dan module library M2WIDESET
      • Perubahan wide set dapat mengubah ABI dan menyebabkan link-time error dengan object file dari versi GCC sebelumnya
    • Library bawaan Modula-2 menambahkan module kamus biner BinDict, menyediakan procedure Write dan WriteLn di beberapa module, dan meningkatkan akses ke module library eksternal dengan opsi -fm2-pathname-root=
    • GCC menyertakan ga68, compiler Algol 68 eksperimental, dengan tujuan mengimplementasikan Revised Report dan errata yang disetujui subkomite IFIP WG2.1 Algol 68 Support
      • Beberapa GNU extension dan POSIX prelude juga diimplementasikan; untuk informasi bahasa lihat situs Algol 68, dan untuk informasi front end lihat wiki

C++ dan libstdc++

  • Versi bahasa default untuk kompilasi C++ berubah dari -std=gnu++17 menjadi -std=gnu++20
    • Kode yang bergantung pada standar C++ sebelumnya perlu menambahkan -std= pada build flag atau melakukan porting kode; lihat porting notes
    • Dukungan C++20 modules masih bersifat experimental dan harus diaktifkan dengan -fmodules
  • Banyak fitur C++26 telah diimplementasikan, termasuk reflection, annotations for reflection, base class subobject splicing, function parameter reflection, contracts, constexpr exceptions, constexpr virtual inheritance, dan lainnya
    • P2996R13 Reflection diaktifkan dengan -std=c++26 -freflection
    • Sebagian dari P2686R4 didukung secara parsial; structured binding dapat menggunakan constexpr, tetapi referensi ke constexpr automatic variable masih belum diizinkan
  • Fitur C++23 P2036R3, P2590R2, dan P2246R1 telah diimplementasikan
  • C++ error message kini memiliki hierarki untuk masalah seperti yang terkait template, dengan indentation dan bullet point untuk menunjukkan nesting pada message
  • Dukungan experimental C++20 modules membangun header unit <bits/stdc++.h> serta module std dan std.compat sebelum source file dikompilasi dengan menambahkan opsi --compile-std-module
    • Jika header unit <bits/stdc++.h> sudah dibangun, #include untuk standard library header yang dapat di-import akan secara transparan diubah menjadi import <bits/stdc++.h>
    • Banyak bug yang telah dilaporkan telah diperbaiki
  • Constraint failure diagnostics untuk type trait standard library kini memberi tahu dengan lebih rinci mengapa is_constructible_v, is_invocable_v, dan lainnya bernilai false
  • Pada target yang mendukung 128-bit integer di libstdc++, std::is_integral<__int128> dan trait serupa kini selalu bernilai true
    • Sebelumnya ini bernilai true pada GNU dialect, tetapi tidak pada strict dialect
  • P0952R2: A new specification for std::generate_canonical telah diimplementasikan pada semua mode yang terdampak sejak C++11, sehingga memengaruhi output yang teramati
    • Perilaku sebelumnya dapat dipulihkan dengan mendefinisikan _GLIBCXX_USE_OLD_GENERATE_CANONICAL
  • ABI std::variant telah diperbarui agar konsisten dengan mode C++20 ke atas, dan memengaruhi class layout pada mode C++17 tertentu
    • Perilaku sebelumnya dapat dipulihkan dengan mendefinisikan _GLIBCXX_USE_VARIANT_CXX17_OLD_ABI, dan dampaknya hanya berlaku pada mode C++17
  • Eksekusi std::regex telah ditulis ulang agar menggunakan stack berbasis heap alih-alih system stack, sehingga menghindari stack overflow saat mencocokkan string yang lebih besar
  • Implementasi C++20 tidak lagi experimental, dan std::chrono::current_zone() kini berfungsi di Windows
  • Karena dukungan C++20 sebelum GCC 16 bersifat experimental, program yang menggunakan komponen C++20 harus dianggap tidak kompatibel dengan rilis yang lebih lama
    • ABI yang berubah mencakup waiting/notifying function di <atomic>, semaphore type di <semaphore>, sinkronisasi di <syncstream>, representasi args std::format dan std::formatter, std::partial_ordering di <compare>, serta representasi beberapa adaptor <ranges>
  • Dukungan library C++23 experimental mencakup std::mdspan, ranges::starts_with, ranges::ends_with, ranges::shift_left, ranges::shift_right, dan std::allocator_traits::allocate_at_least
  • Dukungan library C++26 experimental mencakup std::simd, std::inplace_vector, std::optional<T&>, std::copyable_function, std::function_ref, std::indirect, std::polymorphic, std::owner_equal untuk shared pointer, serta header <debugging>

Dukungan target dan sistem operasi

  • IA-32/x86-64

    • CPU berbasis AMD Zen6 didukung dengan -march=znver6, dan mengaktifkan AVX512_BMM, AVX_NE_CONVERT, AVX_IFMA, AVX_VNNI_INT8, AVX512_FP16 di atas ISA extension yang diaktifkan pada Zen5
    • Jika dukungan AVX512 aktif dan tuning menggunakan znver4, znver5, znver6, auto-vectorization akan mencoba memakai masked vector epilog untuk mengurangi ukuran kode dan meningkatkan performa
    • Intel Wildcat Lake didukung dengan -march=wildcatlake, Intel Nova Lake didukung dengan -march=novalake
      • -march=novalake juga mengaktifkan APX_F, AVX10.1, AVX10.2, PREFETCHI di atas ISA extension berbasis Panther Lake
    • Mulai GCC 16, aktivasi AMX-TRANSPOSE, USER_MSR, CLDEMOTE, KL, WIDEKL, PREFETCHI di berbagai switch -march= dihapus
    • -mavx10.1-256, -mavx10.1-512, -mevex512 dihapus, dan warning perubahan perilaku -mavx10.1 juga ikut hilang
    • Dukungan AMX-TRANSPOSE dihapus pada GCC 16, dan GCC tidak lagi menerima -mamx-transpose
    • Opsi configure baru --enable-x86-64-mfentry mengaktifkan -mfentry, yang memakai __fentry__ alih-alih mcount untuk profiling x86-64, dan di target glibc ini aktif secara default
    • --enable-tls=DIALECT mendukung kontrol dialect TLS default, dengan nilai default gnu, dan nilai yang diizinkan adalah gnu serta gnu2 untuk TLS descriptor

  • AMD GPU, LoongArch, IBM z Systems

    • Pada offloading AMD GPU, overhead peluncuran OpenMP target region dan OpenACC compute region berkurang drastis
    • Dukungan eksperimental untuk perangkat AMD Instinct MI300 gfx942 ditambahkan, dan juga gfx950 yang kompatibel dengan generic gfx9-4-generic dalam banyak kasus
    • Set build multilib default AMD GPU berubah menjadi gfx908, gfx90a, gfx9-generic, gfx9-4-generic, gfx10-3-generic, gfx11-generic
      • Jika ada arsitektur generic, multilib untuk perangkat spesifik tidak lagi dibangun secara default
      • Arsitektur generic memerlukan ROCm 6.4.0 atau lebih baru
      • Set multilib default baru memerlukan assembler dan linker LLVM 20 atau lebih baru
      • Lihat AMD installation notes dan configuration notes di GCC
    • LoongArch mendukung tipe integer presisi-bit seperti _BitInt (N) dan unsigned _BitInt (N)
    • LoongArch mendukung Function Multi-Versioning melalui atribut target_clones untuk membuat versi fungsi per fitur CPU dan otomatis memilih versi optimal saat runtime
    • Dukungan untuk arsitektur LoongArch32 ditambahkan, mencakup ABI default ilp32d serta ABI ilp32f dan ilp32s
      • Ini mencakup versi 32-bit standar LA32 dan versi 32-bit ringkas LA32R, sehingga memungkinkan pembuatan kode target 32-bit untuk aplikasi embedded
      • Fitur ini bergantung pada dukungan Binutils dan glibc
    • S/390, System z, IBM z Systems mendukung tipe integer presisi-bit dan tipe floating-point _Float16
      • Operasi _Float16 dijalankan melalui software atau instruksi float
    • Pada keluarga S/390, global stack protector untuk mendukung runtime patching pemuatan alamat canary di kernel Linux ditambahkan melalui -mstack-protector-guard=global, dan -mstack-protector-guard-record juga ditambahkan
    • Dukungan -m31 pada keluarga S/390 telah deprecated dan akan dihapus pada rilis mendatang

  • Sistem operasi

    • Solaris memudahkan pembuatan Solaris CTF, yaitu Compact C Type Format, melalui opsi -gsctf
    • Windows mendukung native TLS, yaitu Thread-Local Storage
      • Untuk mengaktifkannya, saat configure perlu menentukan --enable-tls dan GNU binutils 2.44 atau lebih baru

Diagnostik, plugin, analisis statis

  • GCC mendukung output diagnostik berformat HTML dengan -fdiagnostics-add-output=experimental-html
  • Output SARIF mengikuti dump directory, dan dalam contoh output build-dir/foo.o, GCC 16 menulis SARIF ke build-dir/foo.c.sarif
    • GCC 15 dalam contoh yang sama menulisnya ke foo.c.sarif
  • Output SARIF menangkap logical location nesting, dan dalam banyak kasus menyertakan properti description di objek fix
  • Properti kinds property pada SARIF threadFlowLocation kini mendapatkan nilai throw, catch, unwind, setjmp, longjmp untuk representasi control flow nonstandar
  • Diagnostik GCC dapat menautkan directed graph, dan juga dapat melaporkan global directed graph
    • graph diabaikan pada text sink, tetapi ditangkap pada SARIF sink, dan experimental-html merendernya berbasis SVG menggunakan dot
    • pada diagnostic sink SARIF atau HTML, jika cfgs=yes diatur maka pengambilan GCC intermediate representation untuk semua function di semua optimization pass akan diaktifkan
  • Diagnostik GCC dapat merujuk logical location di dalam file XML dan JSON
    • tool sarif-replay menggunakan ini untuk memberikan JSON pointer saat melaporkan issue dari input SARIF
  • Jika GCC_DIAGNOSTICS_LOG diatur di environment, subsystem diagnostik akan mengeluarkan text log ke stderr atau named file
    • ini digunakan untuk melacak keputusan internal seperti kapan tepatnya dan mengapa suatu diagnostic ditolak
  • Jika EXPERIMENTAL_SARIF_SOCKET diatur di environment, GCC akan mencoba terhubung ke socket tersebut saat startup, dan mengirim JSON-RPC notification untuk setiap diagnostic yang terjadi
  • Untuk penulis plugin, framework publish/subscribe ditambahkan untuk mengirim strongly-typed message antara sender dan receiver yang loosely-coupled
    • pada rilis ini, topik yang dapat di-subscribe plugin hanya event start/stop optimization pass pada function tertentu dan event terkait static analyzer
  • GCC diagnostic sink dapat memiliki objek extension dengan hook finalizer, dan plugin dapat menggunakan ini untuk menangkap informasi tambahan ke file output SARIF
  • Di GCC 16, diagnostic machinery telah dirapikan secara besar-besaran, dan seharusnya tidak berdampak pada plugin yang hanya menggunakan diagnostic-core.h
    • maintainer plugin yang menggunakan diagnostik secara lebih kompleks perlu melihat panduan porting
  • Static analyzer menangani dukungan awal untuk C++ Named Return Value Optimization dan exception sehingga bisa digunakan pada contoh C++ sederhana
    • karena masalah scaling, pada rilis ini kemungkinan besar masih sulit digunakan untuk code C++ production
  • -fanalyzer mengasumsikan bahwa external function call tanpa atribut nothrow dapat melempar exception saat -fexceptions aktif
    • opsi baru -fanalyzer-assume-nothrow menonaktifkan asumsi ini
    • ini dimaksudkan untuk menghindari peningkatan warning pada project yang memakai -fexceptions di code C demi interoperabilitas C++, tetapi C API yang digunakan kecil kemungkinannya melempar exception
  • Struktur data representasi user code pada -fanalyzer ditulis ulang agar lebih mudah dipahami dan di-debug, dan lokasi diagnostik sedikit ditingkatkan
    • sebagai gantinya, penggunaan memori analyzer meningkat
  • Struktur data simulasi isi memori pada -fanalyzer diimplementasikan ulang agar lebih cepat dan lebih mudah dirawat
  • analyzer mulai menggunakan machinery value_range milik GCC sehingga menghilangkan beberapa false positive

libgdiagnostics dan masalah yang telah diperbaiki

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Saya ingin menyoroti P2590R2 Explicit lifetime management sebagai fitur implementasi yang seharusnya diadopsi orang, tetapi kemungkinan besar tidak akan banyak dipakai dalam praktik
    Ini ditujukan untuk std::start_lifetime_as, yaitu cara yang bukan UB untuk melakukan type-pun pointer menjadi tipe terstruktur
    Hampir semua kode zero-copy yang menangani buffer I/O eksternal bentuknya kurang lebih seperti reinterpret_cast(buffer.get()), dan itu adalah undefined behavior, tetapi sekarang jika reinterpret_cast diganti dengan start_lifetime_as, itu bukan lagi tindakan yang buruk
    https://en.cppreference.com/cpp/memory/start_lifetime_as

    • Sebenarnya sudah ada cara yang legal untuk melakukannya, dan semua orang seharusnya sudah memakai itu. Caranya adalah dengan melakukan laundering pointer lewat no-op memmove
      Menggunakan reinterpret_cast di sini adalah bug
      start_lifetime_as melakukan satu hal lagi selain memberi nama standar yang rapi pada mantra laundering memori. Secara semantik ia tidak menyentuh memori, sedangkan no-op memmove pada dasarnya memang menyentuh memori. Dalam praktiknya perbedaannya kecil karena compiler bisa melihat bahwa memmove itu no-op dan mengoptimalkannya
    • Jika mengabaikan batasan alignment, itu tergantung pada implementasi read. Jika dari sudut pandang compiler ia sepenuhnya opaque, maka kernel atau network card dan semacamnya sebenarnya yang membangun Foo di dalam buffer itu, sehingga cast tersebut menjadi sepenuhnya sah
      start_lifetime_as berguna ketika lifetime buffer transparan bagi compiler sehingga bisa merusak asumsi aliasing
    • Penjelasan cppreference agak meragukan
      Tampaknya maksudnya T adalah objek baru yang sepenuhnya lengkap, dengan subobject di dalamnya, dan salah satunya bertipe U. U diinisialisasi seperti bit_cast, yang mungkin maksudnya dicast dari bit yang sudah ada di alamat tersebut. Namun obj muncul tanpa definisi, jadi sepertinya harus dimaknai sebagai sesuatu yang berada di alamat yang benar
      Tetapi apa itu E terasa ambigu. Di halaman itu tertulis “E is the lvalue of type U denoting obj”, padahal obj mungkin bertipe seperti char, dan jika sejak awal sudah bertipe U maka bit_cast tidak diperlukan
    • Buffer char memang diizinkan untuk type punning
    • Kode itu bukan hanya buruk, tetapi juga tidak benar karena masalah alignment

  • Sebelum mencarinya barusan, saya tidak tahu kalau jadwal rilis GCC ternyata serutin ini: https://gcc.gnu.org/develop.html

    • Proyek besar sudah lama beralih ke rilis reguler
      Sampai era 90-an orang berpikir bisa membuat rilis besar model waterfall setelah semua fitur yang diinginkan masuk, tetapi saat proyek membesar selalu ada orang yang sedang mengerjakan fitur yang belum siap. Dengan rilis reguler, Anda tetap bisa mengirim rilis ke pelanggan
      Pendekatan ini memaksa developer yang kesiapan fiturnya belum pasti untuk membuat toggle guna mematikan fitur yang belum stabil, dan secara realistis itu mendekati yang terbaik
    • Rilis mayor GCC belakangan ini cukup teratur, dan juga mirip dengan rilis musim semi Fedora, seolah masuk ke ritme yang lebih besar. Petunjuknya adalah Red Hat
    • Itu jadi seperti itu setelah orang-orang Cygnus merapikan proyeknya. Sekarang garisnya berlanjut RedHat→IBM
    • Kalau tidak salah, itu mulai terjadi sejak GCC dikenai GPL3
      Dulu jauh lebih lambat, dan saya menghabiskan terlalu banyak waktu untuk mengakali bug C++ di GCC 2.95
      Fakta bahwa saya masih ingat versi bermasalah itu sendiri sudah mengatakan banyak hal

  • Saya sudah memakainya cukup lama. Debian sid punya paket trunk
    Ada c++26 reflection, jadi saya melakukan beberapa hal ajaib dengan reflection, dan untuk beberapa kasus seperti ser-des hasilnya jauh lebih baik
    Andai saja ekosistemnya punya server LSP

    • Saat menjalankan binary GCC 16 di Debian 12 dan 13, libstd sedang menimbulkan masalah

  • Format yang disebut json pada -fdiagnostics-format= telah dihapus di rilis ini, dan sekarang jika Anda memerlukan diagnostics yang machine-readable dari GCC, mereka menyuruh memakai SARIF
    Tetapi mereka juga mengatakan bahwa diagnostics sekarang bisa dioutput sebagai HTML dengan -fdiagnostics-add-output=experimental-html
    Saya penasaran apa latar belakang keputusan menghapus output JSON sambil menambahkan output HTML

    • SARIF tampaknya seperti JSON dengan skema formal. JSON yang sebelumnya mereka keluarkan tampaknya memakai skema nonstandar buatan sendiri

  • Pertanyaan pemula, saya penasaran apakah GCC memakai LLVM di bagian internalnya, atau punya code generation dan optimization pipeline sendiri. Saya juga penasaran bagaimana levelnya dibanding LLVM

    • GCC tidak memakai LLVM
      Ia mendukung lebih banyak target daripada LLVM, dan dalam kebanyakan kasus menghasilkan executable yang setara atau lebih baik
    • Kalau dijawab ala Wikipedia, seperti yang sudah disebut, GCC jauh lebih tua daripada LLVM
      Menurut Wikipedia, GCC tanggalnya 22 Maret 1987, sedangkan rilis awal LLVM tahun 2003
      Perbedaan besar lainnya adalah lisensi. GCC memakai GPL, LLVM memakai Apache License, jadi kedua proyek itu tidak saling berbagi kode
    • Tidak
    • Jawaban “tidak!” dari yang lain memang benar, tetapi dulu pernah ada plugin GCC yang memakai backend LLVM dari GCC
      Apple memakai llvm-gcc sekitar 2012, saat masa transisi dari GCC ke LLVM, dan itu adalah gabungan front end GCC dengan back end LLVM
      https://dragonegg.llvm.org
    • GCC jauh lebih tua daripada LLVM, dan keduanya tidak berbagi kode

  • Apakah -Ofast masih mengabaikan -fno-fast-math?

  • Selama sekitar 3 bulan terakhir saya sudah mencoba source unstable
    Ada program yang tidak bisa dikompilasi dengan GCC terbaru tetapi berjalan baik dengan GCC lama, jadi untuk saat ini secara keseluruhan gcc 15.x lebih cocok bagi saya
    Meski begitu, kalau Anda melihat lebih dari 3000 program yang dikompilasi, sebagian besar tetap berhasil, dan hanya sebagian yang perlu patch. Patch seperti itu sering bisa ditemukan di LFS/BLFS, dan kalau masalah per kasus diperbaiki dengan sed, biasanya tetap jalan
    Saya harap masalah-masalah itu sudah diperbaiki. Kita semua butuh stabilitas dan sesuatu yang “langsung berfungsi”

    • Apakah Anda sudah mengirimkan laporan bug untuk masalah-masalah itu?