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?
