* src/c++11/compatibility-chrono.cc (steady_clock::now()): If
!_GLIBCXX_USE_GETTIMEOFDAY perform conversion inline instead of
calling non-existent from_time_t.
Tested x86_64-linux, committed to trunk and the 4.8 branch.
Steve, trunk should build OK now, thanks for testing
On 28 May 2013 18:39, Steve Ellcey wrote:
> On Tue, 2013-05-28 at 17:29 +0100, Jonathan Wakely wrote:
>
>>
>> I don't think it was my patch that broke it, because
>> compatibility-chrono.cc didn't exist when my patch went in :-)
>
> Sorry about that, I guess I got lost in a maze of twisty checkins
On Tue, 2013-05-28 at 17:29 +0100, Jonathan Wakely wrote:
>
> I don't think it was my patch that broke it, because
> compatibility-chrono.cc didn't exist when my patch went in :-)
Sorry about that, I guess I got lost in a maze of twisty checkins.
> Does this help?
>
> --- src/c++11/compatibil
On Tue, May 28, 2013 at 05:29:38PM +0100, Jonathan Wakely wrote:
> > This has broken the mips-mti-elf build for me,
>
> I don't think it was my patch that broke it, because
> compatibility-chrono.cc didn't exist when my patch went in :-)
Yeah, this is from the latest change set.
> Does this h
On 28 May 2013 17:10, Steve Ellcey wrote:
> On Wed, 2013-05-22 at 09:14 +0100, Jonathan Wakely wrote:
>> This alters the configure script to enable C++11 thread library
>> features based on targets that are known to support the features,
>> rather than based on link tests which are disabled by defa
On Wed, 2013-05-22 at 09:14 +0100, Jonathan Wakely wrote:
> This alters the configure script to enable C++11 thread library
> features based on targets that are known to support the features,
> rather than based on link tests which are disabled by default. With
> Glibc 2.17 this enables a nanoseco
On Tue, May 28, 2013 at 11:41:50AM +0200, Rainer Orth wrote:
> Fixed by the following patch, tested with the appropriate runtest
> invocation on sparc-sun-solaris2.11.
>
> Ok for mainline and 4.8 branch?
Yes, thanks.
> 2013-05-28 Rainer Orth
>
> * config/abi/post/solaris2.10/sparcv9/ba
Jakub Jelinek writes:
> On Sun, May 26, 2013 at 07:58:09AM +0200, Jakub Jelinek wrote:
>> On Sat, May 25, 2013 at 04:07:11PM -0700, Benjamin De Kosnik wrote:
>> >
>> > > Looks good to me.
>> >
>> > Great, trunk patch in.
>> >
>> > > Will you prepare corresponding patch for the 4.8
>> > > bra
On Sun, May 26, 2013 at 07:58:09AM +0200, Jakub Jelinek wrote:
> On Sat, May 25, 2013 at 04:07:11PM -0700, Benjamin De Kosnik wrote:
> >
> > > Looks good to me.
> >
> > Great, trunk patch in.
> >
> > > Will you prepare corresponding patch for the 4.8
> > > branch too (I guess it should be pret
On Sat, May 25, 2013 at 04:07:11PM -0700, Benjamin De Kosnik wrote:
>
> > Looks good to me.
>
> Great, trunk patch in.
>
> > Will you prepare corresponding patch for the 4.8
> > branch too (I guess it should be pretty much the same, not sure if it
> > should keep using typedef system_clock ste
> Looks good to me.
Great, trunk patch in.
> Will you prepare corresponding patch for the 4.8
> branch too (I guess it should be pretty much the same, not sure if it
> should keep using typedef system_clock steady_clock as before for the
> non-MONOTONIC configuration, or if it should just do t
On Sat, May 25, 2013 at 11:56:31AM -0700, Benjamin De Kosnik wrote:
> I'm tempted to check this patch into trunk. Jakub?
Looks good to me. Will you prepare corresponding patch for the 4.8 branch
too (I guess it should be pretty much the same, not sure if it should keep
using typedef system_clock
> > It scraps the renaming/aliasing approach, and just creates a
> > compatibility-chrono.cc that mimics the default configuration in
> > 4.8.0.
>
> Yeah, I think that is reasonable, with one nit, see below.
Cool, incorporated.
> > Users who specially-configured a build with --enable-libstdcxx
On Sat, May 25, 2013 at 08:21:46AM +0200, Jakub Jelinek wrote:
> In this _V2 inline namespace, I think we should change that:
> struct system_clock
> {
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
> typedef chrono::nanoseconds duration;
> #elif defined(_GLIBCXX_U
On Fri, May 24, 2013 at 08:26:32PM -0700, Benjamin De Kosnik wrote:
> It scraps the renaming/aliasing approach, and just creates a
> compatibility-chrono.cc that mimics the default configuration in 4.8.0.
Yeah, I think that is reasonable, with one nit, see below.
> Users who specially-configured
> 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, ditto, yes.
> But the more importa
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?
Benjamin De Kosnik writes:
>>> I get the
>> > following testsuite regressions on Solaris 10/x86:
>> >
>> > FAIL: 30_threads/async/54297.cc (test for excess errors)
>> > WARNING: 30_threads/async/54297.cc compilation failed to produce
>> > executable FAIL: 30_threads/condition_variable_any/53830.c
>> I get the
> > following testsuite regressions on Solaris 10/x86:
> >
> > FAIL: 30_threads/async/54297.cc (test for excess errors)
> > WARNING: 30_threads/async/54297.cc compilation failed to produce
> > executable FAIL: 30_threads/condition_variable_any/53830.cc (test
> > for excess errors) WARN
On Fri, May 24, 2013 at 04:22:43PM +0100, Jonathan Wakely wrote:
> On 24 May 2013 16:03, Jakub Jelinek wrote:
> >
> > So, adjusted patches attached, ok for trunk/4.8 if they pass
> > bootstrap/regtest?
>
> Yes, they're OK - thanks for sorting it out.
Note, I've already committed the patches, but
On 24 May 2013 16:03, Jakub Jelinek wrote:
>
> So, adjusted patches attached, ok for trunk/4.8 if they pass
> bootstrap/regtest?
Yes, they're OK - thanks for sorting it out.
Jakub Jelinek writes:
> So, adjusted patches attached, ok for trunk/4.8 if they pass
> bootstrap/regtest? Guess Rainer will need to on top of that adjust
> Solaris baseline_symbols.txt files.
I meant to look into that, but usually I only update the baselines for
x.y.0 releases, not micro releas
On Fri, May 24, 2013 at 03:29:43PM +0100, Jonathan Wakely wrote:
> >> in the latter). And there is no conversion in between the two.
> >>
> >> Perhaps I'd have to do something like:
> >> return time_point(system_clock::now().time_since_epoch());
> >> ? Can try that.
> >
> > Ah, but the duration
On 24 May 2013 15:16, Jakub Jelinek wrote:
> On Fri, May 24, 2013 at 04:07:48PM +0200, Jakub Jelinek wrote:
>> On Fri, May 24, 2013 at 02:56:24PM +0100, Jonathan Wakely wrote:
>> > > Jonathan/Benjamin, could you please review the patch in the mean time,
>> > > so that if it works well for Rainer,
On Fri, May 24, 2013 at 04:07:48PM +0200, Jakub Jelinek wrote:
> On Fri, May 24, 2013 at 02:56:24PM +0100, Jonathan Wakely wrote:
> > > Jonathan/Benjamin, could you please review the patch in the mean time,
> > > so that if it works well for Rainer, it can be applied immediately and
> > > 4.8.1-rc2
On 24 May 2013 15:07, Jakub Jelinek wrote:
> On Fri, May 24, 2013 at 02:56:24PM +0100, Jonathan Wakely wrote:
>> > Jonathan/Benjamin, could you please review the patch in the mean time,
>> > so that if it works well for Rainer, it can be applied immediately and
>> > 4.8.1-rc2 rolled, even during t
On Fri, May 24, 2013 at 02:56:24PM +0100, Jonathan Wakely wrote:
> > Jonathan/Benjamin, could you please review the patch in the mean time,
> > so that if it works well for Rainer, it can be applied immediately and
> > 4.8.1-rc2 rolled, even during the weekend?
>
>
> In the fallback for steady_cl
On 24 May 2013 14:40, Jakub Jelinek wrote:
>
> Note that for 4.8.1 this is kind of urgent, because it is blocking 4.8.1-rc2
> and thus also 4.8.1 release, so the sooner this gets resolved, the better.
Sorry about that, I didn't realise the trunk change would affect 4.8.1
> Jonathan/Benjamin, coul
Jakub Jelinek writes:
> On Fri, May 24, 2013 at 03:35:15PM +0200, Rainer Orth wrote:
>> > I've posted today wouldn't work well on Solaris?
>>
>> It should work on the 4.8 branch (I'll include it in my bootstraps this
>> weekend), but on mainline the failures due to missing nanosleep/-lrt
>> will
On Fri, May 24, 2013 at 03:35:15PM +0200, Rainer Orth wrote:
> > I've posted today wouldn't work well on Solaris?
>
> It should work on the 4.8 branch (I'll include it in my bootstraps this
> weekend), but on mainline the failures due to missing nanosleep/-lrt
> will remain.
Thanks. Please make
Jakub Jelinek writes:
>> It occured to me that there might be a far less intrusive option to still
>> allow a Solaris backport: instead of going the libstdc++.spec route
>> (which I still think is the correct way forward), statically handle -lrt
>> addition in g++spec.c, controlled by a macro def
On Fri, May 24, 2013 at 11:00:26AM +0200, Rainer Orth wrote:
> Jakub Jelinek writes:
>
> > On Thu, May 23, 2013 at 11:54:05PM +0200, Rainer Orth wrote:
> >> > Agreed, that seems the best course of action if that's an option.
> >>
> >> I just remembered that we aren't there yet even on mainline:
Jakub Jelinek writes:
> On Thu, May 23, 2013 at 11:54:05PM +0200, Rainer Orth wrote:
>> > Agreed, that seems the best course of action if that's an option.
>>
>> I just remembered that we aren't there yet even on mainline:
>>
>> * This snippet
>>
>> http://gcc.gnu.org/ml/gcc-patches/2013-05/
On Fri, May 24, 2013 at 09:57:05AM +0200, Jakub Jelinek wrote:
> Thus, what about this version (just slightly modified, headers remain the
> same, but we export _ZNSt6chrono12steady_clock3nowEv@@GLIBCXX_3.4.19
> even if monotonic clock isn't supported, it will just be work the same as
> _ZNSt6chron
2013/5/24 Jakub Jelinek :
> So, let's talk about other options, is constexpr/const on
> std::chrono::steady_clock::is_steady
> required by the standard (as in, could we export
> _ZNSt6chrono12steady_clock9is_steadyE@@GLIBCXX_3.4.19
> and let the library say which case it is, it would be constexpr w
Jonathan Wakely writes:
> On 23 May 2013 21:56, Rainer Orth wrote:
>>
>> Right, it only got enable by defaulting --enable-libstdcxx-time to auto.
>
> I think it would have been enabled previously with
> --enable-libstdcxx-time=rt, but it wasn't tested and so didn't make it
> into the linker scrip
On 23 May 2013 21:56, Rainer Orth wrote:
>
> Right, it only got enable by defaulting --enable-libstdcxx-time to auto.
I think it would have been enabled previously with
--enable-libstdcxx-time=rt, but it wasn't tested and so didn't make it
into the linker script at the same time as the GNU symbol
On Thu, May 23, 2013 at 11:54:05PM +0200, Rainer Orth wrote:
> > Agreed, that seems the best course of action if that's an option.
>
> I just remembered that we aren't there yet even on mainline:
>
> * This snippet
>
> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01255.html
>
> is necessary
Rainer Orth writes:
> Jakub Jelinek writes:
>
>> On Thu, May 23, 2013 at 10:56:25PM +0200, Rainer Orth wrote:
>>> >> I think std::chrono::steady_clock::now() needs to be protected with
>>> >> !(__sun__ && __svr4__) in GLIBCXX_3.4.17 since it only became available
>>> >> by default with Jonathan'
Jakub Jelinek writes:
> On Thu, May 23, 2013 at 10:56:25PM +0200, Rainer Orth wrote:
>> >> I think std::chrono::steady_clock::now() needs to be protected with
>> >> !(__sun__ && __svr4__) in GLIBCXX_3.4.17 since it only became available
>> >> by default with Jonathan's patch.
>> >
>> > Ah, I see,
On Thu, May 23, 2013 at 10:56:25PM +0200, Rainer Orth wrote:
> >> I think std::chrono::steady_clock::now() needs to be protected with
> >> !(__sun__ && __svr4__) in GLIBCXX_3.4.17 since it only became available
> >> by default with Jonathan's patch.
> >
> > Ah, I see, gnu.ver has some
> > #ifdef HA
Jakub Jelinek writes:
> On Thu, May 23, 2013 at 10:45:32PM +0200, Rainer Orth wrote:
>> Jakub Jelinek writes:
>>
>> > On Thu, May 23, 2013 at 04:02:18PM +0200, Jakub Jelinek wrote:
>> >> So, here is an untested 4.8 branch patch. The @GLIBCXX_3.4.17 +
>> >> @@GLIBCXX_3.4.19 stuff gets ugly, I a
On Thu, May 23, 2013 at 10:45:32PM +0200, Rainer Orth wrote:
> Jakub Jelinek writes:
>
> > On Thu, May 23, 2013 at 04:02:18PM +0200, Jakub Jelinek wrote:
> >> So, here is an untested 4.8 branch patch. The @GLIBCXX_3.4.17 +
> >> @@GLIBCXX_3.4.19 stuff gets ugly, I admit, but don't have other solu
Jakub Jelinek writes:
> On Thu, May 23, 2013 at 04:02:18PM +0200, Jakub Jelinek wrote:
>> So, here is an untested 4.8 branch patch. The @GLIBCXX_3.4.17 +
>> @@GLIBCXX_3.4.19 stuff gets ugly, I admit, but don't have other solution.
>> Tested just that it compiles/links, abi list looks good and ab
On Thu, May 23, 2013 at 04:02:18PM +0200, Jakub Jelinek wrote:
> So, here is an untested 4.8 branch patch. The @GLIBCXX_3.4.17 +
> @@GLIBCXX_3.4.19 stuff gets ugly, I admit, but don't have other solution.
> Tested just that it compiles/links, abi list looks good and abi.exp testing,
> haven't actu
On Thu, May 23, 2013 at 01:04:36PM +0100, Jonathan Wakely wrote:
> > 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 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
>> #endif
>>
>> #if defined (SYS_clock_gettime) && def
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
Rainer Orth writes:
> Jonathan Wakely writes:
>
>> This alters the configure script to enable C++11 thread library
>> features based on targets that are known to support the features,
>> rather than based on link tests which are disabled by default. With
>> Glibc 2.17 this enables a nanosecond
Jonathan Wakely writes:
>> All of them have the same root cause:
>>
>> Excess errors:
>> Undefined first referenced
>> symbol in file
>> nanosleep /var/tmp//ccQhmiwd.o (symbol belongs to implicit dependency
>> /lib/librt.so.1)
>> ld: fatal: symbo
On 22 May 2013 15:05, Rainer Orth wrote:
> Jonathan Wakely writes:
>
>> This alters the configure script to enable C++11 thread library
>> features based on targets that are known to support the features,
>> rather than based on link tests which are disabled by default. With
>> Glibc 2.17 this en
Jonathan Wakely writes:
> This alters the configure script to enable C++11 thread library
> features based on targets that are known to support the features,
> rather than based on link tests which are disabled by default. With
> Glibc 2.17 this enables a nanosecond resolution std::system_clock
On Wed, May 22, 2013 at 12:49:44PM +0100, Jonathan Wakely wrote:
> On 22 May 2013 12:15, Jakub Jelinek wrote:
> >
> > If now() can be perhaps with worse precision emulated in configurations not
> > built against glibc 2.17, perhaps best solution would be to
> > add now()@@GLIBCXX_3.4.18 into 4.8.1
On 22 May 2013 12:49, Jonathan Wakely wrote:
> On 22 May 2013 12:15, Jakub Jelinek wrote:
>>
>> If now() can be perhaps with worse precision emulated in configurations not
>> built against glibc 2.17, perhaps best solution would be to
>> add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 s
On 05/22/2013 01:49 PM, Jonathan Wakely wrote:
On 22 May 2013 12:15, Jakub Jelinek wrote:
If now() can be perhaps with worse precision emulated in configurations not
built against glibc 2.17, perhaps best solution would be to
add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to
On 22 May 2013 12:15, Jakub Jelinek wrote:
>
> If now() can be perhaps with worse precision emulated in configurations not
> built against glibc 2.17, perhaps best solution would be to
> add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to
> 3.4.19) and have now()@GLIBCXX_3.4.17 (
On Wed, May 22, 2013 at 11:42:45AM +0100, Jonathan Wakely wrote:
> On 22 May 2013 11:40, Jonathan Wakely wrote:
> > On 22 May 2013 11:30, Paolo Carlini wrote:
> >> .. put an abort or something in the dummy implementations, to make sure
> >> people don't try to run an executable built with headers w
On 05/22/2013 12:40 PM, Jonathan Wakely wrote:
On 22 May 2013 11:30, Paolo Carlini wrote:
.. put an abort or something in the dummy implementations, to make sure
people don't try to run an executable built with headers which have the
clock available linked at run time to a .so which doesn't, rea
On 22 May 2013 11:40, Jonathan Wakely wrote:
> On 22 May 2013 11:30, Paolo Carlini wrote:
>> .. put an abort or something in the dummy implementations, to make sure
>> people don't try to run an executable built with headers which have the
>> clock available linked at run time to a .so which doesn'
On 22 May 2013 11:30, Paolo Carlini wrote:
> .. put an abort or something in the dummy implementations, to make sure
> people don't try to run an executable built with headers which have the
> clock available linked at run time to a .so which doesn't, really.
> Suboptimal solution because ideally w
.. put an abort or something in the dummy implementations, to make sure
people don't try to run an executable built with headers which have the
clock available linked at run time to a .so which doesn't, really.
Suboptimal solution because ideally we would like to fail at build time,
but this is
.. an idea I have got: we could arrange for defining the symbol
unconditionally, even when isn't really meaningful in that clock
configuration, and therefore exporting it uncondtionally, a dummy
implementation in many configuration. We also have at the same time to
regenerate the baselines to i
Hi,
On 05/22/2013 11:59 AM, Jonathan Wakely wrote:
On 22 May 2013 10:47, Paolo Carlini wrote:
Could you please double check abi_check? On this glibc 2.17 machine I'm
seeing:
1 incompatible symbols
0
_ZNSt6chrono12steady_clock3nowEv
std::chrono::steady_clock::now()
version status: incompatible
On 22 May 2013 10:47, Paolo Carlini wrote:
>
> Could you please double check abi_check? On this glibc 2.17 machine I'm
> seeing:
>
> 1 incompatible symbols
> 0
> _ZNSt6chrono12steady_clock3nowEv
> std::chrono::steady_clock::now()
> version status: incompatible
> GLIBCXX_3.4.17
> type: function
> st
Hi Jon,
On 05/22/2013 10:14 AM, Jonathan Wakely wrote:
This alters the configure script to enable C++11 thread library
features based on targets that are known to support the features,
rather than based on link tests which are disabled by default. With
Glibc 2.17 this enables a nanosecond resol
65 matches
Mail list logo
