This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PowerPC: Define __PTHREAD_MUTEX_HAVE_ELISION to 0
- From: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Tue, 25 Mar 2014 13:37:46 -0300
- Subject: Re: [PATCH] PowerPC: Define __PTHREAD_MUTEX_HAVE_ELISION to 0
- Authentication-results: sourceware.org; auth=none
- References: <532C872D dot 8030107 at linux dot vnet dot ibm dot com> <53318BC9 dot 40404 at linux dot vnet dot ibm dot com> <mvmwqfil26w dot fsf at hawking dot suse dot de> <5331A8BF dot 3050401 at linux dot vnet dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1403251610320 dot 15671 at digraph dot polyomino dot org dot uk>
On 25-03-2014 13:19, Joseph S. Myers wrote:
> On Tue, 25 Mar 2014, Adhemerval Zanella wrote:
>
>> I agree with you, but the patch to check if it is defined in
>> nptl/sysdeps/pthread/pthread.h was rejected:
>> https://sourceware.org/ml/libc-alpha/2014-03/msg00494.html. So I just
>> folowed the way x86_64 and s390 does. If this was just an warning I'd
>> rework it to make it more general, as Roland as suggested in
>> https://sourceware.org/ml/libc-alpha/2014-03/msg00501.html; but it is
>> breaking 'make check' build. So my preference now is let it as and focus
>> on a proper fix, if any, after.
> I suggest an installed header bits/pthread-elision.h that defines
> __PTHREAD_MUTEX_HAVE_ELISION to an appropriate value. That avoids every
> architecture without elision needing to define this value in separate
> bits/pthreadtypes.h files.
>
> I also strongly advise *not* applying any architecture-specific fixes for
> -Wundef warnings that appear not to be architecture-specific without:
>
> (a) working out the correct general solution;
>
> (b) if not fixing all architectures, listing the issue and unfixed
> architectures on <https://sourceware.org/glibc/wiki/PortStatus>.
>
> We've made a lot of progress on avoiding architectures diverging from each
> other. Instead of ad hoc fixes for particular architectures, follow
> Siddhesh's example for fixing bits/mathdef.h (where he fixed all affected
> versions of the header).
>
> By all means just fix issues where the issue and fix appear genuinely
> architecture-specific, rather than relating to a header for which many
> architectures have their own versions all of which would need fixing
> similarly. But for architecture-independent issues like this, it's
> necessary to take the extra steps to avoid divergence and ensure agreement
> over the right fix for all architectures.
>
Fair enough, patch reverted.