This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Converting floor to rint


> Andreas Schwab <schwab@suse.de> writes:
> 
> | Gabriel Dos Reis <gdr@integrable-solutions.net> 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 7.12.9.4 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?

Honza
> 
> Agreed.
> 
> -- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]