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: unassig...@gcc.gnu.org

        ReportedBy: kkoj...@gcc.gnu.org

                CC: ja...@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.

Reply via email to