This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] New condvar implementation that provides stronger ordering guarantees.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, Darren Hart <dvhart at infradead dot org>
- Date: Mon, 2 Jan 2017 18:13:22 +0000
- Subject: Re: [PATCH] New condvar implementation that provides stronger ordering guarantees.
- Authentication-results: sourceware.org; auth=none
- References: <1464268895.17104.14.camel@localhost.localdomain> <1465937639.31784.7.camel@localhost.localdomain> <696ddced-4efa-62ac-9fb5-01022b0437e8@redhat.com> <alpine.DEB.2.20.1612311732140.27227@digraph.polyomino.org.uk> <1483368450.13143.70.camel@redhat.com>
On Mon, 2 Jan 2017, Torvald Riegel wrote:
> On Sat, 2016-12-31 at 17:37 +0000, Joseph Myers wrote:
> > In addition to hppa (as expected), it appears the build is broken for
> > sparcv9 (previous discussion said it was broken for pre-v9, did the
> > expected breakage change as a result of other sparc changes?).
>
> I had initially left sparc pthreadtypes.h untouched because I assumed
> sparc would do something (eg, have proper atomics availabe for all sparc
> variants) -- and then failed to make some decision regarding sparc
> before commiting the new condvar. The attached patch just adds the new
> definitions to sparc's pthreadtypes.h, which should fix your build
> problem. Can you give it a try?
I can confirm this fixes the glibc build for sparc64-linux-gnu and
sparcv9-linux-gnu.
> Also, while we're at it, could you please have a look at the change to
> aarch64 pthread_cond_t introduced with the new condvar? I applied this
> change:
>
> - long int __align;
> + __extension__ long long int __align;
>
> which seemed fine because the previous struct definition also had long
> long int fields. Is this okay? (Same for ia64.)
I think changing long to long long is fine in such cases where they are
the same size. The AArch64 ILP32 people will need to figure out if it's
correct in that case.
--
Joseph S. Myers
joseph@codesourcery.com