Re: general protection faults with "git grep" version 1.7.7.1

Thomas Rast wrote:
...

quoted

The real problem seems to be in glibc, with its addition of
the "leaf" attribute to those synchronization primitives:

  http://bugzilla.redhat.com/747377#c22

Aha.  Glad you found it :-)

Meanwhile I read

  http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

which discusses a similar issue in section 4.3, but is very
interesting on its own.  It's funny how it says

  We know of at least three optimizing compilers (two of them
  production compilers) that performed this transformation at some
  point during their lifetime; usually at least partially reversing
  the decision when the implications on multi-threaded code became
  known.

I guess that would be four now if it was literally the same problem.

Yep.  For those not following the BZ comments at the about URL,
POSIX is quite clear.  Quoting from
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11:

    The following functions synchronize memory with respect to other threads:

        fork
        pthread_barrier_wait
        pthread_cond_broadcast
        pthread_cond_signal
        pthread_cond_timedwait
        pthread_cond_wait
        pthread_create
        pthread_join
        pthread_mutex_lock
        pthread_mutex_timedlock
        pthread_mutex_trylock
        pthread_mutex_unlock
        pthread_spin_lock
        pthread_spin_trylock
        pthread_spin_unlock
        pthread_rwlock_rdlock
        pthread_rwlock_timedrdlock
        pthread_rwlock_timedwrlock
        pthread_rwlock_tryrdlock
        pthread_rwlock_trywrlock
        pthread_rwlock_unlock
        pthread_rwlock_wrlock
        sem_post
        sem_timedwait
        sem_trywait
        sem_wait
        semctl
        semop
        wait
        waitpid

glibc's addition of the leaf attribute to any of those
appears to make gcc violate that.