https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #14)
> > OK, so a division by zero is not invoking undefined behavior but is
> > well-defined and traps. And the idea is that -fnon-call-exceptions alone
> > carries this over to middle-end semantics? (I don't think it does that at
> > the moment, with or without the rev. in question)
>
> Why? It's exactly like any other trapping operation, see the numerous
> predicates in tree-eh.cc, most notably operation_could_trap_helper_p:
>
> switch (op)
> {
> case TRUNC_DIV_EXPR:
> case CEIL_DIV_EXPR:
> case FLOOR_DIV_EXPR:
> case ROUND_DIV_EXPR:
> case EXACT_DIV_EXPR:
> case CEIL_MOD_EXPR:
> case FLOOR_MOD_EXPR:
> case ROUND_MOD_EXPR:
> case TRUNC_MOD_EXPR:
> if (!TREE_CONSTANT (divisor) || integer_zerop (divisor))
> return true;
It's used for a different purpose as well, we of course have to avoid moving a
possibly trapping operation to a place where it was not executed
unconditionally.
But sure, so you say that -fnon-call-exceptions makes operations that
may trap according to the EH machinery well-defined, irrespective of what
the language standards say? That certainly makes sense, it doesn't
make sense to create EH when the situation invokes undefined behavior.
(but as said above we have to avoid traps in non-EH context as well)
