On Mon, 7 Sept 2026 at 16:50, Jakub Jelinek <[email protected]> wrote: > > On Mon, Sep 07, 2026 at 11:31:21PM +0800, Jakit Liang wrote: > > I did some additional investigation and can reproduce the parsing > > failure outside CLion, using Debian's standalone clangd 19.1.7 in WSL2. > > > > The important condition is that clangd is given the GCC bfloat16 feature > > macro, as happens in the CLion configuration. The following minimal > > predefines file is sufficient: > > > > ``` > > #define __BFLT16_MANT_DIG__ 8 > > #define __BFLT16_DIG__ 2 > > ``` > > gcc has a few hundreds of predefined macros, each predefined macro > means something, if you incorrectly define any of them, the same or other > programs can misbehave. > There is no point trying to allow incorrectly redefining just one of those > macros. The predefined macros are usually in implementation namespace (or > even mandated by the standard, see the __cpp* macros) and changing them > makes the program invalid.
Right. And even if we change the use of the literal in <format> and use our internal typedef instead (which would be mostly harmless), it won't help for the use of a literal in bits/c++config which cannot be changed. > > > Thus CLion is not required to trigger the parser diagnostic. In CLion, > > the same condition arises because its clangd integration supplies a > > snapshot of the selected GCC 14.2.0 toolchain's predefined macros via > > an `-imacros` file, including `__BFLT16_DIG__=2`. > > Then CLion is broken. Right. Why is it trying to pretend that bfloat16 is supported when it isn't?
