| Message ID | 20160720.153931.575029361394679476.davem@davemloft.net |
|---|---|
| State | New |
| Headers | show |
On Wed, 2016-07-20 at 15:39 -0700, David Miller wrote: > From: Carlos O'Donell <carlos@redhat.com> > Date: Sat, 16 Jul 2016 14:11:27 -0400 > > > Are you able to do the sparc and sparc64 testing? > > I did v9 sparc and sparc64 runs and they mostly look fine. Great, thanks. What do we do with pre-v9 sparc though? I believe pthreads barriers don't work on it currently, and the new condvar and rwlock implementaitons that we'll hopefully switch to in the next cycle also wouldn't work on pre-v9 sparc. Do we want to: (1) not further support pre-v9 sparc? (2) not further support all of pthreads on pre-v9 sparc (and potentially other things in glibc that use rwlocks, IIRC we don't use condvars internally)? (3) build something that emulates full C11 atomics, either backed by locks in the synchronization data structure or a process-global lock array (though we'd have to adapt the current condvar because there's no space for an extra lock there)? We could also continue to adapt each synchronization data structure specially to pre-v9 sparc, but I don't think this is good enough in terms of maintainability. Personally, I also don't have time to work on (3).
From: Torvald Riegel <triegel@redhat.com> Date: Thu, 21 Jul 2016 13:32:48 +0200 > (3) build something that emulates full C11 atomics, either backed by > locks in the synchronization data structure or a process-global lock > array (though we'd have to adapt the current condvar because there's no > space for an extra lock there)? Nothing done completely inside of glibc will support signals properly. Even the current locking in glibc deadlocks in several testcases because of this problem. Like some other architectures in the same situation have done, we would need something in the kernel to implement locking properly and in a signal safe way. And it's really hard to justify all of that work.
On Thu, 21 Jul 2016, David Miller wrote: > Nothing done completely inside of glibc will support signals properly. > Even the current locking in glibc deadlocks in several testcases > because of this problem. > > Like some other architectures in the same situation have done, we > would need something in the kernel to implement locking properly > and in a signal safe way. > > And it's really hard to justify all of that work. Then should we follow option (1) not further support pre-v9 sparc? If so, much the same approach should be followed as for i386: make configure give an error when the compiler is configured for pre-v9; merge sysdeps directories so there are no longer separate sparcv8 and sparcv9 subdirectories but sparc/sparc32 assumes v9; remove obsolete preprocessor conditionals such as in kernel-features.h.
On 07/21/2016 10:06 PM, Joseph Myers wrote: > Then should we follow option (1) not further support pre-v9 sparc? > If so, much the same approach should be followed as for i386: make configure > give an error when the compiler is configured for pre-v9; merge sysdeps > directories so there are no longer separate sparcv8 and sparcv9 > subdirectories but sparc/sparc32 assumes v9; remove obsolete preprocessor > conditionals such as in kernel-features.h. Possibly we should retain a place for Leon3, which is mostly v8 but adds the casa instruction and the ability to use #ASI_USER_DATA from userspace. r~
On 22 Jul 2016 09:37, Richard Henderson wrote: > On 07/21/2016 10:06 PM, Joseph Myers wrote: > > Then should we follow option (1) not further support pre-v9 sparc? > > If so, much the same approach should be followed as for i386: make configure > > give an error when the compiler is configured for pre-v9; merge sysdeps > > directories so there are no longer separate sparcv8 and sparcv9 > > subdirectories but sparc/sparc32 assumes v9; remove obsolete preprocessor > > conditionals such as in kernel-features.h. > > Possibly we should retain a place for Leon3, which is mostly v8 but adds the > casa instruction and the ability to use #ASI_USER_DATA from userspace. Gentoo def sees leon users. off the top of my head, that's the only v8 we still really see. -mike
diff --git a/string/test-strncmp.c b/string/test-strncmp.c index 8c0a331..d392248 100644 --- a/string/test-strncmp.c +++ b/string/test-strncmp.c @@ -156,6 +156,9 @@ do_test_limit (size_t align1, size_t align2, size_t len, size_t n, int max_char, size_t i, align_n; CHAR *s1, *s2; + align1 &= ~(CHARBYTES - 1); + align2 &= ~(CHARBYTES - 1); + if (n == 0) { s1 = (CHAR *) (buf1 + page_size); @@ -204,6 +207,9 @@ do_test (size_t align1, size_t align2, size_t len, size_t n, int max_char, size_t i; CHAR *s1, *s2; + align1 &= ~(CHARBYTES - 1); + align2 &= ~(CHARBYTES - 1); + if (n == 0) return;