Bug 161736

Can you explain a little bit why -mv8 does not work? -mcpu=v7 -mtune=ultrasparc
is surely wrong.
My reading of GCC HEAD sparc.h is that -mv8 should work the same as it used to
do:
grep mv8[^p] gcc/config/sparc/sparc.h
%{mv8:-D__sparc_v8__} \
%{!mcpu*:%{!mcypress:%{!msparclite:%{!mf930:%{!mf934:%{!mv8:%{!msupersparc:%(cpp_cpu_default)}}}}}}} \
%{mv8:-mcpu=v8} %{msupersparc:-mcpu=supersparc} \
%{!mcpu*:%{!mcypress:%{!msparclite:%{!mf930:%{!mf934:%{!mv8:%{!msupersparc:%(asm_cpu_default)}}}}}}} \

Well, here is the output it not work, i guess something changed in params of gcc4:  
If need more infos let me know, i am really courios why is this mess. 
  
[root@sun /]# gcc -v  
Using built-in specs.  
Target: sparc64-redhat-linux  
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info  
--enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib  
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile  
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk  
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=sparc64-redhat-linux  
--build=sparc64-redhat-linux --target=sparc64-redhat-linux --with-cpu=v7  
Thread model: posix  
gcc version 4.0.0 20050622 (Red Hat 4.0.0-13)  
  
[root@sun /]# gcc -mv8 test.c  
cc1: error: invalid option 'v8'  
  
[root@sun /]# gcc -mcpu=v7 -mtune=ultrasparc   test.c  
test.c: In function 'main':  
test.c:6: warning: incompatible implicit declaration of built-in function 'printf'  
  
 
[root@sun /]# file a.out 
a.out: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for GNU/Linux 2.2.5, 
dynamically linked (uses shared libs), not stripped 
[root@sun /]# ./a.out 
Hello ! 
[root@sun /]#                                                                                                              

Weird.  Does gcc -mcpu=v8 test.c work?

Changed in upstream CVS, will show up in glibc-2.3.90-2 and later.
Note that there are far bigger problems for sparc though:
1) you need sufficiently recent binutils, so that sparc64 TLS support is in
2) linuxthreads have been killed, so the question is what to do with
   *.sparc.rpm builds (sparcv9.rpm and sparc64.rpm should support NPTL fine)
   We had a plan with davem what to do here:
> I started work on this.  It gets a little bit ugly because we
> have to thus override all of the sem_*.c NPTL support files as
> well on sparc.  I was thinking of overriding the fork.c and
> unregister-atfork.c stuff as well so that none of the atomic_*()
> pre-v9 sparc implementation ends up in the NPTL pthread library
> but then I noticed that a lot of top-level nptl/*.c code references
> the atomic_*() routines, sigh.

I think the current atomic_*() routines that use a lock pool
for pre-v9 are fine in most places.  The exceptions should IMHO be
a) futexes where we know the values in them are small (well, limited
to 24 bits is enough)
b) process shared stuff
So lll_*lock as well (thus pshared mutexes), rwlocks, condvars, barriers
and semaphores is enough.

lll*lock uses just 0, 1, 2 values, so ldstub there is fine.
Of the b) stuff, rwlocks are just using lll*lock and no other atomic
operations.  Condvars are also just using lll*lock and no other atomic,
except old_pthread_cond* stuff.  But old_pthread_cond* really can't
work process shared.  So, the only trouble are semaphores and barriers.
There are more than 8 bits left in both pthread_barrier_t and sem_t
though struct sem is ATM 4 bytes, and sem_t 16 (resp. 32 on sparc64) bytes,
and struct pthread_barrier is 16 bytes, while pthread_barrier_t is
20 (resp. 32) bytes.  SPARC would need to override sem_init.c and
pthread_barrier_init.c though, to clear the lock byte and even the
sparcv9/sparc64 sem/barrier routines would need to use that lock.
For lowlevellock.h, sparcv9/sparc64 would need to stop using
atomic_exchange_rel and instead use
do
  __val = *__futex & 3;
while (__builtin_expect (atomic_compare_and_exchange_bool_acq (__futex,
0, __val), 0));
which could be 2 cycles slower or something.

> The futex kernel stuff doesn't know about this convention we are
> using whereby the top byte of the word is used as a spinlock in
> the pre-v9 case.  Therefore my concern is that on a futex wakeup
> comparison, we might do the wrong thing if the futex kernel code
> sees the lock byte set (meaning a pre-v9 process is in the process
> of updating the futex).

The kernel ATM doesn't care, all it ever does is simple value
comparison.  Given that NPTL will never pass a value with upper 8 bits
set to the kernel as expected value of some futex, as soon as somebody
locks a futex for doing the "atomic" operation by ldstubing the upper
8 bits, kernel will consider it as a changed value and return with
-EAGAIN resp. -EWOULDBLOCK, which is what we want there.

The patch I wrote recently and Ingo said he likes that (FUTEX_WAKE_OP)
changes things, the kernel now needs to know how to unlock a lock.
But userland tells it how.  So, for SPARC we'll have 2 options,
either not use FUTEX_WAKE_OP at all and be slower in pthread_cond_signal,
or a SPARC specific operation can be added to the opcodes that will know
about the ldstub stuff and handle it properly.