Jonathan Wakely writes:
>>> I didn't like that feature of the patch much either, but the signature
>>> of the mutex_init function is specified in gthr.h:
>>>
>>> __GTHREAD_MUTEX_INIT_FUNCTION
>>> some systems can't initialize a mutex without a
>>> function call. On such
On 10 February 2012 18:20, Rainer Orth wrote:
> Jon,
>
>> On 10 February 2012 14:48, Rainer Orth wrote:
>>> I've also noticed one feature of your patch that I don't like:
>>> __GTHREAD_{MUTEX,COND}_INIT_FUNCTION ignore the return values of
>>> pthread_{mutex,cond}_init_function instead of passing t
Jon,
> On 10 February 2012 14:48, Rainer Orth wrote:
>> I've also noticed one feature of your patch that I don't like:
>> __GTHREAD_{MUTEX,COND}_INIT_FUNCTION ignore the return values of
>> pthread_{mutex,cond}_init_function instead of passing them on as all
>> other gthr-posix.h functions do. Th
On 10 February 2012 14:48, Rainer Orth wrote:
>
> Bootstrapped without regressions on alpha-dec-osf5.1b, ok for mainline?
Yes, this is OK, thanks for your help testing and getting all of this working.
On 10 February 2012 14:48, Rainer Orth wrote:
> I've also noticed one feature of your patch that I don't like:
> __GTHREAD_{MUTEX,COND}_INIT_FUNCTION ignore the return values of
> pthread_{mutex,cond}_init_function instead of passing them on as all
> other gthr-posix.h functions do. This might lea
Jonathan Wakely writes:
> On 6 February 2012 19:24, Mike Stump wrote:
>> On Feb 5, 2012, at 12:26 PM, Jonathan Wakely wrote:
>>> PRs libstdc++/51296 and libstdc++/51906 are both caused by problems
>>> with the Pthreads static initializer macros such as
>>> PTHREAD_MUTEX_INITIALIZER.
>>
>>> On Mac
On 6 February 2012 19:24, Mike Stump wrote:
> On Feb 5, 2012, at 12:26 PM, Jonathan Wakely wrote:
>> PRs libstdc++/51296 and libstdc++/51906 are both caused by problems
>> with the Pthreads static initializer macros such as
>> PTHREAD_MUTEX_INITIALIZER.
>
>> On Mac OS X 10.7 the PTHREAD_RECURSIVE_M
On Tue, Feb 07, 2012 at 09:11:38AM +, Jonathan Wakely wrote:
> gthr-posix.h changes OK as attached, with this ChangeLog?
Okay. Thanks.
> libgcc/
> 2012-02-07 Jonathan Wakely
>
> PR libstdc++/51906
> PR libstdc++/51296
> * gthr-posix.h: Allow static initializer mac
On 6 February 2012 06:40, Jakub Jelinek wrote:
> On Sun, Feb 05, 2012 at 08:26:22PM +, Jonathan Wakely wrote:
>> This has been testing on darwin, if Rainer tests it successfully on
>> Tru64 will the gthr-posix.h change be acceptable?
>
> Ok with a suitable ChangeLog entry.
Jakub, further to th
On Feb 5, 2012, at 12:26 PM, Jonathan Wakely wrote:
> PRs libstdc++/51296 and libstdc++/51906 are both caused by problems
> with the Pthreads static initializer macros such as
> PTHREAD_MUTEX_INITIALIZER.
> On Mac OS X 10.7 the PTHREAD_RECURSIVE_MUTEX_INITIALIZER is buggy.
Thanks for all you work
On Sun, Feb 05, 2012 at 08:26:22PM +, Jonathan Wakely wrote:
> This has been testing on darwin, if Rainer tests it successfully on
> Tru64 will the gthr-posix.h change be acceptable?
Ok with a suitable ChangeLog entry.
> diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
> index 46054f6..
On 5 February 2012 23:53, Jack Howarth wrote:
>
> There are no unexpected libstdc++ testsuite regressions on
> x86_64-apple-darwin11 with this
> patch applied to current gcc trunk.
Thanks, Jack. If I can't get approval for the change I'll workaround
it in libstdc++, but IMHO it would be cleaner
On Sun, Feb 05, 2012 at 08:26:22PM +, Jonathan Wakely wrote:
> PRs libstdc++/51296 and libstdc++/51906 are both caused by problems
> with the Pthreads static initializer macros such as
> PTHREAD_MUTEX_INITIALIZER.
>
> On Tru64 PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER can
> only b
PRs libstdc++/51296 and libstdc++/51906 are both caused by problems
with the Pthreads static initializer macros such as
PTHREAD_MUTEX_INITIALIZER.
On Tru64 PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER can
only be used for statically-initialized variables, as allowed by POSIX
currently, b
14 matches
Mail list logo
