Well, yes and no. The code I linked to in the pastebin is what demonstrates the issue. The code in question is Apple’s libdispatch which I package separately as well as part of Swift. In that situation they’re using a C++ file that uses the underlying primitives in stdatomic in macros for their own higher-level functions, thus why stdatomic is ultimately being invoked.
On 1 Feb 2022, at 3:26, Jonathan Wakely wrote: > On Tue, 1 Feb 2022 at 09:15, Jonathan Wakely <jwak...@redhat.com> wrote: >> >> On Mon, 31 Jan 2022 at 22:45, Ron Olson <tachokni...@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++? > > I think I misread, this isn't code in Clang, this is your code and > you're just using Clang, right? > > So then you can fix your code fairly easily. > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
