From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6714 invoked by alias); 11 Jul 2014 23:03:50 -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 6537 invoked by uid 48); 11 Jul 2014 23:03:40 -0000 From: "pthaugen at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking Date: Fri, 11 Jul 2014 23:03: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: 4.10.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: pthaugen at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.10.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-07/txt/msg00739.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61757 --- Comment #19 from Pat Haugen --- Tracked down the problem in 176.gcc to a difference in the generated code f= or benchmark source toplev.c:exact_log2_wide(). Following compiled with -O3 -mcpu=3Dpower7. int exact_log2_wide (unsigned int x) { register int log =3D 0; if (x =3D=3D 0 || x !=3D (x & -x)) return -1; while ((x >>=3D 1) !=3D 0) log++; return log; } r212351: neg 9,3 and 9,9,3 cmplw 7,9,3 bne 7,.L5 >>> rldicl. 9,9,63,33 li 3,0 beq 0,.L6 r212352: neg 10,3 and 10,10,3 cmplw 7,10,3 bne 7,.L5 >>> srdi. 9,3,1 li 3,0 beq 0,.L6 r212351 is clearing the high word of the 64-bit register on the initial shi= ft right of 'x', whereas r212352 just starts shifting the whole 64-bit reg. The reason this causes problems is that the callers are calling with an integer arg: #define exact_log2(N) exact_log2_wide ((HOST_WIDE_INT) (N)) So in the case where MIN_INT32 is passed (sign extended), the upper 32 bits= are '1' so r212352 returns a value of 63 whereas prior revisions returned a val= ue of 31. Not sure if this is more of a benchmark source error, but figured I'd post = my findings in case it helps with the general problem. >>From gcc-bugs-return-456150-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 12 01:42:52 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 18840 invoked by alias); 12 Jul 2014 01:42:52 -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 18782 invoked by uid 48); 12 Jul 2014 01:42:48 -0000 From: "emsr at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/57644] [C++1y] Cannot bind bitfield to lvalue reference Date: Sat, 12 Jul 2014 01:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: emsr at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution 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-07/txt/msg00741.txt.bz2 Content-length: 472 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57644 emsr at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |emsr at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from emsr at gcc dot gnu.org --- Fixed on trunk...