https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93491
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
'const' and trapping/EH are distinct bits, and definiteily
tree/gimple_could_trap_p reports true for the 1 / i; stmt. Note that traps
are not considered a "side-effect" and thus passes just checking for
gimple_has_side_effects will not get this.
But traps in general are difficult beasts, and what to do when facing them
depends on the actual transform. In this case it is tree PRE hoisting the
g(0) call.
It's vn_reference_may_trap that handles calls optimistically:
/* Return true if the reference operation REF may trap. */
bool
vn_reference_may_trap (vn_reference_t ref)
{
switch (ref->operands[0].opcode)
{
case MODIFY_EXPR:
case CALL_EXPR:
/* We do not handle calls. */
case ADDR_EXPR:
/* And toplevel address computations never trap. */
return false;
but note that tree_could_trap_p for example only looks at the actual
call instruction, not at as to whether the called function execution
might trap. So calls need to be handled specially and we don't have
a way to test/record for whether a called function might trap.
