From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-409592-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6074 invoked by alias); 12 Dec 2012 06:09:29 -0000
Received: (qmail 5914 invoked by uid 48); 12 Dec 2012 06:09:02 -0000
From: "kkojima at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/55659] New: [4.8 Regression] [SH] Build failure with ICE in dwarf2out_var_location, at dwarf2out.c:20748
Date: Wed, 12 Dec 2012 06:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kkojima at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55659-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
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
X-SW-Source: 2012-12/txt/msg01200.txt.bz2


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

             Bug #: 55659
           Summary: [4.8 Regression] [SH] Build failure with ICE in
                    dwarf2out_var_location, at dwarf2out.c:20748
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: kkojima@gcc.gnu.org
                CC: jakub@gcc.gnu.org
            Target: sh*-*-*


sh4-unknown-linux-gnu fails to build during compiling libgcc2.c with

trunk/libgcc/libgcc2.c: In function '__absvsi2':
trunk/libgcc/libgcc2.c:234:1: internal compiler error: in
dwarf2out_var_location, at dwarf2out.c:20748
 }
 ^
0x82e4b56 dwarf2out_var_location
    ../../ORIG/trunk/gcc/dwarf2out.c:20744
0x83439bb final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
    ../../ORIG/trunk/gcc/final.c:2215

It looks to start to fail after

r194392 | jakub | 2012-12-11 19:41:44 +0900 (Tue, 11 Dec 2012) | 10 lines

        PR middle-end/43631
        PR bootstrap/55615
        * var-tracking.c (emit_note_insn_var_location): If insn is followed
        by BARRIER, put note after the BARRIER.
        (next_non_note_insn_var_location): Skip over BARRIERs.
        (emit_notes_in_bb): If call is followed by BARRIER, put note after
        the BARRIER.

A reduced testcase for -g -O2 is

void
foo (void)
{
  bar ();
}

.236r.barriers dump looks like:

...
(call_insn/j 6 5 7 (parallel [
            (set (reg:SI 0 r0)
                (call (mem:SI (reg/f:SI 0 r0 [160]) [0 bar S4 A32])
                    (const_int 0 [0])))
            (use (reg:PSI 151 ))
            (return)
        ]) foo.c:4 325 {sibcall_valuei}
     (expr_list:REG_DEAD (reg:PSI 151 )
        (expr_list:REG_UNUSED (reg:SI 0 r0)
            (nil)))
    (nil))
(barrier 7 6 14)
(code_label 14 7 15 3 "" [0 uses])
(insn 15 14 16 (unspec_volatile [
            (const_int 2 [0x2])
        ] UNSPECV_CMPXCHG_2) 408 {align_log}
     (nil))
(code_label 16 15 17 2 "" [0 uses])
(insn 17 16 18 (unspec_volatile [
            (symbol_ref:SI ("bar") [flags 0x41]  <function_decl 0xb750c600
bar>)
            (const_int 0 [0])
        ] 4) 404 {consttable_4}
     (nil))
(insn 18 17 19 (unspec_volatile [
            (const_int 0 [0])
        ] 11) 409 {consttable_end}
     (nil))
(barrier 19 18 13)
(note 13 19 11 (expr_list:REG_DEP_TRUE (concat:SI (pc)
        (symbol_ref:SI ("bar") [flags 0x41]  <function_decl 0xb750c600 bar>))
    (nil)) NOTE_INSN_CALL_ARG_LOCATION)
(note 11 13 0 NOTE_INSN_DELETED)

Before the latest var-tracking.c change, NOTE_INSN_CALL_ARG_LOCATION
note has been put just after barrier 7 instead of barrier 19.  It seems
that the insns for constant pools for this target make the middle-end
confused.