https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63315
--- Comment #1 from Jakub Jelinek ---
We have:
(insn 10025 3 10026 2 (set (reg:SI 85 [ D.39608 ])
(mem/u/j:SI (const:DI (plus:DI (symbol_ref:DI
("_otable_gnu_xml_util_XCat$Catalog") [flags 0x2] )
(const_int 68 [0x44]))) [11
_otable_gnu_xml_util_XCat$Catalog+68 S4 A32]))
/usr/src/gcc/libjava/classpath/gnu/xml/util/XCat.java:971 90 {*movsi_internal}
(expr_list:REG_EQUIV (mem/u/j:SI (const:DI (plus:DI (symbol_ref:DI
("_otable_gnu_xml_util_XCat$Catalog") [flags 0x2] )
(const_int 68 [0x44]))) [11
_otable_gnu_xml_util_XCat$Catalog+68 S4 A32])
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil
instruction that is at the end of bb2 and due to -fnon-call-exceptions marked
as possibly throwing, then LRA comes and removes this insn for whatever reason
(haven't looked), by turning it into NOTE_INSN_DELETED. This insn is preceeded
by some debug insns (for -g) and before that a CALL_INSN (supposedly
non-throwing one, because it didn't terminate a bb before).
Then lra calls fixup_abnormal_edges, which for -g0 removes the
NOTE_INSN_DELETED (for some strange reason considers the CALL_INSN, even when
it can't throw, as the spot which has to end the bb) and in theory would delete
any other non-throwing insns after the CALL_INSN. But for -g, there is a
DEBUG_INSN which it stops on.
So, either the bug is in LRA that it removed a possibly throwing insn, or that
it hasn't updated outgoing edges of the bb when removing possibly throwing insn
at the end. Or it is in fixup_abnormal_edges, because it shouldn't consider
CALL_INSNs that can't throw. Or what fixup_abnormal_edges does is fine in the
-g0 case and we should ignore DEBUG_INSNs during analysis and then throw them
away or something. Thoughts on this?
