Hello,
by forcing the compiler to detect consistency checks for 
atomics as I mentioned earlier, I detected 5 trouble spots. The first
four are relatively clear:

 - a_and and a_or interfaces on i386 and friends are not consistent
   with the remaining archs. They have `volatile void*` for the
   arguments and then do a gratuitous cast to `int*`. As far as I can
   see just using `volatile int*` as for the other archs works fine.
 - pthread_once_t should always be volatile
 - pthread_spinlock_t should always be volatile
 - pthread_barrier needs atomic increment

The fifth troubles me a bit. It concerns __timedwait and
__timedwait_cp. These both are mostly used with a first argument addr
that is atomic. This makes sense, since addr then is passed to a call
to futex, which internally might do some atomic operations. Now there
is one call that doesn't pass something that is otherwise seen as
atomic, namely line 14 in pthread_join.c. It reads as

	while ((tmp = t->tid)) __timedwait_cp(&t->tid, tmp, 0, 0, 0);

So is the task id here to be seen as atomic, or not? Will updates to
that field that are not atomic (and maybe optimized in some sort) be
able to mess up the futex call?

Thanks
Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::