On Thu, Oct 11, 2012 at 08:11:48PM +0200, Dominique Dhumieres wrote:
> Jack,
>
> > > That's PR 54407, so not a regression.
> >
> > ... The pthreads support is definitely improved in darwin11 and later.
>
> Do you confirm that 30_threads/condition_variable/54185.cc is passing on
> darwin11 and 12
Jack,
> > That's PR 54407, so not a regression.
>
> ... The pthreads support is definitely improved in darwin11 and later.
Do you confirm that 30_threads/condition_variable/54185.cc is passing on
darwin11 and 12?
If yes, I'll test a patch to skip it on darwin10 and older.
Dominique
On Thu, Oct 11, 2012 at 06:46:47PM +0100, Jonathan Wakely wrote:
> On 11 October 2012 17:05, Jack Howarth wrote:
> >
> > Jonathan,
> > The committed patch results in the expected this_thread::yield() and
> > this_thread::sleep_for()
> > support. I did run into a regression at -m32/-m64 on darw
On 11 October 2012 17:05, Jack Howarth wrote:
>
> Jonathan,
> The committed patch results in the expected this_thread::yield() and
> this_thread::sleep_for()
> support. I did run into a regression at -m32/-m64 on darwin10 (but not
> darwin11/12).
>
> WARNING: program timed out.
> FAIL: 30_thr
On Thu, Oct 11, 2012 at 12:18:59AM +0100, Jonathan Wakely wrote:
> On 11 October 2012 00:09, Jonathan Wakely wrote:
> > On 9 October 2012 18:49, Benjamin De Kosnik wrote:
> >>
> >>> I don't like the sched_yield macro being set there because it's
> >>> detected correctly by configure anyway, but I'm
On 11 October 2012 00:09, Jonathan Wakely wrote:
> On 9 October 2012 18:49, Benjamin De Kosnik wrote:
>>
>>> I don't like the sched_yield macro being set there because it's
>>> detected correctly by configure anyway, but I'm not going to labour
>>> that point any more.
>>
>> Indeed. Then somebody w
On 9 October 2012 18:49, Benjamin De Kosnik wrote:
>
>> I don't like the sched_yield macro being set there because it's
>> detected correctly by configure anyway, but I'm not going to labour
>> that point any more.
>
> Indeed. Then somebody will waste hours in the future wondering why
> configure s
On Tue, Oct 09, 2012 at 10:49:28AM -0700, Benjamin De Kosnik wrote:
>
> > I don't like the sched_yield macro being set there because it's
> > detected correctly by configure anyway, but I'm not going to labour
> > that point any more.
>
> Indeed. Then somebody will waste hours in the future wonde
> I don't like the sched_yield macro being set there because it's
> detected correctly by configure anyway, but I'm not going to labour
> that point any more.
Indeed. Then somebody will waste hours in the future wondering why
configure says no but their TU says yes.
At least a comment in the co
On 9 October 2012 14:11, Jack Howarth wrote:
> On Tue, Oct 09, 2012 at 09:21:25AM +0100, Jonathan Wakely wrote:
>> I don't like the sched_yield macro being set there because it's
>> detected correctly by configure anyway, but I'm not going to labour
>> that point any more.
>
> Since we are defining
On Tue, Oct 09, 2012 at 09:21:25AM +0100, Jonathan Wakely wrote:
> On 9 October 2012 01:39, Jack Howarth wrote:
> >The --enable-libstdcxx-time=yes configure option fails to validate the
> > presence of a usable nanosleep() call on darwin due to its use of pre-2008
> > POSIX timers. As both nano
On 9 October 2012 01:39, Jack Howarth wrote:
>The --enable-libstdcxx-time=yes configure option fails to validate the
> presence of a usable nanosleep() call on darwin due to its use of pre-2008
> POSIX timers. As both nanosleep() and sched_yield() have always been available
> on darwin, the att
The --enable-libstdcxx-time=yes configure option fails to validate the
presence of a usable nanosleep() call on darwin due to its use of pre-2008
POSIX timers. As both nanosleep() and sched_yield() have always been available
on darwin, the attached patch simply defines _GLIBCXX_USE_NANOSLEEP and
13 matches
Mail list logo
