#clang
5 posts tagged #clang.
C++26 tightened unevaluated strings, and GCC did half of it
P2361R6 makes encoding prefixes and numeric escapes ill-formed in the strings that only exist at compile time. GCC 16.1 rejects the prefixes and accepts the escapes; Clang 22.1 rejects both. The same source compiles on one and fails on the other, which is worth knowing before you rely on either.
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.
A C++26 structured binding that GCC and Clang disagree about
C++26 lets a structured binding declaration be the condition of an if. GCC 16.1 and Clang 22.1 both implement it and both agree on ordinary structs. Put a tuple-protocol type in the condition and evaluate it at compile time, and GCC rejects the program while Clang accepts it. The reproducer is twenty lines and needs no library.
Clang's lifetimebound warns about a copy, and that is the problem
The lifetimebound attribute lets -Wdangling see through a function call, which is how clang catches a string_view into a temporary. It has no conditional form, so a function that returns a copy on some instantiations and a reference on others has to pick between missing real dangles and warning about correct code. A proposal on the LLVM forum wants to close that gap.