Re: Re: [committed] libstdc++: Allow Clang to use <stdatomic.h> before C++23

[Jonathan Wakely <jwakely@redhat.com>]

On Wed, 4 Jan 2023 at 16:57, Jonathan Wakely wrote:
>
> On Wed, 4 Jan 2023 at 16:31, Alexander Hans wrote:
> >
> > Hi Jonathan,
>
> Hi,
>
> > I'm trying to integrate gcc 12.2.0 in a Bazel build and have an issue
> > compiling some C code that includes stdatomic.h. Instead of using the C
> > stdatomic.h, it includes the C++23 one, which there does nothing. Your
>
> It should be impossible for C code to include that header.
>
>
> > patch mentioned in the subject seems to address a similar issue.
> > However, in my case, it doesn't fix the issue, because when using gcc,
> > #if __clang__ is not true. When I change the line to be an
> > unconditional #else instead of the #else if, things work as expected.
> >
> > Why did you put the if __clang__? I can imagine you wanted to address
> > this one usecase when people use clang++, but wouldn't the same issue
> > occur for g++?
>
> With Clang, including the C version of <stdatomic.h> actually works,
> because clang++ supports the _Atomic qualifier even in C++ code. So
> there is non-portable C++17 and C++20 code out there already which
> includes <stdatomic.h> and expects it to work (as long as it's only
> compiled with Clang).
>
> My change to the libstdc++ <stdatomic.h> allows that code to keep
> compiling when using Clang. Such code never compiled with g++ at any
> time, so there is no need to support it. It never worked anyway.
>
> > I suppose in a usual system-installation, the C++23
> > file is not part of the builtin include paths when compiling C code.
>
> Right. Not just a system-installation. In any GCC installation, the
> libstdc++ headers are in a C++-specific directory that the C compiler
> never looks in.
>
> > However, when having the toolchain managed by Bazel, I can only give
> > a single set of include directories [1]:
> >
> > > cxx_builtin_include_directories
> > > [...]
> > > We currently use the C++ paths also for C compilation, which is
> > > safe as long as there are no name clashes between C++ and C header
> > > files.
> >
> > I can work around this by patching my local version of C++23's
> > stdatomic.h, but I suppose other Bazel users will face that issue as
> > well, since the assumption of no name clashes is not true anymore.
>
> Then Bazel is broken. The assumption that "there are no name clashes
> between C++ and C header files" has never been true.

Why does Bazel even need to know those directories? It should not be
adding them for compiling C code nor for compiling C++ code, because
GCC does that automatically (and gets it right).


>
> I suppose we could support that silliness like this:
>
> --- a/libstdc++-v3/include/c_compatibility/stdatomic.h
> +++ b/libstdc++-v3/include/c_compatibility/stdatomic.h
> @@ -124,7 +124,7 @@ using std::atomic_flag_clear_explicit;
> using std::atomic_thread_fence;
> using std::atomic_signal_fence;
>
> -#elif defined __clang__
> +#elif defined __clang__ || !defined __cplusplus
> # include_next <stdatomic.h>
> #endif // C++23
> #endif // _GLIBCXX_STDATOMIC_H
>
> But I don't really like having to patch libstdc++ to support broken tools.
>
>
>
> > I wasn't sure if posting to the mailing list was appropriate. Feel
> > free to CC to the list!
>
> Yes, this should be on the mailing list, CC'd.
>
>
> >
> >
> > Thanks and cheers!
> >
> > Alex
> >
> >
> > [1] https://bazel.build/rules/lib/cc_common#create_cc_toolchain_config_info
> >