On Fri, Nov 25, 2011 at 08:38:39AM +0100, Jakub Jelinek wrote: > My preference would be to avoid the abstraction changes though, both > because it is additional clutter in the changeset and because omp_lock > and nested lock are part of public ABIs, so if struct is layed out > differently on some weird architecture, it would be an ABI change.
OK, fair enough. I didn't consider that structs may be laid out differently. > So, if you could keep gomp_mutex_t, omp_lock_t and gomp_sem_t as integers, > it would be appreciated. > > Furthermore, I'd prefer if the patch could be split into smaller parts, > e.g. for bisecting purposes. One patch would do the mutex changes > to use new atomics, remove extra mutex.h headers and start using 0/1/-1 > instead of 0/1/2. And another patch would rewrite the semaphores. OK. I need to do this anyway as I just discovered a regression when looping on one of the tests. I suspect the acquire/release mutex locking may have exposed bugs elsewhere in libgomp that were covered by the heavyweight locking used by the __sync builtins. -- Alan Modra Australia Development Lab, IBM
