public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/97182] New: Add support for targets that only define SYS_futex_time64 and not SYS_futex
@ 2020-09-23 17:23 redi at gcc dot gnu.org
2020-09-23 17:28 ` [Bug libstdc++/97182] " redi at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2020-09-23 17:23 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex
2020-09-23 17:23 [Bug libstdc++/97182] New: Add support for targets that only define SYS_futex_time64 and not SYS_futex redi at gcc dot gnu.org
@ 2020-09-23 17:28 ` redi at gcc dot gnu.org
2020-09-23 18:47 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2020-09-23 17:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex
2020-09-23 17:23 [Bug libstdc++/97182] New: Add support for targets that only define SYS_futex_time64 and not SYS_futex redi at gcc dot gnu.org
2020-09-23 17:28 ` [Bug libstdc++/97182] " redi at gcc dot gnu.org
@ 2020-09-23 18:47 ` jakub at gcc dot gnu.org
2020-09-23 19:27 ` wilson at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-23 18:47 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex
2020-09-23 17:23 [Bug libstdc++/97182] New: Add support for targets that only define SYS_futex_time64 and not SYS_futex redi at gcc dot gnu.org
2020-09-23 17:28 ` [Bug libstdc++/97182] " redi at gcc dot gnu.org
2020-09-23 18:47 ` jakub at gcc dot gnu.org
@ 2020-09-23 19:27 ` wilson at gcc dot gnu.org
2020-09-23 19:35 ` jakub at gcc dot gnu.org
2020-09-24 23:09 ` wilson at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: wilson at gcc dot gnu.org @ 2020-09-23 19:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex
2020-09-23 17:23 [Bug libstdc++/97182] New: Add support for targets that only define SYS_futex_time64 and not SYS_futex redi at gcc dot gnu.org
` (2 preceding siblings ...)
2020-09-23 19:27 ` wilson at gcc dot gnu.org
@ 2020-09-23 19:35 ` jakub at gcc dot gnu.org
2020-09-24 23:09 ` wilson at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-23 19:35 UTC (permalink / raw)
To: gcc-bugs
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*.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/97182] Add support for targets that only define SYS_futex_time64 and not SYS_futex
2020-09-23 17:23 [Bug libstdc++/97182] New: Add support for targets that only define SYS_futex_time64 and not SYS_futex redi at gcc dot gnu.org
` (3 preceding siblings ...)
2020-09-23 19:35 ` jakub at gcc dot gnu.org
@ 2020-09-24 23:09 ` wilson at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: wilson at gcc dot gnu.org @ 2020-09-24 23:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-09-24 23:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-23 17:23 [Bug libstdc++/97182] New: Add support for targets that only define SYS_futex_time64 and not SYS_futex redi at gcc dot gnu.org
2020-09-23 17:28 ` [Bug libstdc++/97182] " redi at gcc dot gnu.org
2020-09-23 18:47 ` jakub at gcc dot gnu.org
2020-09-23 19:27 ` wilson at gcc dot gnu.org
2020-09-23 19:35 ` jakub at gcc dot gnu.org
2020-09-24 23:09 ` wilson at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).