This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libgcc/59305] [4.9/5/6/7 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |libgcc

--- Comment #29 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #28)
> Me too on a ThunderX, I thought it was due to an hardware errata too (where
> load acquire was not a memory barrier after a store release).

The problem turns out that pthread_mutex_lock/unlock is not fair.  So what is
happening is the newly created thread (which does the stores) will happen to
get the lock more often than the other thread which is doing the arithmetic
operations and is the time thread which is keeping count.

There are a few ways of fixing this.  One is to loop on try lock for a few
thousand times before falling through to the full mutex_lock  [Really this
should be done this way in libc].  The other way is to use spin locks (which
does not fix darwin as darwin does not have pthread spinlocks).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]