On Tue, Dec 12, 2017 at 09:08:10AM +0100, Richard Biener wrote:
> On Mon, Dec 11, 2017 at 11:34 PM, Joseph Myers <jos...@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.

Isn't the const attribute on the testcase because besides the implicit
attributes for the builtin the testcase also has explicit attributes (const, 
nothrow)?

> 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]

Anyway, perhaps the builtins that are known not to be affected by rounding
mode should use a different macro?  We do have a macro for that already,
it is ATTR_MATHFN_ERRNO.

Any other functions that are using ATTR_MATHFN_FPROUNDING_ERRNO or
ATTR_MATHFN_FPROUNDING and aren't affected by fesetround?
I thought a little about ldexp*/scalb*/significand*, but looking at the
glibc implementation it uses e.g. for tiny or huge values floating point
multiplication and is thus affected by the rounding mode.
nextafter/nexttoward also perform floating point multiplication or addition,
but they evaluate it only for the exceptions, so shouldn't be affected by
the rounding mode.

So, ok for trunk?

2017-12-12  Jakub Jelinek  <ja...@redhat.com>

        * builtins.def (BUILT_IN_NEXTAFTER, BUILT_IN_NEXTAFTERF,
        BUILT_IN_NEXTAFTERL, BUILT_IN_NEXTTOWARD, BUILT_IN_NEXTTOWARDF,
        BUILT_IN_NEXTTOWARDL): Use ATTR_MATHFN_ERRNO instead of
        ATTR_MATHFN_FPROUNDING_ERRNO.

--- gcc/builtins.def.jj 2017-11-28 12:11:40.000000000 +0100
+++ gcc/builtins.def    2017-12-12 09:27:38.018787795 +0100
@@ -526,12 +526,12 @@ DEF_GCC_FLOATN_NX_BUILTINS (BUILT_IN_NAN
 DEF_C99_BUILTIN        (BUILT_IN_NEARBYINT, "nearbyint", BT_FN_DOUBLE_DOUBLE, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_NEARBYINTF, "nearbyintf", BT_FN_FLOAT_FLOAT, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_NEARBYINTL, "nearbyintl", 
BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
-DEF_C99_BUILTIN        (BUILT_IN_NEXTAFTER, "nextafter", 
BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
-DEF_C99_BUILTIN        (BUILT_IN_NEXTAFTERF, "nextafterf", 
BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
-DEF_C99_BUILTIN        (BUILT_IN_NEXTAFTERL, "nextafterl", 
BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
-DEF_C99_BUILTIN        (BUILT_IN_NEXTTOWARD, "nexttoward", 
BT_FN_DOUBLE_DOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
-DEF_C99_BUILTIN        (BUILT_IN_NEXTTOWARDF, "nexttowardf", 
BT_FN_FLOAT_FLOAT_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
-DEF_C99_BUILTIN        (BUILT_IN_NEXTTOWARDL, "nexttowardl", 
BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
+DEF_C99_BUILTIN        (BUILT_IN_NEXTAFTER, "nextafter", 
BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_ERRNO)
+DEF_C99_BUILTIN        (BUILT_IN_NEXTAFTERF, "nextafterf", 
BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_ERRNO)
+DEF_C99_BUILTIN        (BUILT_IN_NEXTAFTERL, "nextafterl", 
BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_ERRNO)
+DEF_C99_BUILTIN        (BUILT_IN_NEXTTOWARD, "nexttoward", 
BT_FN_DOUBLE_DOUBLE_LONGDOUBLE, ATTR_MATHFN_ERRNO)
+DEF_C99_BUILTIN        (BUILT_IN_NEXTTOWARDF, "nexttowardf", 
BT_FN_FLOAT_FLOAT_LONGDOUBLE, ATTR_MATHFN_ERRNO)
+DEF_C99_BUILTIN        (BUILT_IN_NEXTTOWARDL, "nexttowardl", 
BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_ERRNO)
 DEF_LIB_BUILTIN        (BUILT_IN_POW, "pow", BT_FN_DOUBLE_DOUBLE_DOUBLE, 
ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_POW10, "pow10", BT_FN_DOUBLE_DOUBLE, 
ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_POW10F, "pow10f", BT_FN_FLOAT_FLOAT, 
ATTR_MATHFN_FPROUNDING_ERRNO)

        Jakub

Reply via email to