https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jonathan Wakely <r...@gcc.gnu.org>: https://gcc.gnu.org/g:1e3e6c700f04fe6992b9077541e434172c1cbdae commit r11-5114-g1e3e6c700f04fe6992b9077541e434172c1cbdae Author: Jonathan Wakely <jwak...@redhat.com> Date: Tue Nov 17 16:13:02 2020 +0000 libstdc++: Revert changes for SYS_clock_gettime64 [PR 93421] As discussed in the PR, it's incredibly unlikely that a system that needs to use the SYS_clock_gettime syscall (e.g. glibc 2.16 or older) is going to define the SYS_clock_gettime64 macro. Ancient systems that need to use the syscall aren't going to have time64 support. This reverts the recent changes to try and make clock_gettime syscalls be compatible with systems that have been updated for time64 (those changes were wrong anyway as they misspelled the SYS_clock_gettime64 macro). The changes for futex syscalls are retained, because we still use them on modern systems that might be using time64. To ensure that the clock_gettime syscalls are safe, configure will fail if SYS_clock_gettime is needed, and SYS_clock_gettime64 is also defined (but to a distinct value from SYS_clock_gettime), and the tv_sec member of timespec is larger than long. This means we will be unable to build on a hypothetical system where we need the time32 version of SYS_clock_gettime but where userspace is using a time64 struct timespec. In the unlikely event that this failure is triggered on any real systems, we can fix it later. But we probably won't need to. libstdc++-v3/ChangeLog: PR libstdc++/93421 * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Fail if struct timespec isn't compatible with SYS_clock_gettime. * configure: Regenerate. * src/c++11/chrono.cc: Revert changes for time64 compatibility. Add static_assert instead. * src/c++11/futex.cc (_M_futex_wait_until_steady): Assume SYS_clock_gettime can use struct timespec.
