From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4906 invoked by alias); 5 May 2014 19:27:32 -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 4874 invoked by uid 48); 5 May 2014 19:27:28 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter Date: Mon, 05 May 2014 19:27: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.10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.1 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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-05/txt/msg00303.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61060 Uro=C5=A1 Bizjak changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at ucw dot cz --- Comment #2 from Uro=C5=A1 Bizjak --- The code in ix86_expand_set_or_movmem assumes that !count implies non-const= _int count_exp: unsigned HOST_WIDE_INT count =3D 0; ... if (CONST_INT_P (count_exp)) min_size =3D max_size =3D probable_max_size =3D count =3D expected_size =3D INTVAL (count_exp); ... if (!count) count_exp =3D copy_to_mode_reg (GET_MODE (count_exp), count_exp); However, when count_exp is (const_int 0), the assumption breaks, and the co= de tries to determine the mode of modeless (const_int 0) count_exp RTX. CC author of the code. >>From gcc-bugs-return-450612-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 05 19:33:34 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 7954 invoked by alias); 5 May 2014 19:33:34 -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 7928 invoked by uid 48); 5 May 2014 19:33:30 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable() Date: Mon, 05 May 2014 19:33: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.10.0 X-Bugzilla-Keywords: ice-checking, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed 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-05/txt/msg00304.txt.bz2 Content-length: 1759 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61058 Jeffrey A. Law changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2014-05-05 Ever confirmed|0 |1 --- Comment #3 from Jeffrey A. Law --- What do you need me to confirm? I can confirm that you're not supposed to have BARRIERS in the middle of a block. THe RTL in question: .file "j.c" .text .globl foo .type foo, @function foo: pushq %rbp (note 1 0 3 NOTE_INSN_DELETED) (note 3 1 9 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (insn/f 9 3 10 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8]) (reg/f:DI 6 bp)) j.c:2 65 {*pushdi2_rex64} (nil)) (insn/f 10 9 5 2 (set (reg/f:DI 6 bp) (reg/f:DI 7 sp)) j.c:2 89 {*movdi_internal} (nil)) (barrier 5 10 11) (note 11 5 2 2 NOTE_INSN_PROLOGUE_END) (note 2 11 8 2 NOTE_INSN_FUNCTION_BEG) (note 8 2 0 NOTE_INSN_DELETED) We're in distance_agu_use_in_bb. We're passing it insn 10 as INSN and the BARRIER as START. We try to look at BLOCK_FOR_INSN (start), after that, we're well into undefined territory. But this really looks like x86 backend breakage. Refer to the above RTL and look at this call site: 17976 if (insn != BB_END (bb)) 17977 distance = distance_agu_use_in_bb (regno0, insn, distance, 17978 NEXT_INSN (insn), 17979 &found, &redefined); Clearly if NEXT_INSN (insn) is a BARRIER, then nothing good can happen.