Floating-point to integer conversions can be inexact or invalid (e.g., the latter due to overflow or NaN). However, since users of operation_could_trap_p infer the bool FP_OPERATION argument from the expression's type, FIX_TRUNC_EXPR is considered non-trapping here. This patch handles FIX_TRUNC_EXPR explicitly.
Floating-point extensions/truncations and integer to floating-point conversions are considered trapping via the default case, as their expressions have a floating-point type. I believe this is the correct behavior here, since floating-point extensions/truncations are clearly potentially trapping, and integer to floating-point conversions can be inexact for extreme integer values. Perhaps it's worth being explicit here too? I stumbled upon this behavior through ifcvt; see https://godbolt.org/z/h7qMc4ebx. There might be a simpler or better way to test this change, but I'm not sure. Bootstrapped and regtested on aarch64-linux-gnu. This change causes sve/pr96357.c to fail, as it can no longer be vectorized without fno-trapping-math. The PR is a failure involving SVE_STRICT_GP, so I'm hesitant to add that flag. I suspect we may want a better test for the issue fixed by commit 0eb5e901f6e2, if it is still relevant. Thanks Spencer Abson (1): middle-end: Fix operation_could_trap_p for FIX_TRUNC_EXPR .../gcc.dg/tree-ssa/ifcvt-fix-trunc-1.c | 18 ++++++++++++++++++ .../gcc.dg/tree-ssa/ifcvt-fix-trunc-2.c | 6 ++++++ gcc/tree-eh.cc | 5 +++++ 3 files changed, 29 insertions(+) create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ifcvt-fix-trunc-1.c create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ifcvt-fix-trunc-2.c -- 2.34.1
