https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, what seems to happen is that we have at the end of ehcleanup2:
After removal of unreachable regions:
Eh tree:
1 cleanup land:{5,<L29>},{4,<L30>}
7 must_not_throw
2 cleanup land:{3,<L24>}
3 cleanup land:{2,<L20>}
4 cleanup land:{1,<L19>}
...
<L19>:
MEM[(struct basic_streambuf *)this_3(D) + 8B]._vptr.basic_streambuf =
&MEM[(void *)&_ZTV15basic_streambuf + 16B];
resx 4
<L20>:
...
Then resx lowering pass lowers this into:
...
<L19>:
MEM[(struct basic_streambuf *)this_3(D) + 8B]._vptr.basic_streambuf =
&MEM[(void *)&_ZTV15basic_streambuf + 16B];
__builtin_eh_copy_values (3, 4);
<L20>:
...
and finally remove_unreachable_handlers called during optimize pass removes the
EH 3 region (supposedly because the EH 4 cleanup now falls thru into the L20
landing pad?). And during expansion we ICE when trying to expand the
__builtin_eh_copy_values call, as the region 3 has been removed as unreachable.
So, shall remove_unreachable_handlers consider __builtin_eh_copy_values as
uses, something else? Richard, any ideas?
