https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
At least for #c1 (which can be simplified to:
void
foo (void)
{
for (unsigned i = 0; i == 0; i++)
;
}
), the problem is that __builtin_unreachable that was emitted by ivcanon pass
is marked const and so is __ubsan_handle_builtin_unreachable but __builtin_trap
is not.
Which means that __builtin_unreachable (looks ok) and
__ubsan_handle_builtin_unreachable (admittedly surprising) doesn't need
gimple_vdef nor gimple_vuse on it, but __builtin_trap needs it.
And ivcanon doesn't expect that and as it doesn't add the vdef manually, we
remain with something that needs SSA update but we don't ask for it in todo
flags.
At least for user calls of __builtin_trap, I think we need at least vuse on it,
unlike __builtin_unreachable for traps we do care about say stores to memory
before it so that one can investigate them, abort isn't const either.
For a noreturn function, it isn't clear if we need a vdef.
I'm afraid we need to at least investigate all the
gimple_build_builtin_unreachable callers.
E.g. in gimple-fold.cc, it calls gimple_move_vops, so if the old method call
wasn't const/pure, it will work properly, but if it was e.g. const, we won't
add it and will ICE similarly.
Perhaps one way out of this would be to use 2 different __builtin_trap
builtins, one as it is now that requires vops, and another one marked const for
the __builtin_unreachable turned into __builtin_trap which would be marked
const and wouldn't need vops (__builtin_unreachable_trap?) and expand both
builtins the same into RTL.
