https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |matz at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Last reconfirmed|2019-08-05 00:00:00 |2023-4-13
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Re-confirmed.
The implicit IL contract with the following is incredibly fragile:
<bb 5> [count: 0]:
<L2>:
d.1_16 = d;
_17 = d.1_16 + 4294967295;
d = _17;
resx 4 // EDGE_EH fallthru
<bb 6> [count: 0]:
<L3>:
_20 = __builtin_eh_filter (1);
if we don't support any stmts inbetween the RESX and the landing pad then
we should prohibit splitting the edge.
I think the issue is that splitting the EH edge creates a new landing pad
(OK), but when we sink stmts into that empty block there's a fallthru
from that landing pad to another landing pad. When ehcleanup then
elides the just RESX 4 containing forwarder via cleanup_empty_eh_merge_phis
that confuses it and the EH tree gets corrupt.
Into GIMPLE sink we get
Eh tree:
1 allowed_exceptions land:{1,<L3>},{3,} filter :-1 types:int
4 cleanup land:{2,<L2>}
which splitting two EH edges via split_edges_for_insertion turns into
Eh tree:
1 allowed_exceptions land:{4,<L6>},{1,<L7>},{3,} filter :-1 types:int
4 cleanup land:{2,<L2>}
remove_unreachable_handlers does
Eh tree:
1 allowed_exceptions land:{4,<L6>},{1,<L7>} filter :-1 types:int
4 cleanup land:{2,<L2>}
and cleanup_empty_eh
Eh tree:
1 allowed_exceptions land:{4,<L3>},{1,<L7>} filter :-1 types:int
4 cleanup
