https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #4) > I think the reason why it doesn't work is clear, call_can_make_abnormal_goto > on the vfork call is false, because it is leaf (and that is how glibc > declares vfork BTW) and ctrl_altering flag is initialized by > gimple_call_initialize_ctrl_altering based on that or if it is noreturn etc. > (nothing applies). > So, I think as discussed in another PR, I think we really should make if not > call_can_make_abnormal_goto at least gimple_call_initialize_ctrl_altering be > true for > RETURNS_TWICE calls. I think I'm going to revert r13-5965 since neither setjmp nor [v]fork alter control flow. They receive additional control flow. I'm not sure why we have abnormal edges into fork(), fork simply returns twice but you can't longjmp to it. It's probably the same reason we have them on setjmp - to avoid code motion across the call, though as you can't jump to it I wonder if that's necessary there. r13-5965 has the side-effect of removing the RTL side-effects as well, though that's probably only ->calls_setjmp, forks never had REG_SETJMP on them? That said, if we choose to set ctrl-altering for setjmp + fork (see PR108855 for the problem with that), we need to do that explicitely rather than relying on call_can_make_abnormal_goto as you say. I still prefer to revert the offending revision and see how to handle the indirect -> direct transform better (in the end reverting the assert in DCE will solve these ICEs for us and get us back to previous behavior)
