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

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #18)
> sparc-sun-solaris2.10 is a primary arch, making P1 for now.  As sparc
> implements
> the hook Joseph mentions is this merely a testsuite issue (sparc being
> "slow")?

In Darwin's case, I don't believe it is (simply) a test-suite issue;

Rather it is connected with the implementation of pthread-based locking in
libatomic when entities larger than those natively-supported are used.

So, for example, if libatomic is configured to use a machine supporting
cmpxchg16b, then test-time drops from 50mins -> 1min (c.f. configuring without
cmpxchg16b).

Probing the stalled cases, shows that things are stuck in mutex code.

I started looking at the (default) posix implementation of the locking in
libatomic (partly to see if there was a more BSD-esque way to do it).  However,
I'm out of time for the next couple of weeks.

Two things (in the posix libatomic implementation) that might bear more
examination:

1) adjacent entities that happen to fall within one cache line size (which
would apply to two 32byte numbers stored consecutively, for x86) get the same
hash ID.  I wonder if that can introduce a vulnerability.

2) If the alignment of an entity is < its size, AFAICT the entity could span
two hash IDs without this being detected [the evaluation is carried out modulo
size without considering alignment].

===

On darwin it's possible to resolve the issue by replacing the
pthread_mutex_lock()s with
while ((err = pthead_mutex_trylock(…)) != 0)
 if (err == …) abort();

.. which might indicate an underlying issue with the implementation of pthreads
(or it might simply modify the behaviour enough to cause some other
vulnerability to be hidden).

--

I don't know if the same approach (spinning on try lock) would resolve the
issue on Solaris, or (particularly) how to interpret the findings yet.