[Bug rtl-optimization/51271] New: ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[Bug rtl-optimization/51271] New: ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

             Bug #: 51271
           Summary: ICE in in maybe_record_trace_start, at
                    dwarf2cfi.c:2244
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vries@gcc.gnu.org


Created attachment 25886
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25886
preprocessed res_hconf.c

I ran into this ICE with a mips64el cross compiler build from r181586:
...
res_hconf.c: In function 'skip_string':
res_hconf.c:104:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2244
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
...

compile line:
...
mips64el-linux-gnu-gcc  -mabi=n32 res_hconf.c -c -std=gnu99 -fgnu89-inline -O2
-Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wno-strict-prototypes
-Wno-write-strings -Wstrict-prototypes -fexceptions -mabi=n32
...

configure line:
...
/scratch/vries/b4/ref-mips64-ml-11-11-21/src/gcc-mainline/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=mips64el-linux-gnu
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--enable-checking=yes,rtl --disable-multilib --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu
--enable-__cxa_atexit --disable-nls --prefix=/opt/codesourcery --disable-libffi
--disable-libquadmath --enable-languages=c
--with-sysroot=/opt/codesourcery/mips64el-linux-gnu/libc
--with-build-sysroot=/scratch/vries/b4/ref-mips64-ml-11-11-21/install/mips64el-linux-gnu/libc
--with-gmp=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr
--with-mpc=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr
--with-ppl=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-cloog=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr
--with-libelf=/scratch/vries/b4/ref-mips64-ml-11-11-21/obj/host-libs-mainline-0-mips64el-linux-gnu-i686-pc-linux-gnu/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/vries/b4/ref-mips64-ml-11-11-21/install/mips64el-linux-gnu/bin
--with-build-time-tools=/scratch/vries/b4/ref-mips64-ml-11-11-21/install/mips64el-linux-gnu/bin
...

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org 2011-11-23 01:18:18 UTC ---
minimal compile line:
...
$ mips64el-linux-gnu-gcc -O2 -g res_hconf.c
...

minimal example res_hconf.c:
...
extern __thread int *__libc_tsd_CTYPE_B;

int *
skip_string (int *str)
{
  while (*str
         && __libc_tsd_CTYPE_B[*str]
         && *str != ',')
    ++str;
  return str;
}
...

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-11-23 01:55:24 UTC ---
This is interesting because I cannot reproduce it on a native big endian MIPS64
build (even with -mel).

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org 2011-11-23 11:40:06 UTC ---
Created attachment 25896
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25896
res_hconf.c.220r.vartrack

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org 2011-11-23 11:40:36 UTC ---
Created attachment 25897
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25897
res_hconf.c.221r.mach

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org 2011-11-23 11:41:10 UTC ---
Created attachment 25898
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25898
res_hconf.c.227r.nothrow

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org 2011-11-23 11:43:38 UTC ---
Created attachment 25899
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25899
res_hconf.c.228r.dwarf2

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org 2011-11-23 13:35:13 UTC ---
triggering assert: gcc_checking_assert (cfi_row_equal_p (cur_row,
ti->beg_row));

relevant values:
...
(gdb) call debug_cfi_row  (cur_row)
    .cfi_def_cfa 29, 16
(gdb) call debug_cfi_row  (ti->beg_row)
    .cfi_def_cfa 29, 16
    .cfi_offset 28, -8
...

The cur_row is the state belonging to the current transition, which is
  'saw edge from trace 2 to 3 (via fallthru 0)'
meaning the fallthru from bb 7 to bb 8.
The ti->beg_row is the state at the start of trace 3, which was generated by
  'saw edge from trace 1 to 3 (via jump_insn 156)'
meaning the jump from block 5 to block 8.

So we've got:
...
  block 7 -> block 8
    .cfi_def_cfa 29, 16

  block 5 -> block 8
    .cfi_def_cfa 29, 16
    .cfi_offset 28, -8
...

This difference seems related to epilogue insn 141:
...
(insn 141 155 142 (set (reg:DI 28 $28)
        (mem/c:DI (plus:SI (reg/f:SI 29 $sp)
                (const_int 8 [0x8])) [4 S8 A64])) res_hconf.c:11 278
{*movdi_64bit}
     (nil))
...

Insn 141 is copied by pass_mach (probably by dbr_schedule) to:
- the delay slot of jump_insn 63 in bb 4, and to
- the delay slot of jump_insn 75 in bb 6.

jump_insn 63 is an annuling jump (jump_insn/u) and insn 141 is only executed
then the branch is taken (insn/s), so it does not disturb the fallthru path.
...
(insn 177 62 65 (sequence [
            (jump_insn/u 63 62 141 (set (pc)
                    (if_then_else (eq (reg:SI 4 $4 [orig:242 D.2240 ] [242])
                            (reg:SI 3 $3 [256]))
                        (label_ref:SI 176)
                        (pc))) res_hconf.c:8 434 {*branch_equalitysi}
                 (expr_list:REG_BR_PRED (const_int 48 [0x30])
                    (expr_list:REG_DEAD (reg:SI 4 $4 [orig:242 D.2240 ] [242])
                        (expr_list:REG_DEAD (reg:SI 3 $3 [256])
                            (expr_list:REG_EQUAL (if_then_else (eq (reg:SI 4 $4
[orig:242 D.2240 ] [242])
                                        (const_int 44 [0x2c]))
                                    (label_ref:SI 176)
                                    (pc))
                                (expr_list:REG_BR_PROB (const_int 300 [0x12c])
                                    (nil))))))
             -> 176)
            (insn/s 141 63 65 (set (reg:DI 28 $28)
                    (mem/c:DI (plus:SI (reg/f:SI 29 $sp)
                            (const_int 8 [0x8])) [4 S8 A64])) 278
{*movdi_64bit}
                 (nil))
        ]) res_hconf.c:8 -1
     (nil))
...

jump_insn 75 is an normal jump and insn 141 is executed on either branch or
fallthru path.
...
(insn 178 74 76 (sequence [
            (jump_insn 75 74 141 (set (pc)
                    (if_then_else (eq (reg:SI 4 $4 [orig:259 *D.2245_8 ] [259])
                            (const_int 0 [0]))
                        (label_ref:SI 176)
                        (pc))) res_hconf.c:7 434 {*branch_equalitysi}
                 (expr_list:REG_BR_PRED (const_int 48 [0x30])
                    (expr_list:REG_DEAD (reg:SI 4 $4 [orig:259 *D.2245_8 ]
[259])
                        (expr_list:REG_BR_PROB (const_int 300 [0x12c])
                            (nil))))
             -> 176)
            (insn 141 75 76 (set (reg:DI 28 $28)
                    (mem/c:DI (plus:SI (reg/f:SI 29 $sp)
                            (const_int 8 [0x8])) [4 S8 A64])) 278
{*movdi_64bit}
                 (nil))
        ]) res_hconf.c:7 -1
     (nil))
...

The execution of insn 141 in bb 6 on the fallthru path causes the difference in
cfa state at the entry of bb8, which causes the assert.

Disregarding cfa info, the branch delay scheduling looks correct to me.
I guess we need analyze why the epilogue insn is not handled more conservative
by branch delay scheduling, and fix that.

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[gcc@Denis-Excoffier.org]

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

--- Comment #8 from Denis Excoffier <gcc@Denis-Excoffier.org> 2011-11-28 07:41:38 UTC ---
Created attachment 25928
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25928
preprocessed exclude.c

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[gcc@Denis-Excoffier.org]

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

Denis Excoffier <gcc@Denis-Excoffier.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc@Denis-Excoffier.org

--- Comment #9 from Denis Excoffier <gcc@Denis-Excoffier.org> 2011-11-28 07:44:12 UTC ---
Under last Cygwin (XP 32bits) and with gcc-4.7-20111119, i get the same
message with exclude.c (from the rsync-3.0.9 distribution), see
attachment (preprocessed).
However, i cannot reproduce the minimal test case given under
Comment 1.

% gcc -O2 -o exclude.o -c exclude.c
exclude.c: In function 'get_cvs_excludes':
exclude.c:943:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2244
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |mips64el-linux-gnu

--- Comment #10 from vries at gcc dot gnu.org 2011-11-30 11:40:45 UTC ---
Denis,

1.
If I click on exclude.c, I get:
...
XML Parsing Error: not well-formed
Location: http://gcc.gnu.org/bugzilla/attachment.cgi?id=25928
Line Number 1, Column 2:# 1 "exclude.c"
-^
...
I don't know whether this is specific to me, but I am able to open other
attachments.


2.
It's possible that you've hit a different bug with the same assert message.
Given:
- the fact that the investigation sofar points to delay slot scheduling, and
- my impression that you're talking about an x86-variant target,
I'd say it's likely it's a different bug, so you can file it as a separate bug.
If it turns out to be the same as this or another one, we can always mark it a
duplicate.

Thanks,
- Tom

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org 2011-11-30 16:20:07 UTC ---
Denis,

please open a separate bug, and mention configure line there.

Thanks,
- Tom

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[gcc@Denis-Excoffier.org]

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

--- Comment #12 from Denis Excoffier <gcc@Denis-Excoffier.org> 2011-11-30 20:03:47 UTC ---
I  have transfered my bug into #51366. Sorry for the noise.

[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-12-15 00:02:14 UTC ---
I think my patch for PR 51471 will also fix this bug.  I now know why I could
not reproduce it, I was using slightly different scheduling (-march=octeon
rather than the default).

[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
   Target Milestone|---                         |4.7.0
            Summary|ICE in in                   |[4.7 Regression] ICE in in
                   |maybe_record_trace_start,   |maybe_record_trace_start,
                   |at dwarf2cfi.c:2244         |at dwarf2cfi.c:2244

[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #14 from vries at gcc dot gnu.org 2011-12-17 12:49:21 UTC ---
Created attachment 26119
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26119
res_hconf.c.221r.mach, using Andrew's patch

(In reply to comment #13)
> I think my patch for PR 51471 will also fix this bug.  I now know why I could
> not reproduce it, I was using slightly different scheduling (-march=octeon
> rather than the default).

I tried out the patch, and the compiler does not assert any more. However, I'm
not convinced that it fixes the problem.

The patch inhibits scheduling of frame-related instructions in delay slots.
AFAIU, the instruction causing problems in this PR is insn 141, and it is not
marked as frame-related, so the patch has no direct effect on that instruction.

The patch seems to have the following effect: the frame-related insn 129 (from
the prologue) is inhibited from being scheduled into the delay slot of
jump_insn 60. So instead, insn 141 is now scheduled into the delay slot of
jump_insn 60. As a consequence insn 141 is now executed on both paths leading
up to block 8, and the assert is not triggered anymore.

rtl.h:
...
  /* 1 in an INSN or a SET if this rtx is related to the call frame,
     either changing how we compute the frame address or saving and
     restoring registers in the prologue and epilogue.
     <SNIP>.  */
  unsigned frame_related : 1;
...

given this definition, maybe insn 141 should be marked as frame-related, since
it restores a reg in the epilogue.

[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #15 from vries at gcc dot gnu.org 2011-12-19 13:17:23 UTC ---
> given this definition, maybe insn 141 should be marked as frame-related, since
> it restores a reg in the epilogue.

It seems to be the other way round: insn 141 is ignored by scan_insn_after,
because:
- it is not frame-related, and 
- doesn't contain a REG_ARGS_SIZE note.
The problematic insn is insn 143. That one has the REG_CFA notes attached, and
is causes changes in cfi state.

In scan_trace, we're handling insn 143 as element in the delay slot of an
annulling branch, executed only on taken branch:
...
(gdb) call debug_rtx (elt)
(insn/s/f 143 79 162 (set (reg/f:SI 29 $sp)
        (plus:SI (reg/f:SI 29 $sp)
            (const_int 16 [0x10]))) 10 {*addsi3}
     (expr_list:REG_CFA_DEF_CFA (reg/f:SI 29 $sp)
        (expr_list:REG_CFA_RESTORE (reg:DI 28 $28)
            (nil))))
...

The row state at that point is:
...
(gdb) call debug_cfi_row (cur_row)
    .cfi_def_cfa 29, 16
    .cfi_offset 28, -8
...

we then execute scan_insn_after to setup the trace at the target of the jump:
...
(gdb) 
2460              scan_insn_after (elt);
....

at which point the REG_CFAs have been taken into account:
...
(gdb) call debug_cfi_row (cur_row)
    .cfi_def_cfa 29, 0
...

we then try to restore for the fallthru path:
...
2467              cur_trace->end_true_args_size = restore_args_size;
(gdb) n
2468              cur_row->cfa = this_cfa;
(gdb) 
...

but the state is not sufficiently restored:
...
(gdb) call debug_cfi_row (cur_row)
    .cfi_def_cfa 29, 16
...
The '.cfi_offset 28, -8' is missing.

This tentative patch fixes the problem for the testcase:
...
Index: src/gcc-mainline/gcc/dwarf2cfi.c
===================================================================
--- src/gcc-mainline/gcc/dwarf2cfi.c (revision 182341)
+++ src/gcc-mainline/gcc/dwarf2cfi.c (working copy)
@@ -2452,10 +2452,12 @@ scan_trace (dw_trace_info *trace)
           if (INSN_FROM_TARGET_P (elt))
         {
           HOST_WIDE_INT restore_args_size;
+          cfi_vec save_row_reg_save;

           add_cfi_insn = NULL;
           restore_args_size = cur_trace->end_true_args_size;
           cur_cfa = &cur_row->cfa;
+          save_row_reg_save = VEC_copy (dw_cfi_ref, gc, cur_row->reg_save);

           scan_insn_after (elt);

@@ -2466,6 +2468,7 @@ scan_trace (dw_trace_info *trace)

           cur_trace->end_true_args_size = restore_args_size;
           cur_row->cfa = this_cfa;
+          cur_row->reg_save = save_row_reg_save;
           cur_cfa = &this_cfa;
           continue;
         }
...

[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-04 13:36:30 UTC ---
I assume the issue would reproduce on mipsisa64-elf as well.

[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #17 from vries at gcc dot gnu.org 2012-01-08 14:12:44 UTC ---
Submitted http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00359.html

[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

--- Comment #18 from vries at gcc dot gnu.org 2012-01-10 08:50:45 UTC ---
Author: vries
Revision: 183052
Modified property: svn:log

Modified: svn:log at Tue Jan 10 08:50:40 2012
------------------------------------------------------------------------------
--- svn:log (original)
+++ svn:log Tue Jan 10 08:50:40 2012
@@ -1,4 +1,5 @@
 2012-01-10  Tom de Vries  <tom@codesourcery.com>

+    PR rtl-optimization/51271
     * dwarf2cfi.c (scan_trace): Save and restore cur_row->reg_save when
     handling annulled branch.

[Bug rtl-optimization/51271] [4.7 Regression] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #19 from vries at gcc dot gnu.org 2012-01-10 08:53:43 UTC ---
Patch committed in r183052.