Hi Jakub,
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
```
With a source file containing:
```
#include <format>
int main() { }
```
and this compile command:
```
/usr/bin/c++ -std=gnu++23 \
-imacros /tmp/bf16-clangd-repro/gcc-predefines.h \
-c /tmp/bf16-clangd-repro/test.cc
```
`clangd-19 --check` consistently reports:
```
[invalid_suffix_constant] Line 1: in included file:
invalid suffix 'bf16' on floating constant
```
The same happens in `-std=gnu++20` mode.
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`.
Without that macro, the bfloat16-specific code is preprocessed out, so a
normal standalone clangd invocation does not show the diagnostic. This
explains why the issue can otherwise appear dependent on CLion.
I understand that the proposed `__bf16` change is not
target-independent and does not establish a correct libstdc++ fix. I am
providing the above reproduction to clarify the source of the clangd
diagnostic.
Thanks,
Jakit
Jakit Liang <[email protected]> 于2026年9月7日周一 23:02写道：
>
> I see.
>
> My understanding is that GCC's implementation is internally consistent
> and valid when compiled by GCC itself. CLion/clangd injects GCC feature
> macros into a clangd parser that does not support the corresponding
> features, creating an inconsistent translation environment.
>
> Separately, and one day if GCC wished to reduce dependencies on such
> tooling in the
> future, it could consider providing a target-independent internal
> bfloat16 type mechanism that does not depend on deducing the type from a
> literal. However, my current patch does not achieve that.
>
> Sincerely,
> Jakit
>
> Jakub Jelinek <[email protected]> 于2026年9月7日周一 22:59写道：
> >
> > On Mon, Sep 07, 2026 at 10:53:04PM +0800, Jakit Liang wrote:
> > > Thus the `__BFLT16_DIG__`-guarded code is visible to clangd because
> > > CLion injects the predefined macros collected from the selected GCC
> > > toolchain. The same JetBrains clangd run standalone with an ordinary
> >
> > Then just don't do it, if CLion (whatever it is) does that always,
> > ask it to be fixed, otherwise don't configure it that way.
> >
> > > GCC-style compile command, without CLion's injected `-imacros` file,
> > > does not define `__BFLT16_DIG__` and does not reach this code.
> > >
> > > So the issue is a mismatch: clangd is given GCC's bfloat16 capability
> > > macros but does not recognize the corresponding `bf16` literal suffix.
> > >
> > > Separately, I understand your point that `__bf16` cannot be assumed to
> > > be the type of `0.0bf16` on every target. My proposed change to
> > > `c++config` was checked on x86_64.
> > >
> > > And maybe the previous commit is better?
> >
> > No, libstdc++ shouldn't be changed to cope with bad configuration.
> > Whatever is predefining the macros when it actually isn't supported
> > is lying to the compiler.
> >
> > Jakub
> >
