This is the mail archive of the
mailing list for the libstdc++ project.
Re: [patch] Default to --enable-libstdcxx-time=auto
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, Paolo Carlini <paolo dot carlini at oracle dot com>, "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Date: Thu, 23 May 2013 13:04:36 +0100
- Subject: Re: [patch] Default to --enable-libstdcxx-time=auto
- References: <519C942D dot 6050100 at oracle dot com> <CAH6eHdTjdi75WSwKYfdGBtOeQwbsSvMbzzxo24qofMexFSmETA at mail dot gmail dot com> <519C9AF5 dot 8090300 at oracle dot com> <519C9CBC dot 4050606 at oracle dot com> <519C9E3B dot 60609 at oracle dot com> <CAH6eHdRXAK1r0g7u+50RobAxTo=6DJsvRZzo75m7x+5ir3opKQ at mail dot gmail dot com> <CAH6eHdS5gqa2nfNJfC0zy9FJq4amgjJbtUuEASM_Qw0GZ8-9aA at mail dot gmail dot com> <20130522111543 dot GG1377 at tucnak dot redhat dot com> <CAH6eHdR0MocSNhvD_xRfhcYiaGugs8P++oJnTyy5DSAiDh=hPg at mail dot gmail dot com> <20130522123540 dot GH1377 at tucnak dot redhat dot com> <20130523102827 dot GV1377 at tucnak dot redhat dot com>
On 23 May 2013 11:28, Jakub Jelinek wrote:
> On Wed, May 22, 2013 at 02:35:40PM +0200, Jakub Jelinek wrote:
>> non-steady clock instead. Or, have you also considered just using
>> for this routine
>> #if _GLIBCXX_HAS_SYS_SYSCALL_H
>> #include <sys/syscall.h>
>> #if defined (SYS_clock_gettime) && defined (CLOCK_MONOTONIC)
>> syscall (SYS_clock_gettime, CLOCK_MONOTONIC, &tp);
>> if clock_gettime isn't available, at least on Linux?
>> The implementation seems to ignore ENOSYS from clock_gettime, so ignoring it
>> even here wouldn't make it worse.
> I mean something like completely untested following patch, then it would
> be pretty much enabled for all non-prehistoric Linux builds (there is a risk
> of it returning garbage on 2.4.x and earlier kernels, if you compile it on
> something that defines __NR_clock_gettime in their headers, but the exact
> same risk is if you do the same with --enable-libstdcxx-time=rt
> (clock_gettime wrapper in glibc will return -1/ENOSYS in that case, so will
> the syscall, but chrono.cc seems to ignore that return value)).
> 2.6+ kernels (2004-ish and later or so) should support CLOCK_MONOTONIC just
This looks great to me, thanks.
> fine. Of course, there is a possibility of fallback, at least for the
> clock_gettime/syscall CLOCK_RUNTIME or gettimeofday, if they fail, fall
> through into the time case, and for CLOCK_MONOTONIC perhaps just lie and
> return time as well, shouldn't really affect almost anybody.
We should consider doing that yes, but it's less urgent.
> Still, the ABI question is there, would we want to apply to 4.8.1 (can we
> get agreement on that RSN, this is pretty much the only blocker for 4.8.1
> rc2 right now) and, would we export that symbol as @@GLIBCXX_3.4.18 (with
> all trunk @@GLIBCXX_3.4.18 symbols moved to 3.4.19) and add @GLIBCXX_3.4.17
> alias for backwards compatibility with those that configured with
> --enable-libstdcxx-time=rt ?
I like that plan.