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 >
