[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- .
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 --- Comment #7 from Zdenek Sojka --- Please feel free to close this one; I might open another PR if I trigger this ICE again.
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 --- Comment #6 from Jakub Jelinek --- #c0 got fixed or made latent with r235905. The #c4 testcase went latent with r249450 (though no idea why it hasn't been filed separately). In any case, not sure if it is worth keeping this open when it is either latent or fixed on the trunk.
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #5 from Arseny Solokha --- Is it still an issue?
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496
Zdenek Sojka changed:
What|Removed |Added
Known to fail||7.0
--- Comment #4 from Zdenek Sojka ---
Another testcase:
$ cat testcase.c
int c;
__int128 x;
void
foo ()
{
if (c)
x /= 5;
}
$ powerpc64-unknown-linux-gnu-gcc -O2 -fsched2-use-superblocks -g
--param=max-pending-list-length=0 testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2328
}
^
0x78d4b0 maybe_record_trace_start
/repo/gcc-trunk/gcc/dwarf2cfi.c:2328
0x78e360 scan_trace
/repo/gcc-trunk/gcc/dwarf2cfi.c:2510
0x78ebca create_cfi_notes
/repo/gcc-trunk/gcc/dwarf2cfi.c:2664
0x78ebca execute_dwarf2_frame
/repo/gcc-trunk/gcc/dwarf2cfi.c:3022
0x78ebca execute
/repo/gcc-trunk/gcc/dwarf2cfi.c:3502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) Richard, any thoughts what to do about this? Avoid scheduling frame related instructions across conditional jumps? Something else? Yes, for the short term that will have to be a requirement in order to keep the unwind info happy. Something for the next stage1 is (1) Avoiding the use of bare /f, and thus also REG_FRAME_RELATED_EXPR, using instead always REG_CFA_*. I suspect that this insn 620 shouldn't actually be frame related at all, but is a part of a larger dwarf expression we're intending to construct. (2) Once we have an unambiguous note for everything, we can allow these insns to be scheduled across a conditional jump if we strip and collect those notes and place them after the conditional jump, probably on a fake insn like (insn/f (use (const_int 0)) (expr-list:REG_CFA_... (expr-list:REG_CFA_... (expr-list:REG_CFA_...
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-20 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r217331. Not really a regression, as GCC 4.9 doesn't have -mavx512dq support.
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
And the problem is that with these weirdo scheduling options the scheduler
schedules the
(insn/f:TI 620 60 37 2 (set (reg:DI 39 r10)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8]))) pr65496.c:3 214 {*leadi}
(nil))
instruction before the shrink-wrapping conditional jump:
(jump_insn:TI 38 45 43 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 645)
(pc))) pr65496.c:4 613 {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 900 (nil)))
- 645)
At the end of the function we have:
(insn/f:TI 641 640 645 40 (set (reg/f:DI 7 sp)
(plus:DI (reg:DI 39 r10)
(const_int -8 [0xfff8]))) pr65496.c:6 214 {*leadi}
(expr_list:REG_DEAD (reg:DI 39 r10)
(expr_list:REG_CFA_DEF_CFA (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8]))
(nil
(code_label 645 641 644 41 106 [1 uses])
(note 644 645 663 41 [bb 41] NOTE_INSN_BASIC_BLOCK)
(jump_insn 663 644 643 41 (parallel [
(simple_return)
(unspec [
(const_int 0 [0])
] UNSPEC_REP)
]) pr65496.c:6 682 {simple_return_internal_long}
(nil))
(barrier 643 663 355)
And the problem is that because the r10 = rsp + 8 frame related instruction is
moved before the shrink-wrapping jump we assume CFA is in r10 + 0, but before
fallthru into the return we have a CFA restore note to use r8 + 8 again as CFA
(not really needed in this case, but desirable for the case when the r10 = rsp
+ 8 instruction isn't moved.
Richard, any thoughts what to do about this? Avoid scheduling frame related
instructions across conditional jumps? Something else?
