This is the mail archive of the
libstdc++@gcc.gnu.org
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: Rainer Orth <ro at cebitec dot uni-bielefeld dot de>, 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>
- Date: Sat, 25 May 2013 02:32:24 +0100
- Subject: Re: [patch] Default to --enable-libstdcxx-time=auto
- References: <yddk3mopxat dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE> <20130524132117 dot GT1377 at tucnak dot redhat dot com> <ydd38tcpkks dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE> <20130524134056 dot GU1377 at tucnak dot redhat dot com> <CAH6eHdScm3PHL_HVJU7rKywvDoPwgeU_OJ1kDAS12y-v5RJbwg at mail dot gmail dot com> <20130524140748 dot GV1377 at tucnak dot redhat dot com> <20130524141622 dot GW1377 at tucnak dot redhat dot com> <CAH6eHdRZPUrsF=kh-mQRT4kj7Khq9YrEYSj3Rf7jRLtpgZuiAg at mail dot gmail dot com> <20130524150357 dot GX1377 at tucnak dot redhat dot com> <CAH6eHdTSVSj5M0ptSOmW9Bj86Kyjw-=KtUZh3-uiRAA9O-h1DQ at mail dot gmail dot com> <20130524201004 dot GE1377 at tucnak dot redhat dot com>
On 24 May 2013 21:10, Jakub Jelinek wrote:
>
> So, there is a minor issue that what is std::chrono::steady_clock has
> changed, if you say use it as a function parameter, it will mangle
> differently before/after. Guess not that big a deal, after all, C++11
> support is still experimental, right?
Right.
> But the more important issue is that std::chrono::system_clock broke,
> code compiled against the old headers will assume
> std::chrono::system_clock::duration is microseconds resolution on Linux,
> while code compiled against the new headers will assume it is in
> nanoseconds resolution. That is because of:
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
> typedef chrono::nanoseconds duration;
> #elif defined(_GLIBCXX_USE_GETTIMEOFDAY)
> typedef chrono::microseconds duration;
> #else
> typedef chrono::seconds duration;
> #endif
>
> Thus, I'm afraid we can't ABI compatibly change either of these macros,
> unless we e.g. keep old std::chrono::system_clock as is and introduce
> std::chrono::__whatever::system_clock or whatever, that will be typedefed
> as std::chrono::system_clock.
Or use the new ABI attribute so the "new" system_clock mangles
differently to the "old" system_clock.
I prefer to break it though - if we're going to paint ourselves into a
corner and insist on compatibility with semi-functional previous
releases we should stop calling it "experimental". Alternatively,
while we still call it experimental, let's fix it properly and get it
right.
> Is it a big issue if system_clock will have
> just old resolution (usec) and =auto code is reverted to only tweak
> steady_clock (aka. _GLIBCXX_USE_CLOCK_MONOTONIC) (then for 4.8 the change
> would be just to drop
> ac_has_clock_realtime=yes
> line from if test x"$ac_has_clock_monotonic_syscall" = x"yes"; then)?
IMHO yes, that's a big issue. I believe most users are more
interested in system_clock than in steady_clock, and we should provide
a nanosecond-resolution system_clock if the OS supports it.
> Ugh, C++ and ABI doesn't go well together...
Yeah, this stuff's hard. But I hope we can get a stable ABI for 4.9,
even if it's incompatible with previous releases.