[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" <gcc-bugzilla@gcc.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.
>From gcc-bugs-return-447924-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 31 09:56:23 2014
Return-Path: <gcc-bugs-return-447924-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21058 invoked by alias); 31 Mar 2014 09:56:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21000 invoked by uid 48); 31 Mar 2014 09:56:19 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
Date: Mon, 31 Mar 2014 09:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: ramana at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority
Message-ID: <bug-60655-4-57hAvKCuFz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60655-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60655-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-03/txt/msg02793.txt.bz2
Content-length: 1845

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Ramana Radhakrishnan from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> > As discussed yesterday with Ramana on IRC, my suggested fix for this for 4.9
> > is something like:
> > --- gcc/dwarf2out.c	2014-03-03 08:24:14.841895755 +0100
> > +++ gcc/dwarf2out.c	2014-03-26 10:42:32.027508796 +0100
> > @@ -11326,7 +11326,12 @@ const_ok_for_output_1 (rtx *rtlp, void *
> >      }
> >  
> >    if (GET_CODE (rtl) != SYMBOL_REF)
> > -    return 0;
> > +    {
> > +      /* NOT is not handled by output_addr_const.  */
> > +      if (GET_CODE (rtl) == NOT)
> > +	return 1;
> > +      return 0;
> > +    }
> >  
> 
> In addition looks like we need to handle 
> 
> (minus (const_int) (sym_ref))  because with the reduced testcase with -g and
> removing the -fdata-sections I get an error with 
> 
> const ( minus (323) (sym_ref)) and gas won't grok that because there is no
> relocation that will deal with this. 

Note that (minus 323 sym_ref) is canonicalized (plus (neg sym_ref) 323)

but it looks like this needs to go through some legitimize hook before
handing it to output_addr_const?

> 
> (note 220 219 221 5 (var_location r2 (plus:SI (plus:SI (reg:SI 3 r3
> [orig:192 ivtmp.37 ] [192])
>         (symbol_ref:SI ("*.LANCHOR0") [flags 0x182]))
>     (const:SI (minus:SI (const_int 323 [0x143])
>             (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])))))
> NOTE_INSN_VAR_LOCATION)
> 
> Uggh this is proving to be more ugly.
>From gcc-bugs-return-447925-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 31 09:56:49 2014
Return-Path: <gcc-bugs-return-447925-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21799 invoked by alias); 31 Mar 2014 09:56:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21737 invoked by uid 48); 31 Mar 2014 09:56:46 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60656] [4.8/4.9 regression] x86 vectorization produces wrong code
Date: Mon, 31 Mar 2014 09:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority
Message-ID: <bug-60656-4-QWHdzpFcuj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60656-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60656-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-03/txt/msg02794.txt.bz2
Content-length: 290

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`656

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2