From patchwork Thu May 23 10:28:27 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 245873 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 4F8012C0090 for ; Thu, 23 May 2013 20:29:01 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=R4mqdx79C5uszb9qG ScAjBkJgXM3JIqdcDcpIseGNJ6EXKR9q6k6n6WD0YYVX0YKpiODYIKbCzN3RIz6Q FtsIMG8hzWyWEcFOqtzpJ0E4jV130Mw4VuUQYJYcCFTzG10C8g2n2xFvyaOgs3NT 4BDM9kNtawjbe3uFYVIYvyyJw8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=jMYOjgsDPG/m6ysSARos0tA j+AY=; b=vm5fq69Zc8rxehGjFR0K9qB8bdJhndS4tKemYbhe9pyjegAElY5VYyJ 6dTU2iVxD6FvE37DVWwNaHhin0vIZ3wSaI7VfvjwUdYYTfj8NL84tqz9zb6Vz4et FwNN7LyKXj3aZS1NmWerXJEDa281gziapxt47MpcRUkhscpf92O8= Received: (qmail 23808 invoked by alias); 23 May 2013 10:28:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 23773 invoked by uid 89); 23 May 2013 10:28:40 -0000 X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS, TW_CX, TW_DC autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 23 May 2013 10:28:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4NASabq019619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 May 2013 06:28:36 -0400 Received: from zalov.cz (vpn-60-240.rdu2.redhat.com [10.10.60.240]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r4NASYIN009075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 06:28:35 -0400 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.cz (8.14.5/8.14.5) with ESMTP id r4NASVBc023853; Thu, 23 May 2013 12:28:32 +0200 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r4NASTb5023852; Thu, 23 May 2013 12:28:29 +0200 Date: Thu, 23 May 2013 12:28:27 +0200 From: Jakub Jelinek To: Jonathan Wakely , Benjamin Kosnik Cc: Paolo Carlini , libstdc++ , gcc-patches , Rainer Orth Subject: Re: [patch] Default to --enable-libstdcxx-time=auto Message-ID: <20130523102827.GV1377@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <519C942D.6050100@oracle.com> <519C9AF5.8090300@oracle.com> <519C9CBC.4050606@oracle.com> <519C9E3B.60609@oracle.com> <20130522111543.GG1377@tucnak.redhat.com> <20130522123540.GH1377@tucnak.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130522123540.GH1377@tucnak.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 > #endif > > #if defined (SYS_clock_gettime) && defined (CLOCK_MONOTONIC) > syscall (SYS_clock_gettime, CLOCK_MONOTONIC, &tp); > #endif > 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 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. 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 ? Jakub --- libstdc++-v3/src/c++11/chrono.cc.jj 2013-03-16 08:07:57.000000000 +0100 +++ libstdc++-v3/src/c++11/chrono.cc 2013-05-23 12:08:04.165686015 +0200 @@ -32,6 +32,9 @@ defined(_GLIBCXX_USE_GETTIMEOFDAY) #include #endif +#ifdef _GLIBCXX_USE_CLOCK_MONOTONIC_SYSCALL +#include +#endif namespace std _GLIBCXX_VISIBILITY(default) { @@ -47,7 +50,11 @@ namespace std _GLIBCXX_VISIBILITY(defaul #ifdef _GLIBCXX_USE_CLOCK_REALTIME timespec tp; // -EINVAL, -EFAULT +#ifdef _GLIBCXX_USE_CLOCK_REALTIME_SYSCALL + syscall(SYS_clock_gettime, CLOCK_REALTIME, &tp); +#else clock_gettime(CLOCK_REALTIME, &tp); +#endif return time_point(duration(chrono::seconds(tp.tv_sec) + chrono::nanoseconds(tp.tv_nsec))); #elif defined(_GLIBCXX_USE_GETTIMEOFDAY) @@ -70,7 +77,11 @@ namespace std _GLIBCXX_VISIBILITY(defaul { timespec tp; // -EINVAL, -EFAULT +#ifdef _GLIBCXX_USE_CLOCK_REALTIME_SYSCALL + syscall(SYS_clock_gettime, CLOCK_MONOTONIC, &tp); +#else clock_gettime(CLOCK_MONOTONIC, &tp); +#endif return time_point(duration(chrono::seconds(tp.tv_sec) + chrono::nanoseconds(tp.tv_nsec))); } --- libstdc++-v3/acinclude.m4.jj 2013-04-10 08:32:08.000000000 +0200 +++ libstdc++-v3/acinclude.m4 2013-05-23 12:03:29.626014601 +0200 @@ -1274,6 +1274,28 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME] fi fi + if test x"$ac_has_clock_monotonic" != x"yes"; then + AC_MSG_CHECKING([for clock_gettime syscall]) + AC_TRY_COMPILE( + [#include + #include + #include + ], + [#if _POSIX_TIMERS > 0 && defined(_POSIX_MONOTONIC_CLOCK) + timespec tp; + #endif + syscall(SYS_clock_gettime, CLOCK_MONOTONIC, &tp); + syscall(SYS_clock_gettime, CLOCK_REALTIME, &tp); + ], [ac_has_clock_monotonic_syscall=yes], [ac_has_clock_monotonic_syscall=no]) + AC_MSG_RESULT($ac_has_clock_monotonic_syscall) + if test x"$ac_has_clock_monotonic_syscall" = x"yes"; then + AC_DEFINE(_GLIBCXX_USE_CLOCK_MONOTONIC_SYSCALL, 1, + [ Defined if clock_gettime syscall has monotonic clock support. ]) + ac_has_clock_monotonic=yes + ac_has_clock_realtime=yes + fi + fi + if test x"$ac_has_clock_monotonic" = x"yes"; then AC_DEFINE(_GLIBCXX_USE_CLOCK_MONOTONIC, 1, [ Defined if clock_gettime has monotonic clock support. ])