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

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

[Sebastian Huber]

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?

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

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.

3. Use gthr as the default implementation of libatomic.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

[Jonathan Wakely]

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?

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

[Sebastian Huber]

On 19/12/2022 13:41, Jonathan Wakely wrote:
>> 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?

Yes, this would also work. I can probably duplicate the gthr 
configure/Makefile stuff from libstdc++ for this.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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

[LIU Hao]

[-- Attachment #1.1: Type: text/plain, Size: 706 bytes --]

在 2022/12/19 20:45, Sebastian Huber 写道:
> On 19/12/2022 13:41, Jonathan Wakely wrote:
>>> 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?
> 
> Yes, this would also work. I can probably duplicate the gthr configure/Makefile stuff from libstdc++ 
> for this.
> 

Would you please do the same to libgomp too?

-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]