Re: Problem with accessing built-ins from Fortran front-end
On Fri, 26 Sep 2014, Jakub Jelinek wrote:
> > One related question: the __builtin_signbit is not type generic, is there
> > any reason for it not to be? Is there any reason for it not to be? I ask
>
> I guess history, builtins that were added earlier when we didn't have any
> typegeneric builtins were all *{f,,l} etc. suffixed.
> As they are used quite heavily in user code, it is too late to change that.
I see no reason not to make __builtin_signbit type-generic, and think such
a change would be a good idea (PR 36757).
> Just look at what glibc does for years:
> /* Return nonzero value if sign of X is negative. */
> # ifdef __NO_LONG_DOUBLE_MATH
> # define signbit(x) \
> (sizeof (x) == sizeof (float) ? __signbitf (x) : __signbit (x))
> # else
> # define signbit(x) \
> (sizeof (x) == sizeof (float) \
> ? __signbitf (x) \
> : sizeof (x) == sizeof (double) \
> ? __signbit (x) : __signbitl (x))
> # endif
> We can't stop supporting that.
Such code would be completely unaffected by __builtin_signbit being made
type-generic. It would continue to work, but future glibc versions could
just use __builtin_signbit conditional on a suitable __GNUC_PREREQ check,
so eliminating a function call (on architectures not already defining
__signbit etc. in bits/mathinline.h) and avoiding the macro expanding its
argument more than once (something that causes exponential blowup of the
source code size when nested macro calls are involved).
It's true that code using __builtin_signbit on a long double argument
would lose the conversion to double (not affecting the result, but
possibly losing exceptions arising from the conversion) and similarly
calls for a float argument would also lose the conversion to double (so
losing exceptions for signaling NaN arguments). In view of the many open
bugs relating to floating-point exceptions, I don't think such changes
would be problematic.
--
Joseph S. Myers
jos...@codesourcery.com
Re: Problem with accessing built-ins from Fortran front-end
On Fri, Sep 26, 2014 at 11:07:28AM +0200, FX wrote:
> > Thus, the middle-end assumes that if you have __builtin_{isfinite,isnormal},
> > you also have __builtin_is{less,greater}equal builtins too.
>
> Many thanks to both of you! I wasn’t looking into the right place at all. I
> defined them, and now it works.
>
> One related question: the __builtin_signbit is not type generic, is there
> any reason for it not to be? Is there any reason for it not to be? I ask
I guess history, builtins that were added earlier when we didn't have any
typegeneric builtins were all *{f,,l} etc. suffixed.
As they are used quite heavily in user code, it is too late to change that.
Just look at what glibc does for years:
/* Return nonzero value if sign of X is negative. */
# ifdef __NO_LONG_DOUBLE_MATH
# define signbit(x) \
(sizeof (x) == sizeof (float) ? __signbitf (x) : __signbit (x))
# else
# define signbit(x) \
(sizeof (x) == sizeof (float) \
? __signbitf (x) \
: sizeof (x) == sizeof (double) \
? __signbit (x) : __signbitl (x))
# endif
We can't stop supporting that.
Jakub
Re: Problem with accessing built-ins from Fortran front-end
> Thus, the middle-end assumes that if you have __builtin_{isfinite,isnormal},
> you also have __builtin_is{less,greater}equal builtins too.
Many thanks to both of you! I wasn’t looking into the right place at all. I
defined them, and now it works.
One related question: the __builtin_signbit is not type generic, is there any
reason for it not to be? Is there any reason for it not to be? I ask for two
reasons: 1. it would make my life easier, and 2. it’s generated in the folding
of BUILT_IN_ISINF_SIGN, which is weird because the later is type generic.
Thanks again,
FX
Re: Problem with accessing built-ins from Fortran front-end
On Fri, Sep 26, 2014 at 10:29:57AM +0200, FX wrote:
> Hi,
>
> I’m trying to make the Fortran front-end emit calls to some builtins we don’t
> currently use (isfinite, isnormal). However, trying to use the same code as
> isnan doesn’t work at all. Our gfc_define_builtin does three things:
>
> decl = add_builtin_function (name, type, code, BUILT_IN_NORMAL,
> library_name, NULL_TREE);
> set_call_expr_flags (decl, attr);
> set_builtin_decl (code, decl, true);
>
> While doing so works with isnan, it fails with isfinite or isnormal. When I
> try to, I get an ICE in tree checking:
>
> * frame #0: 0x000100c02338 f951`build_call_expr_loc_array(loc=0,
> fndecl=0x, n=2, argarray=0x7fff5fbfeb20) + 24 at
> tree.h:2846
> frame #1: 0x000100c0259a f951`build_call_expr(fndecl=,
> n=) + 186 at tree.c:10550
> frame #2: 0x00010046f671
> f951`fold_builtin_interclass_mathfn(loc=, fndecl=,
> arg=0x00014340c990) + 337 at builtins.c:9393
> frame #3: 0x000100485e34 f951`fold_builtin_1(loc=260,
> fndecl=0x000143449360, arg0=0x00014340c990, ignore=) +
> 2964 at builtins.c:10050
> frame #4: 0x00010049030c f951`fold_builtin_n(loc=,
> fndecl=, args=, nargs=,
> ignore=) + 1116 at builtins.c:10409
> frame #5: 0x000100491c33 f951`fold_builtin_call_array(loc=260,
> type=0x000143405690, fn=0x00014351fc40, n=1,
> argarray=0x7fff5fbfeeb0) + 355 at builtins.c:10575
> frame #6: 0x000100c024c5 f951`build_call_expr_loc(loc=,
> fndecl=, n=) + 181 at tree.c:10533
>
>
> I don’t understand how the middle-end builtins decl should work, would
> someone have a hint of how to fix this?
Just look what foold_builtin_interclass_mathfn does:
isfinite(x) -> islessequal(fabs(x),DBL_MAX)
isnormal(x) -> isgreaterequal(fabs(x),DBL_MIN) & islessequal(fabs(x),DBL_MAX)
Thus, the middle-end assumes that if you have __builtin_{isfinite,isnormal},
you also have __builtin_is{less,greater}equal builtins too.
Just create those too and you'll be fine (they are also typegeneric, like
__builtin_is{finite,normal}), i.e. they take ... arguments and the FE is
supposed to verify they are ok (or, if the FE creates them artificially, it
will ensure that too).
Jakub
Re: Problem with accessing built-ins from Fortran front-end
On Fri, Sep 26, 2014 at 10:29 AM, FX wrote:
> Hi,
>
> I’m trying to make the Fortran front-end emit calls to some builtins we don’t
> currently use (isfinite, isnormal). However, trying to use the same code as
> isnan doesn’t work at all. Our gfc_define_builtin does three things:
>
> decl = add_builtin_function (name, type, code, BUILT_IN_NORMAL,
> library_name, NULL_TREE);
> set_call_expr_flags (decl, attr);
> set_builtin_decl (code, decl, true);
>
> While doing so works with isnan, it fails with isfinite or isnormal. When I
> try to, I get an ICE in tree checking:
>
> * frame #0: 0x000100c02338 f951`build_call_expr_loc_array(loc=0,
> fndecl=0x, n=2, argarray=0x7fff5fbfeb20) + 24 at
> tree.h:2846
fndecl is NULL which means that fold_builtin_interclass_mathfn doesn't
expect only some of the classification builtins to exist. In this case
probably
CASE_FLT_FN (BUILT_IN_FINITE):
case BUILT_IN_ISFINITE:
{
/* isfinite(x) -> islessequal(fabs(x),DBL_MAX). */
tree const isle_fn = builtin_decl_explicit (BUILT_IN_ISLESSEQUAL);
You can either amend the transforms in builtins.c to check for
the availability of the decls (simply return NULL_TREE if !isle_fn)
or make sure the fortran frontend defines all of the FP classification
and compare builtins.
Richard.
> frame #1: 0x000100c0259a f951`build_call_expr(fndecl=,
> n=) + 186 at tree.c:10550
> frame #2: 0x00010046f671
> f951`fold_builtin_interclass_mathfn(loc=, fndecl=,
> arg=0x00014340c990) + 337 at builtins.c:9393
> frame #3: 0x000100485e34 f951`fold_builtin_1(loc=260,
> fndecl=0x000143449360, arg0=0x00014340c990, ignore=) +
> 2964 at builtins.c:10050
> frame #4: 0x00010049030c f951`fold_builtin_n(loc=,
> fndecl=, args=, nargs=,
> ignore=) + 1116 at builtins.c:10409
> frame #5: 0x000100491c33 f951`fold_builtin_call_array(loc=260,
> type=0x000143405690, fn=0x00014351fc40, n=1,
> argarray=0x7fff5fbfeeb0) + 355 at builtins.c:10575
> frame #6: 0x000100c024c5 f951`build_call_expr_loc(loc=,
> fndecl=, n=) + 181 at tree.c:10533
>
>
> I don’t understand how the middle-end builtins decl should work, would
> someone have a hint of how to fix this?
>
> Thanks,
> FX
>
>
> PS: the attached patch emits isfinite instead of isnan to test the built-in
> changes with minimal. With that patch, the Fortran source attached triggers
> the ICE above.
>
>
