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.)

Reply via email to