Re: Problem with accessing built-ins from Fortran front-end

["Joseph S. Myers" <joseph at codesourcery dot com>]

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 <math.h> 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
joseph@codesourcery.com