GCC 16 đã được phát hành

 (gcc.gnu.org)
1 điểm bởi GN⁺ 2 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Bản phát hành mới của GNU Compiler Collection đánh dấu một bước chuyển quan trọng khi đổi chuẩn mặc định của C++ sang gnu++20, và không còn xem việc triển khai C++20 là experimental nữa
  • Đã bổ sung các tính năng reflection, contracts, constexpr của C++26, các tính năng C++23, cùng hỗ trợ thư viện C++23·C++26 ở trạng thái experimental; chẩn đoán lỗi template và type trait constraint failure cũng chi tiết hơn với thông báo phân cấp
  • OpenMP và OpenACC đã mở rộng GPU memory allocation, target memset, device memcpy API; các front end Ada·Fortran·Modula-2·Algol 68 cũng được bổ sung tính năng ngôn ngữ mới và trình biên dịch thử nghiệm
  • x86-64 hỗ trợ AMD Zen6, Intel Wildcat Lake, Intel Nova Lake; phía AMD GPU·LoongArch·IBM z Systems·Solaris·Windows cũng được bổ sung các tính năng theo từng mục tiêu và thay đổi ABI
  • Việc loại bỏ định dạng chẩn đoán JSON, tăng cường chẩn đoán SARIF·HTML, cải thiện static analyzer, và bổ sung 37 entrypoint cho libgdiagnostics đã mở rộng đáng kể khả năng tích hợp công cụ và hạ tầng chẩn đoán

Thay đổi về tương thích và cải tiến chung

  • Trên Solaris, int8_t và các kiểu tương tự đã trở thành signed char để tuân thủ chuẩn C99; đây là thay đổi không tương thích
  • Trên Solaris, tùy chọn -pthread không còn định nghĩa sẵn _REENTRANT nữa
  • Định dạng json của -fdiagnostics-format= đã bị loại bỏ; nên dùng SARIF cho chẩn đoán mà máy có thể đọc được
  • Link-Time Optimization nay xử lý tốt hơn các câu lệnh asm cấp cao nhất với -flto-toplevel-asm-heuristics
  • Speculative devirtualization xử lý được các lời gọi hàm gián tiếp thông thường và hỗ trợ suy đoán nhiều hơn một đích
  • Vectorizer đã linh hoạt hơn trong việc nhận diện loop-level parallelism của reduction, đồng thời hỗ trợ vector hóa các vòng lặp không biết trước số lần lặp và uncounted loop
    • Cũng hỗ trợ peeling để căn chỉnh cho vector length agnostic loop dùng masking, mutual peeling for alignment, và loại bỏ phép tính vector induction trong các vòng lặp early break
  • GCC Command Options và option index đã được chỉnh sửa để bao quát nhiều tùy chọn từng bị bỏ sót trước đây
  • Tài liệu GCC-specific attributes đã được hiện đại hóa để nhấn mạnh hơn cú pháp attribute chuẩn được cho phép trong mọi dialect C/C++ mà GCC hỗ trợ
    • Tài liệu về attribute đã được tái cấu trúc để giảm lặp lại, và bổ sung attribute index mới
    • Tài liệu về file spec của parameter và option đã được chuyển sang GCC internals manual dành cho nhà phát triển GCC và người dùng cần cấu hình GCC tùy biến

Các thay đổi chính theo ngôn ngữ

  • OpenMP và OpenACC

    • Hỗ trợ cấp phát bộ nhớ của OpenMP được tăng cường: pinned trait allocator và ompx_gnu_pinned_mem_alloc sẽ sử dụng CUDA API khi khả dụng, giúp cải thiện hiệu năng truy cập bộ nhớ đó trên GPU Nvidia
    • GNU extension ompx_gnu_managed_mem_alloc allocator và ompx_gnu_managed_mem_space cấp phát bộ nhớ mà device có thể truy cập từ host
      • Device vẫn có thể truy cập ngay cả khi unified-shared memory không được hỗ trợ, và ngay cả trên các hệ thống nơi toàn bộ host memory đều device-accessible, hành vi page-migration vẫn có thể khác với các loại bộ nhớ khác
    • OpenMP 5.0 bổ sung hỗ trợ declare mapper ở mức hạn chế cho C/C++, còn mệnh đề uses_allocators bao gồm cả thay đổi cú pháp của OpenMP 5.2 lẫn hỗ trợ dấu chấm phẩy của OpenMP 6.0
    • OpenMP 5.1 bổ sung hỗ trợ ban đầu cho iterator modifier của map clause và target update construct trong C/C++
    • OpenMP 5.2 hỗ trợ begin declare variant directive trong C/C++
    • OpenMP 6.0 bổ sung các API routine omp_target_memset và omp_target_memset_async, đồng thời cũng có thể dùng assumptions clause no_openmp_constructs
    • Các directive và clause bị deprecated trong OpenMP 5.0, 5.1, 5.2 mặc định sẽ phát sinh deprecation warning, và có thể tắt bằng -Wno-deprecated-openmp
      • Warning cũng xuất hiện khi dùng named constant hoặc API routine đã deprecated, và có thể tắt bằng -Wno-deprecated-declarations
    • OpenACC bổ sung các API routine acc_memcpy_device và acc_memcpy_device_async cho C/C++/Fortran
    • wait directive của OpenACC 3.0 chấp nhận if clause, còn các API routine Fortran acc_attach và acc_detach của OpenACC 3.3 bổ sung cho các counterpart C/C++ của OpenACC 2.6
    • Trong OpenACC 3.4, việc dùng named constant PARAMETER trong Fortran data clause được cả đặc tả và GCC cho phép, nhưng trong GCC nó không ảnh hưởng tới hành vi lúc biên dịch hay khi chạy

  • Ada, Fortran, Modula-2, Algol 68

    • Các GNAT extension của Ada bổ sung Constructor và Destructor, cung cấp cơ chế construction/finalization khác biệt đáng kể so với Ada tiêu chuẩn
    • Ada bổ sung các aspect Implicit with, Structural Generic instantiation, Extended_Access
      • Extended_Access có thể được chỉ định cho general access type declaration trỏ tới unconstrained array subtype, thay đổi biểu diễn con trỏ và giúp Ada dễ liên kết với foreign language trên vùng nhớ không do Ada cấp phát
    • Ada có thể dùng VAST cho mục đích debug compiler thông qua -gnatd_V hoặc -gnatd_W ở chế độ verbose, đồng thời semantic analysis của Ada 2022 Reduction Expressions, Ada.Containers.Bounded_Indefinite_Holders, việc triển khai accessibility rule và hỗ trợ Android cũng được cải thiện
    • Fortran xử lý coarray dùng native shared memory multithreading trên máy single node và tính năng TEAM của Fortran 2018
    • Hỗ trợ Fortran 2003 Parameterized Derived Types được cải thiện, việc xử lý LEN parameter hiện hoạt động nhưng vẫn cần thay đổi representation trong tương lai theo PR82649
    • Fortran 2018 hỗ trợ mở rộng IMPORT statement, REDUCE intrinsic và GENERIC statement mới
    • Fortran 2023 hỗ trợ các hàm lượng giác bổ sung như sinpi, intrinsic subroutine split, và c_f_pointer nhận optional lower bound làm đối số
    • Tùy chọn -fexternal-blas64 sẽ gọi external BLAS routine từ MATMUL với đối số integer 64-bit, và chỉ có hiệu lực trên hệ thống 64-bit khi áp dụng -ffrontend-optimize
    • Modula-2 đưa ra spelling hint khi xử lý import list, tên module và symbol trong nested scope, đồng thời giới thiệu cách triển khai wide set mới và library module M2WIDESET
      • Thay đổi đối với wide set làm thay đổi ABI và có thể gây link-time error với các object file từ phiên bản GCC cũ hơn
    • Thư viện mặc định của Modula-2 được bổ sung binary dictionary module BinDict, nhiều module có thêm các procedure Write và WriteLn, và khả năng truy cập external library module được cải thiện qua tùy chọn -fm2-pathname-root=
    • GCC bao gồm ga68, một compiler Algol 68 ở mức thử nghiệm, với mục tiêu triển khai Revised Report cùng errata đã được IFIP WG2.1 Algol 68 Support subcommittee phê duyệt
      • Một số GNU extension và POSIX prelude cũng được triển khai; thông tin về ngôn ngữ xem tại Algol 68 website, còn thông tin về front end xem tại wiki

C++ và libstdc++

  • Phiên bản ngôn ngữ mặc định cho biên dịch C++ đã được đổi từ -std=gnu++17 sang -std=gnu++20
    • Mã phụ thuộc vào các chuẩn C++ cũ cần thêm -std= vào build flag hoặc porting mã, tham khảo porting notes
    • Hỗ trợ C++20 modules vẫn ở trạng thái experimental và phải bật bằng -fmodules
  • Nhiều tính năng C++26 đã được triển khai, gồm reflection, annotations for reflection, base class subobject splicing, function parameter reflection, contracts, constexpr exceptions, constexpr virtual inheritance, v.v.
    • P2996R13 Reflection được bật bằng -std=c++26 -freflection
    • Một phần của P2686R4 được hỗ trợ một phần; structured binding có thể dùng constexpr nhưng tham chiếu tới constexpr automatic variable vẫn chưa được cho phép
  • Các tính năng C++23 như P2036R3, P2590R2, P2246R1 đã được triển khai
  • Thông báo lỗi C++ có cấu trúc phân cấp trong các vấn đề như liên quan đến template, và dùng thụt lề cùng bullet point để biểu thị message nesting
  • Hỗ trợ C++20 modules ở trạng thái experimental sẽ thêm tùy chọn --compile-std-module để build header unit <bits/stdc++.h> cùng các module std, std.compat trước khi compile source file
    • Nếu header unit <bits/stdc++.h> đã được build, #include của standard library header có thể import sẽ được chuyển một cách trong suốt thành import <bits/stdc++.h>
    • Nhiều bug đã được báo cáo đã được sửa
  • Constraint failure diagnostics của type trait trong standard library sẽ cho biết chi tiết hơn vì sao is_constructible_v, is_invocable_v v.v. trả về false
  • Trên các target mà libstdc++ hỗ trợ 128-bit integer, std::is_integral<__int128> và các trait tương tự sẽ luôn là true
    • Trước đây trong GNU dialect thì là true, nhưng trong strict dialect thì không phải vậy
  • P0952R2: A new specification for std::generate_canonical đã được triển khai cho mọi mode bị ảnh hưởng từ C++11 trở đi, tác động đến output có thể quan sát được
    • Có thể khôi phục hành vi trước đây bằng định nghĩa _GLIBCXX_USE_OLD_GENERATE_CANONICAL
  • ABI của std::variant đã được cập nhật để nhất quán với mode C++20 trở lên, và ảnh hưởng đến class layout trong một số mode C++17 nhất định
    • Có thể khôi phục hành vi trước đây bằng định nghĩa _GLIBCXX_USE_VARIANT_CXX17_OLD_ABI, và ảnh hưởng này chỉ áp dụng cho mode C++17
  • Việc thực thi std::regex đã được viết lại để dùng stack trên heap thay vì system stack, giúp tránh stack overflow khi matching các string lớn hơn
  • Việc triển khai C++20 không còn là experimental nữa, và std::chrono::current_zone() hoạt động trên Windows
  • Vì hỗ trợ C++20 trước GCC 16 là experimental, nên các chương trình dùng component C++20 cần được xem là không tương thích với các bản phát hành cũ hơn
    • Các đối tượng có thay đổi ABI gồm hàm waiting/notifying của <atomic>, kiểu semaphore của <semaphore>, synchronization của <syncstream>, args của std::format và biểu diễn của std::formatter, std::partial_ordering trong <compare>, cùng biểu diễn của một số adaptor trong <ranges>
  • Hỗ trợ thư viện C++23 ở trạng thái experimental bao gồm std::mdspan, ranges::starts_with, ranges::ends_with, ranges::shift_left, ranges::shift_right, std::allocator_traits::allocate_at_least
  • Hỗ trợ thư viện C++26 ở trạng thái experimental bao gồm std::simd, std::inplace_vector, std::optional<T&>, std::copyable_function, std::function_ref, std::indirect, std::polymorphic, std::owner_equal cho shared pointer, header <debugging>, v.v.

Hỗ trợ target và hệ điều hành

  • IA-32/x86-64

    • CPU dựa trên AMD Zen6 được hỗ trợ với -march=znver6, đồng thời bật thêm AVX512_BMM, AVX_NE_CONVERT, AVX_IFMA, AVX_VNNI_INT8, AVX512_FP16 bên trên các ISA extension đã được kích hoạt cho Zen5
    • Khi bật hỗ trợ AVX512 và tuning là znver4, znver5, znver6, auto-vectorization sẽ thử dùng masked vector epilog để giảm kích thước mã và cải thiện hiệu năng
    • Intel Wildcat Lake được hỗ trợ với -march=wildcatlake, Intel Nova Lake được hỗ trợ với -march=novalake
      • -march=novalake sẽ bật thêm APX_F, AVX10.1, AVX10.2, PREFETCHI bên trên các ISA extension dựa trên Panther Lake
    • Từ GCC 16, việc bật AMX-TRANSPOSE, USER_MSR, CLDEMOTE, KL, WIDEKL, PREFETCHI trong nhiều switch -march= đã bị loại bỏ
    • -mavx10.1-256, -mavx10.1-512, -mevex512 đã bị loại bỏ, và cảnh báo thay đổi hành vi của -mavx10.1 cũng biến mất
    • Hỗ trợ AMX-TRANSPOSE đã bị loại bỏ trong GCC 16, và GCC không còn chấp nhận -mamx-transpose
    • Tùy chọn configure mới --enable-x86-64-mfentry bật -mfentry, sử dụng __fentry__ thay cho mcount cho profiling trên x86-64, và được bật mặc định trên target glibc
    • --enable-tls=DIALECT hỗ trợ điều khiển TLS dialect mặc định, giá trị mặc định là gnu, và các giá trị cho phép là gnu và gnu2 cho TLS descriptor

  • AMD GPU, LoongArch, IBM z Systems

    • Trên AMD GPU offloading, overhead khi khởi chạy OpenMP target region và OpenACC compute region đã giảm đáng kể
    • Đã bổ sung hỗ trợ thử nghiệm cho thiết bị AMD Instinct MI300 gfx942, đồng thời bao gồm gfx950 tương thích với generic gfx9-4-generic trong đa số trường hợp
    • Bộ multilib build mặc định cho AMD GPU nay chuyển thành gfx908, gfx90a, gfx9-generic, gfx9-4-generic, gfx10-3-generic, gfx11-generic
      • Nếu có generic arch, multilib cho thiết bị cụ thể sẽ không còn được build mặc định nữa
      • Generic architecture yêu cầu ROCm 6.4.0 trở lên
      • Bộ multilib mặc định mới yêu cầu assembler và linker từ LLVM 20 trở lên
      • Tham khảo AMD installation notes và configuration notes của GCC
    • LoongArch hỗ trợ các kiểu số nguyên chính xác theo bit như _BitInt (N) và unsigned _BitInt (N)
    • LoongArch hỗ trợ Function Multi-Versioning thông qua attribute target_clones, cho phép tạo các phiên bản hàm theo từng tính năng CPU và tự động chọn phiên bản tối ưu lúc runtime
    • Đã bổ sung hỗ trợ cho kiến trúc LoongArch32, bao gồm ABI mặc định ilp32d cùng các ABI ilp32f, ilp32s
      • Hỗ trợ cả phiên bản 32-bit tiêu chuẩn LA32 và phiên bản 32-bit rút gọn LA32R, cho phép sinh mã target 32-bit cho ứng dụng nhúng
      • Tính năng này phụ thuộc vào hỗ trợ của Binutils và glibc
    • S/390, System z, IBM z Systems hỗ trợ kiểu số nguyên chính xác theo bit và kiểu số thực dấu chấm động _Float16
      • Các phép toán _Float16 được thực hiện bằng phần mềm hoặc bằng instruction float
    • Với họ S/390, global stack protector để hỗ trợ runtime patching cho việc nạp địa chỉ canary của Linux kernel đã được bổ sung qua -mstack-protector-guard=global, đồng thời cũng thêm -mstack-protector-guard-record
    • Hỗ trợ -m31 trên họ S/390 đã bị deprecate và sẽ bị loại bỏ trong các bản phát hành tương lai

  • Hệ điều hành

    • Solaris hỗ trợ thuận tiện việc tạo Solaris CTF, tức Compact C Type Format, thông qua tùy chọn -gsctf
    • Windows hỗ trợ native TLS, tức Thread-Local Storage
      • Để kích hoạt, cần chỉ định --enable-tls khi configure và cần GNU binutils 2.44 trở lên

Chẩn đoán, plugin, phân tích tĩnh

  • GCC hỗ trợ xuất chẩn đoán định dạng HTML với -fdiagnostics-add-output=experimental-html
  • Đầu ra SARIF tuân theo dump directory, và trong ví dụ đầu ra build-dir/foo.o, GCC 16 ghi SARIF vào build-dir/foo.c.sarif
    • GCC 15 trong cùng ví dụ đã ghi vào foo.c.sarif
  • Đầu ra SARIF ghi nhận logical location nesting và trong nhiều trường hợp bao gồm thuộc tính description trong đối tượng fix
  • Thuộc tính kinds của SARIF threadFlowLocation mới có thêm các giá trị throw, catch, unwind, setjmp, longjmp để biểu diễn control flow phi tiêu chuẩn
  • GCC diagnostics có thể đính kèm directed graph, và cũng có thể báo cáo global directed graph
    • graph bị bỏ qua ở text sink nhưng được ghi nhận ở SARIF sink, còn experimental-html dùng dot để render dưới dạng SVG
    • Khi đặt cfgs=yes trên SARIF hoặc HTML diagnostic sink, việc ghi nhận GCC intermediate representation cho mọi function của mọi optimization pass sẽ được bật
  • GCC diagnostics có thể tham chiếu logical location bên trong file XML và JSON
    • Công cụ sarif-replay dùng điều này để cung cấp JSON pointer khi báo cáo issue của đầu vào SARIF
  • Nếu GCC_DIAGNOSTICS_LOG được đặt trong environment, diagnostic subsystem sẽ xuất text log ra stderr hoặc file được chỉ định
    • Dùng để theo dõi các quyết định nội bộ như chẩn đoán bị loại bỏ chính xác khi nào và vì sao
  • Nếu EXPERIMENTAL_SARIF_SOCKET được đặt trong environment, GCC sẽ cố gắng kết nối tới socket đó khi khởi động và gửi JSON-RPC notification cho mọi chẩn đoán phát sinh
  • Một framework publish/subscribe đã được thêm vào cho tác giả plugin để truyền các message strongly-typed giữa sender và receiver loosely-coupled
    • Trong bản phát hành này, các topic mà plugin có thể subscribe chỉ gồm event bắt đầu/kết thúc optimization pass của function cụ thể và các event liên quan đến static analyzer
  • GCC diagnostic sink có thể có đối tượng extension với hook finalizer, và plugin có thể dùng nó để ghi thêm thông tin vào file đầu ra SARIF
  • Trong GCC 16, diagnostic machinery đã được dọn dẹp lớn, và sẽ không ảnh hưởng tới các plugin chỉ dùng diagnostic-core.h
    • Maintainer của các plugin dùng diagnostics phức tạp hơn cần tham khảo porting guide
  • Static analyzer xử lý hỗ trợ ban đầu cho C++ Named Return Value Optimization và exception, nên có thể dùng với các ví dụ C++ đơn giản
    • Do vấn đề về khả năng mở rộng, ở bản phát hành này rất có thể vẫn khó dùng cho mã C++ production
  • -fanalyzer giả định rằng external function call không có thuộc tính nothrow có thể ném exception khi -fexceptions được bật
    • Tùy chọn mới -fanalyzer-assume-nothrow sẽ tắt giả định này
    • Mục đích là để tránh số lượng warning tăng lên trong các project dùng -fexceptions cho mã C nhằm tương thích với C++, nhưng API C đang dùng ít có khả năng ném exception
  • Cấu trúc dữ liệu biểu diễn user code của -fanalyzer đã được viết lại để dễ hiểu và debug hơn, đồng thời vị trí chẩn đoán cũng được cải thiện đôi chút
    • Đổi lại, mức sử dụng bộ nhớ của analyzer tăng lên
  • Cấu trúc dữ liệu mô phỏng nội dung bộ nhớ của -fanalyzer đã được triển khai lại để nhanh hơn và dễ bảo trì hơn
  • Analyzer đã bắt đầu sử dụng machinery value_range của GCC để loại bỏ một số false positive

libgdiagnostics và các vấn đề đã được sửa

Bài viết liên quan

1 bình luận

 
GN⁺ 2 giờ trước
Ý kiến trên Hacker News

  • Tôi muốn chỉ ra P2590R2 Explicit lifetime management như một tính năng được triển khai mà mọi người nên áp dụng nhưng có lẽ trên thực tế sẽ không được dùng nhiều
    Đây là thứ dành cho std::start_lifetime_as, là cách không phải UB để type-pun con trỏ sang kiểu có cấu trúc
    Gần như mọi đoạn mã zero-copy xử lý bộ đệm I/O bên ngoài đều trông đại loại như reinterpret_cast(buffer.get()), và đó là undefined behavior; giờ chỉ cần thay reinterpret_cast bằng start_lifetime_as thì không còn là làm điều xấu nữa
    https://en.cppreference.com/cpp/memory/start_lifetime_as

    • Thực ra đã có một cách hợp pháp để làm việc này, và ai cũng lẽ ra nên dùng nó rồi. Đó là cách laundering con trỏ bằng no-op memmove
      Dùng reinterpret_cast ở đây là một lỗi
      start_lifetime_as còn làm thêm một việc ngoài chuyện đặt cho phép thuật memory laundering một cái tên chuẩn gọn gàng. Về mặt ngữ nghĩa nó không đụng vào bộ nhớ, trong khi no-op memmove về bản chất vẫn động tới bộ nhớ. Trên thực tế khác biệt không lớn vì compiler có thể nhận ra memmove là no-op và tối ưu đi
    • Nếu bỏ qua ràng buộc alignment thì điều đó còn tùy vào cách read được triển khai. Nếu từ góc nhìn của compiler nó hoàn toàn opaque, thì những thứ như kernel hay card mạng thực sự đang dựng một Foo trong bộ đệm đó, nên phép cast trở nên hoàn toàn chính đáng
      start_lifetime_as hữu ích khi lifetime của bộ đệm là minh bạch với compiler và có thể phá vỡ các giả định aliasing
    • Phần giải thích trên cppreference có vẻ hơi đáng ngờ
      Có vẻ như ý họ là T là một đối tượng mới hoàn chỉnh, có các subobject bên trong, và một trong số đó có kiểu U. U được khởi tạo như kiểu bit_cast, có lẽ họ định nói là cast từ các bit đã có sẵn ở địa chỉ đó. Nhưng obj lại xuất hiện mà không được định nghĩa, nên có lẽ phải hiểu nó là một thứ gì đó nằm ở đúng địa chỉ
      Tuy nhiên E là gì thì vẫn mơ hồ. Trang đó ghi “E is the lvalue of type U denoting obj”, nhưng obj có lẽ là kiểu như char, và nếu nó vốn đã là kiểu U thì đâu cần bit_cast
    • Type punning với bộ đệm char là được phép
    • Đoạn mã đó không chỉ xấu mà còn không đúng vì vấn đề alignment

  • Trước khi vừa tra thử thì tôi không biết lịch phát hành GCC lại đều đặn như vậy: https://gcc.gnu.org/develop.html

    • Các dự án lớn từ lâu đã chuyển sang phát hành định kỳ
      Cho đến tận thập niên 90, người ta vẫn nghĩ có thể làm những bản phát hành lớn kiểu waterfall, nhét vào mọi tính năng mong muốn, nhưng khi dự án đủ lớn thì sẽ luôn có ai đó đang làm một tính năng chưa sẵn sàng. Làm phát hành định kỳ thì ít nhất vẫn có thể giao bản phát hành cho khách hàng
      Cách này buộc những lập trình viên có tính năng chưa chắc kịp phải tạo công tắc tắt các tính năng chưa ổn định, và thực tế đó gần như là phương án tốt nhất
    • Các bản phát hành lớn gần đây của GCC khá đều đặn, cũng na ná bản phát hành mùa xuân của Fedora, và có vẻ khớp trong một nhịp lớn hơn. Gợi ý là Red Hat
    • Mọi thứ thành ra như vậy từ sau khi những người của Cygnus tái cơ cấu dự án. Giờ thì mạch đó là RedHat→IBM
    • Nếu nhớ không nhầm thì là từ sau khi GCC chuyển sang GPL3
      Trước đây chậm hơn nhiều, và tôi đã tốn quá nhiều thời gian để lách lỗi C++ của GCC 2.95
      Chỉ riêng việc tôi vẫn còn nhớ chính xác phiên bản gây rắc rối đó đã nói lên rất nhiều điều

  • Tôi đã dùng nó được một thời gian rồi. Debian sid có gói trunk
    Nó có c++26 reflection, nên tôi đang làm một số trò khá ảo với reflection, và trong vài trường hợp như ser-des thì tốt hơn hẳn
    Chỉ mong trong hệ sinh thái có máy chủ LSP

    • Khi chạy binary GCC 16 trên Debian 12 và 13, libstd đang gây ra vấn đề

  • Cái gọi là định dạng json của -fdiagnostics-format= đã bị loại bỏ trong bản phát hành này, và họ nói rằng nếu cần diagnostics machine-readable từ GCC thì hãy dùng SARIF
    Nhưng họ cũng nói rằng giờ có thể xuất diagnostics ra HTML bằng -fdiagnostics-add-output=experimental-html
    Tôi khá tò mò về lý do đằng sau quyết định bỏ đầu ra JSON nhưng lại thêm đầu ra HTML

    • SARIF trông giống JSON có schema chính thức. Có vẻ JSON mà họ xuất trước đây là một schema tự chế, không chuẩn

  • Câu hỏi hơi gà, nhưng tôi muốn biết liệu GCC có dùng LLVM ở đâu đó bên trong không, hay nó có pipeline tối ưu hóa và sinh mã riêng hoàn toàn. Tôi cũng muốn biết nếu so với LLVM thì nó ở mức nào

    • GCC không dùng LLVM
      Nó hỗ trợ nhiều target hơn LLVM, và trong đa số trường hợp tạo ra executable tương đương hoặc tốt hơn
    • Nếu trả lời kiểu Wikipedia thì, như người khác đã nói, GCC lâu đời hơn LLVM rất nhiều
      Theo Wikipedia, GCC là ngày 22 tháng 3 năm 1987, còn bản phát hành đầu tiên của LLVM là năm 2003
      Một khác biệt lớn nữa là giấy phép. GCC dùng GPL, LLVM dùng Apache License, nên hai dự án không chia sẻ mã nguồn với nhau
    • Không dùng
    • Những câu “không!” ở các câu trả lời khác là đúng, nhưng ngày xưa từng có plugin GCC dùng LLVM backend trong GCC
      Apple từng dùng llvm-gcc vào khoảng năm 2012, thời kỳ họ chuyển từ GCC sang LLVM, và đó là tổ hợp GCC front end với LLVM back end
      https://dragonegg.llvm.org
    • GCC lâu đời hơn LLVM rất nhiều, và hai bên không chia sẻ mã nguồn

  • -Ofast giờ vẫn còn bỏ qua -fno-fast-math à?

  • Tôi đã thử dùng mã nguồn unstable trong khoảng 3 tháng vừa qua
    Có những chương trình không biên dịch được với GCC gần đây nhưng lại chạy tốt với GCC cũ hơn, nên hiện tại nhìn chung gcc 15.x hợp với tôi hơn
    Dù vậy, nếu xét việc biên dịch hơn 3000 chương trình thì phần lớn vẫn ổn, chỉ một số ít cần vá. Những bản vá đó thường có thể tìm thấy trong LFS/BLFS, và sửa từng lỗi bằng sed thì đa phần cũng chạy được
    Tôi mong những vấn đề đó đã được sửa. Tất cả chúng ta đều cần sự ổn định và cảm giác “cứ thế là chạy”

    • Bạn đã gửi báo cáo lỗi cho những vấn đề đó chưa?