[Bug libstdc++/97182] New: Add support for targets that only define SYS_futex_time64 and not SYS_futex

[Bug libstdc++/97182] New: Add support for targets that only define SYS_futex_time64 and not SYS_futex

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97182

            Bug ID: 97182
           Summary: Add support for targets that only define
                    SYS_futex_time64 and not SYS_futex
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

I'm told this affects 32-bit RISC-V.

If SYS_futex isn't defined then libstdc++ won't use futexes, even though they
might be available via the new SYS_futex_time64 syscall instead.

The autoconf checks for SYS_futex should be updated to look for
SYS_futex_time64 as well, and then src/c++11/futex.cc needs to use the best one
available, and possibly have a fallback for the case where both were defined at
configure time but one returns ENOSYS at runtime. Ugh.

This probably also affects our uses of SYS_clock_gettime in both
src/c++11/futex.cc and src/c++11/chrono.cc

[Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97182

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The consequence of not using SYS_futex is that we use a mutex + condition
variable for some synchronization, which is obviously suboptimal if futexes are
actually available.

Changing to use a futex would be an ABI change for targets currently not using
it, because it affects the layout of the shared state used by std::promise and
std::future. That probably needs coordination with target maintainers.

[Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97182

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |wilson at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess riscv*-linux* support needs to be added to libgomp too then...

[Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97182

--- Comment #3 from Jim Wilson <wilson at gcc dot gnu.org> ---
libgomp works on riscv64-linux.  It would only be riscv32-linux that is broken.

The riscv32 support was only just recently added to FSF glibc, and hasn't
appeared in a release yet, so arguably, there is no ABI break for riscv32-linux
if we can fix this before the gcc-11 release, as that is the first one that can
officially support riscv32-linux.  Unofficialy we have embedded linux distros
with riscv32-linux but they should be able to tolerate ABI breaks, particularly
since we never guaranteed that the riscv32-linux ABI was stable.

This will be a problem for other 32-bit targets though when they enable 64-bit
time_t support.

[Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97182

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jim Wilson from comment #3)
> libgomp works on riscv64-linux.  It would only be riscv32-linux that is
> broken.
> 
> The riscv32 support was only just recently added to FSF glibc, and hasn't
> appeared in a release yet, so arguably, there is no ABI break for
> riscv32-linux if we can fix this before the gcc-11 release, as that is the
> first one that can officially support riscv32-linux.  Unofficialy we have
> embedded linux distros with riscv32-linux but they should be able to
> tolerate ABI breaks, particularly since we never guaranteed that the
> riscv32-linux ABI was stable.

For riscv64 works perhaps, but does it work efficiently?
I mean, I don't see it mentioned anywhere in libgomp/configure.tgt, which means
it won't set config_path to include linux and therefore will not use futexes
directly and will instead use pthread*.

[Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97182

--- Comment #5 from Jim Wilson <wilson at gcc dot gnu.org> ---
I see that a riscv64-linux libgomp.so has mutex calls and no obvious futex
calls.  Though I find it a little curious that futex support isn't
auto-detected.  There is already config/futex.m4 to detect futex support, and
libstdc++ is using it.  So yes, we are missing riscv*-linux futex support in
libgomp.