[Bug target/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

2019-02-13 Thread acsawdey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308 --- Comment #5 from acsawdey at gcc dot gnu.org --- After some more digging, it appears that the problem is move_insn_for_shrink_wrap() is deleting and re-creating insns to move them from one BB to another. The label reference count gets

[Bug target/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

2019-02-12 Thread acsawdey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308 --- Comment #4 from acsawdey at gcc dot gnu.org --- Tracked down the difference between -m32 and -m64. In the -m64 case, rs6000_emit_move calls force_const_mem and that will set LABEL_PRESERVE_P on a label_ref that it finds, which is what marks

[Bug target/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

2019-02-12 Thread acsawdey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308 --- Comment #3 from acsawdey at gcc dot gnu.org --- One difference between compiling this -m32 and -m64 is that the label for the jump table is marked /s in the 64-bit version: (code_label/s 22 21 23 4 (nil) [4 uses]) (jump_table_data 23 22 24

[Bug target/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

2018-12-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308 --- Comment #2 from Segher Boessenkool --- This is related to PR88347.

[Bug target/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

2018-12-23 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88308 Segher Boessenkool changed: What|Removed |Added Target|powerpc-*-linux-gnu |powerpc*-*-*