This is the mail archive of the
mailing list for the GCC project.
Re: Converting floor to rint
> Andreas Schwab <firstname.lastname@example.org> writes:
> | Gabriel Dos Reis <email@example.com> writes:
> | |> "may" part refers to the fact whether the programmer might want
> | |> to run rint() under a particular floating-point control mode that
> | |> would permit rint() to raise the inexact exception.
> | |> rint() cannot unconditionally set it. If FENV_ACCESS is on and
> | |> FE_INEXACT is supported then rint() should raise the exception if
> | |> appropriate. That is my understanding.
> | If the implementation defines __STDC_IEC_559__ then F.9.6.4 applies. I
> | have no copy of IEC 60559, but if it states that rint must raise the
> | exception then it must do it independent of FENV_ACCESS.
Yes, IEC seems to be clear about the trap:
[#1] The rint functions differ from the nearbyint functions
only in that they do raise the ``inexact'' floating-point
exception if the result differs in value from the argument.
I would love to be enlightened about when this feature is usefull :) I
can't think of any use for it. Sadly most people use rint/lrint and not
nearbyint/lrint that are more consistent.
> My concern is this:
> F.7.1 Environment management
> [#1] IEC 60559 requires that floating-point operations
> implicitly raise floating-point exception status flags, and
> that rounding control modes can be set explicitly to affect
> result values of floating-point operations. When the state
> for the FENV_ACCESS pragma (defined in <fenv.h>) is ``on'',
> these changes to the floating-point state are treated as
> *side effects* which respect sequence points.304)
> (my emphasis)
So one can not consider rint as "attribute((const))" function and we can
not do that in strict mode.
> | Otherwise, if
> | __STDC_IEC_559__ is not defined, then no requirements on the exceptions
> | are stated for rint, since 220.127.116.11 does not have a "shall".
Can I detect somehow the cases when __STDC_IEC_559__ is not defined?
This seems to be done by glibc in all cases, even with -ffast-math.
Perhaps I can do the rint folding only with -ffast-math that would be
enought for majority of 3D software that is about the only case where we
get some oppurtunities for speedup from this transformations?
> -- Gaby