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
jos...@codesourcery.com
