#toolchain
5 posts tagged #toolchain.
C++26 reflection runs on a compiler you already have
The received wisdom is that trying P2996 means the Bloomberg clang fork. It does not. GCC 16.1 has shipped reflection since April behind -freflection, using the standard <meta> header, and it runs the same code. The two implementations do disagree about what display_string_of prints.
CUDA lock-in is real, and it is not in the C++
The usual account says CUDA's warp primitives and template layers weld your code to Nvidia hardware. Compile the same kernel through a third-party toolchain for an AMD GPU and the warp shuffle comes out as native cross-lane instructions with the addition fused in. What binds you is the toolchain and the licence, not the language.
C++29 mode is open, and the compilers already disagree
LLVM 23.1 shipped with -std=c++2d, a mode for the standard after C++26, and GCC trunk has one too. Both report __cplusplus as 202700. They do not agree about C++26 itself: GCC says 202603, which is the ratified value, and clang still says 202400.
LLVM 23.1 shipped, and one of its changes is silent
Clang 23.1 landed on 25 August with partial expansion statements, modules dependency discovery, and a batch of core-issue fixes. It also elides more dead stores than 22 did, which is the one change that alters behaviour without saying anything at build time.
GCC 16.2 is out, LLVM 23.1 is nearly there, MSVC is still finishing C++23
GCC 16.2 shipped on 7 August with more than a hundred regression fixes and no new features. LLVM 23.1 reached its third release candidate on 12 August and has not shipped. MSVC has no C++26 date. If you want to write C++26 today, the practical answer remains GCC, and this is where each toolchain actually stands.