diff mbox

New condvar implementation that provides stronger ordering guarantees.

Message ID 1483368450.13143.70.camel@redhat.com
State New, archived
Headers

Commit Message

Torvald Riegel Jan. 2, 2017, 2:47 p.m. UTC 
  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?

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.)

Comments

Joseph Myers Jan. 2, 2017, 6:13 p.m. UTC | #1 
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.
diff mbox

Patch

commit 62210e7eb1b270c72c2ee61a14015285cd817262
Author: Torvald Riegel <triegel@redhat.com>
Date:   Mon Jan 2 15:39:14 2017 +0100

    Fix pthread_cond_t on sparc for new condvar.
    
    	* sysdeps/sparc/nptl/bits/pthreadtypes.h (pthread_cond_t): Adapt to
    	new condvar.

diff --git a/sysdeps/sparc/nptl/bits/pthreadtypes.h b/sysdeps/sparc/nptl/bits/pthreadtypes.h
index ebef53a..5685d95 100644
--- a/sysdeps/sparc/nptl/bits/pthreadtypes.h
+++ b/sysdeps/sparc/nptl/bits/pthreadtypes.h
@@ -122,14 +122,27 @@  typedef union
 {
   struct
   {
-    int __lock;
-    unsigned int __futex;
-    __extension__ unsigned long long int __total_seq;
-    __extension__ unsigned long long int __wakeup_seq;
-    __extension__ unsigned long long int __woken_seq;
-    void *__mutex;
-    unsigned int __nwaiters;
-    unsigned int __broadcast_seq;
+    __extension__ union
+    {
+      __extension__ unsigned long long int __wseq;
+      struct {
+	unsigned int __low;
+	unsigned int __high;
+      } __wseq32;
+    };
+    __extension__ union
+    {
+      __extension__ unsigned long long int __g1_start;
+      struct {
+	unsigned int __low;
+	unsigned int __high;
+      } __g1_start32;
+    };
+    unsigned int __g_refs[2];
+    unsigned int __g_size[2];
+    unsigned int __g1_orig_size;
+    unsigned int __wrefs;
+    unsigned int __g_signals[2];
   } __data;
   char __size[__SIZEOF_PTHREAD_COND_T];
   __extension__ long long int __align;