When compiling glibc 2.5 with a gcc 4.2 snapshot (20061007), I'm seeing the
following assertion failure, e.g. in firefox:

galeon: pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.

I did some debugging and found out that the assertion is bogus. The reason it
shows up is because gcc move the load of mutex->__data.__owner before calling
lll_mutex_lock. gdb clearly shows that the owner is 0 after successful
aqcuisition of the lock, but the register has the content 0x6 from before
lll_mutex_lock.

Apparently somehow gcc doesn't get it that it should not reorder the loads
around lll_mutex_lock. I'm not sure whether this is a bug in glibc that shows up
with new gcc optimizations or whether this is a bug in gcc 4.2 (I looked through
the bugzilla regressions and didn't identify any such bugs, I haven't seen any
locking problems with gcc 4.2 compiled kernels either).

Please don't shoot me for testing stuff with alpha compilers. If this is indeed
not a glibc bug, I will report it to the gcc people.

Working disassembled code with gcc 4.1.1:

acquiring mutex (lll_mutex_lock):
  3d:   31 c0                   xor    %eax,%eax
  3f:   b9 01 00 00 00          mov    $0x1,%ecx
  44:   f0 0f b1 0b             lock cmpxchg %ecx,(%ebx)
  48:   0f 85 ed 05 00 00       jne    63b <_L_mutex_lock_86>
loading and testing owner:
  4e:   8b 43 08                mov    0x8(%ebx),%eax
  51:   85 c0                   test   %eax,%eax
  53:   0f 85 71 05 00 00       jne    5ca <__pthread_mutex_lock+0x5ca>
                                        -> __assert_fail

Broken code with gcc 4.2:

loading owner:
  2f:   8b 53 08                mov    0x8(%ebx),%edx
lll_mutex_lock:
  32:   31 c0                   xor    %eax,%eax
  34:   b9 01 00 00 00          mov    $0x1,%ecx
  39:   f0 0f b1 0b             lock cmpxchg %ecx,(%ebx)
  3d:   0f 85 f3 05 00 00       jne    636 <_L_mutex_lock_78>
testing owner (%edx from above!):
  43:   85 d2                   test   %edx,%edx
  45:   0f 85 7f 04 00 00       jne    4ca <__pthread_mutex_lock+0x4ca>
                                        -> __assert_fail