https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90993
--- Comment #4 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> --- I've looked at this issue some more. 1. rounding modes: I can't think of any way how different floating-point rounding modes could break this. There are always extra bits in the fp significand, so that rounding of inexact results won't have an effect on subsequent truncation. 2. -fno-trapping-math: This one is unfortunate. I agree that spurious FE_INEXACT from integer operations is not really correct. But then again in most programs, FE_INEXACT is simply always raised anyway. FE_INEXACT matters in verification of fp algorithms that are intended to be exact. To continue to support these use cases, using fp div must be gated on some flag or there must be a local inhibitor for the transformation. From my perspective, the underlying issue here might be one of defaults: Maybe -fno-trapping-math should be the default for most users (and then warn on calls to the corresponding library functions if no-trapping-math is active). 3. -freciprocal-math: If an optimization pass before pass_cse_reciprocals turns integer division into fp division, results are actually wrong. Either, the fp division must be marked as "don't-reciprocal-math-me", or it must be ordered after pass_cse_reciprocals, or it goes into the backend.
