On Mon, 31 Jan 2022 at 22:45, Ron Olson <tachoknight(a)gmail.com> wrote:
Hey all,
I’m troubleshooting an issue and came up with this sample program:
https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 13, on Rawhide,
won’t compile that program, while on Fedora 35 it does.
The reason why is that on Rawhide, stdatomic.h exists under /usr/include/c++/12 while it
does not exist on 35, so clang uses its built-in stdatomic per
https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations.
But that's about C, not C++.
If it uses its internal version, the sample program compiles fine.
Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 202002L”, so
that means C++2b or later, not C++20. This seems to create a problem for clang which,
since the file is present, wants to use it, but since it’s effectively empty due to the
#ifdef, compiling of the sample program fails.
Is it possible to disable clang’s use of the header file as a flag? I’ve been unable to
find anything like that, and obviously renaming the header is out of the question. Also,
is it correct to the setting stdatomic.h to only be used by c++2b?
Yes, that's 100% correct.
Clang is at fault here. <stdatomic.h> does not exist in C++ up to and
including the current C++20 standard, so Clang should not assume it's
present or usable.
In C++23 there is now a <stdatomic.h> header in the C++ library for
compatibility. That's what I added to GCC, and that's what Clang is
now picking up.
Why is C++ code in Clang using a C header that isn't part of C++?