https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127908
--- Comment #2 from oo.hehir at gmail dot com --- The conversion is an UNSPEC with an integer result. In riscv.md (master 2c7bb56592f6), l<round_pattern><ANYF:mode>di2 is: (set (reg:DI) (unspec:DI [(reg:DF)] ROUND)) RISC-V does not define TARGET_UNSPEC_MAY_TRAP_P, so may_trap_p_1 falls back to default_unspec_may_trap_p, which treats an UNSPEC as trapping only when its own mode is a float mode. Here the mode is DImode & the only operand is a register, so it returns 0, even under -ftrapping-math. At a guess (unverified, from reading the source, not from scheduler dumps) that is what lets sched1 (the first scheduling pass) move the fcvt above the range check. If so, any target that represents a float-to-int conversion as an integer-mode UNSPEC would get the same result from the default hook. numpy relies on the FP exception flags, which is how this showed up, in test_unary_spurious_fpexception.
