https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96371
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Wed, 29 Jul 2020, vries at gcc dot gnu.org wrote: > Anyway, in absence of all this, without fenv.h support there's no way to set > the rounding mode, meaning that we can assume default rounding mode, as the > current implementation of "div<mode>3" does. OTOH, we don't take that > assumption further, f.i. we don't ignore frounding-math. Ignoring -frounding-math and -ftrapping-math would generically make sense for most software floating-point configurations (not powerpc-linux-gnu) as well because those don't support rounding modes and exceptions. It would probably require various testsuite updates to mark testcases that depend on rounding mode / exception support and test assumptions that are only valid when those are available. (Tests requiring such support at execution time should already be appropriately conditional. But compile-time tests of optimzations may well just assume the particular set of optimizations enabled that the given options yield at present.) Compile-time warning for such options seems less helpful, e.g. glibc just builds with -frounding-math everywhere including configurations with software floating point (and the handful of libm functions that depend on being able to set FE_TOWARDZERO internally have different implementations used in the software floating point case). Calling fesetround in such a glibc configuration results in a link-time warning for the unimplemented function (which succeeds at runtime when FE_TONEAREST is passed, fails if any other value is passed). When an instruction set supports rounding modes specified in instructions, that's a natural match for the TS 18661 / C2x FENV_ROUND pragma (but note the complications around how that's supposed to affect calls to certain standard library functions only, only when macro replacement has not been suppressed for those calls). However, implementation of that pragma for such architectures would be rather different from implementations for architectures where it's necessary to insert dynamic rounding mode changes (inlined, to avoid introducing libm dependencies for fesetround). (A third case is where there are multiple dynamic rounding modes that can be set independently and an instruction can choose which one to use, but I don't know if any architectures more modern than ia64 do that.)
