Why is there no libatomic default implementation using gthr.h?

Jonathan Wakely jwakely.gcc@gmail.com
Mon Dec 19 12:41:52 GMT 2022


On Mon, 19 Dec 2022 at 11:19, Sebastian Huber wrote:
>
> Hello,
>
> I would like to fix the -fprofile-update=atomic implementation so that
> it works on all targets. Currently, it works only on targets with 64-bit
> atomic operations in hardware (and some special cases). I tried to fix
> it like this:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608620.html
>
> The problem with this patch is that it falls back to use functions
> provided by libatomic. The libatomic is currently not supported on all
> targets, for example:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77466
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378
>
> Why is there no libatomic default implementation using gthr.h?
>
> The C++ library already depends on gthr.h and installs the headers in
> "bits/gthr.h" etc. For this the libstdc++-v3 configure/Makefile
> duplicates some logic from libgcc. Why is the gthr.h stuff not installed
> by libgcc itself?

Because libstdc++ installs a modified copy of the libgcc headers. Are
those modifications suitable for all users of the libgcc version of
the header?

>
> In libatomic, the POSIX implementation could be easily rewritten to use
> the gthr interface.

Why would that need gthr.h to be installed? The use of gthreads should
be an internal implementation detail, not exposed as part of the
libatomic API.


>
> Any objections to do the following?
>
> 1. Install gthr.h to "bits/gthr.h" by libgcc (including the other gthr
> headers).
>
> 2. Remove the gthr configure/Makefile support from libstdc++-v3.

I would be concerned by these two steps.


> 3. Use gthr as the default implementation of libatomic.

I have no objection to doing this, but I don't see why you need to
touch libstdc++ to do it. Just make libatomic create its own copy of
gthr.h (if a fallback gthreads-based implementation is actually
needed) and compile that locally in the libatomic build dir. That
shouldn't need changes to libgcc or libstdc++, should it?


More information about the Gcc mailing list