This is the mail archive of the gcc@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: nexttoward/nextafter attribute question


On Mon, Dec 11, 2017 at 11:34 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 11 Dec 2017, Steve Ellcey wrote:
>
>> the attribute.  The other is why the function would be pure with
>> -fno-math-errno but const otherwise.  I would think that the -fno-math-errno
>> version would be const (stricter than pure) since it is not setting
>> errno.  Finally, how can I check if -frounding-mode is set in the compiler
>
> Using -fno-math-errno does not mean that a function does not set errno; it
> means that it's not required to set errno.  If it does set errno (in a
> case where permitted to do so), it's not const or pure and using those
> attributes is not valid.  Those attributes would imply that a read of
> errno before a call to the function could be moved after the call to the
> function, which is not true for these functions.

I had the impression that -fno-math-errno means the user isn't interested
in errno and thus is fine with any such hoisting being done which means
we can treat those functions as const.

I believe we use pure instead of const in the lazy attempt to make the
builtins ordered with respect to fesetround () which for GCC stores to
global memory and thus pure functions cannot be re-ordered around it
while const functions could.  You might call that stupid because it is
only a tiny bit of a "solution" for -frounding-math issues with respect
to code re-ordering.  But I believe we want to preserve that behavior.
[we could use other tricks like treating fesetround as returns-twice
which would work better but is a quite big hammer for optimization
purposes]

Richard.

> This is generally the case for more libm function than just these ones -
> it's incorrect and unsafe to have const / pure attributes on them for
> -fno-math-errno.  (It's safe if a particular implementation guarantees as
> part of its ABI that the function will never set errno - or if GCC will
> always inline the function for -fno-math-errno, as with sqrt on some
> architectures but not all.  And of course many libm functions do not have
> any domain / range / pole errors so should never set errno at all and can
> safely be considered const / pure.)
>
> Separately, specifically for the nextafter and nexttoward functions, Annex
> F specifies that they are independent of the rounding mode.  Thus it is
> not correct for anything about those functions' attributes to depend on
> -frounding-math.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com


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