From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20306 invoked by alias); 31 Mar 2014 09:55:36 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 20259 invoked by uid 48); 31 Mar 2014 09:55:30 -0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [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 Date: Mon, 31 Mar 2014 09:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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/msg02792.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59305 --- Comment #19 from Iain Sandoe --- (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 with= out 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). Howe= ver, 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 sa= me 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 mod= ulo size without considering alignment]. =3D=3D=3D On darwin it's possible to resolve the issue by replacing the pthread_mutex_lock()s with while ((err =3D pthead_mutex_trylock(=E2=80=A6)) !=3D 0) if (err =3D=3D =E2=80=A6) abort(); .. which might indicate an underlying issue with the implementation of pthr= eads (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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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=3D60655 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 --- Comment #8 from Richard Biener --- (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 fo= r 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 * > > } > >=20=20 > > if (GET_CODE (rtl) !=3D SYMBOL_REF) > > - return 0; > > + { > > + /* NOT is not handled by output_addr_const. */ > > + if (GET_CODE (rtl) =3D=3D NOT) > > + return 1; > > + return 0; > > + } > >=20=20 >=20 > In addition looks like we need to handle=20 >=20 > (minus (const_int) (sym_ref)) because with the reduced testcase with -g = and > removing the -fdata-sections I get an error with=20 >=20 > const ( minus (323) (sym_ref)) and gas won't grok that because there is no > relocation that will deal with this.=20 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? >=20 > (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) >=20 > 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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=60656 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P2