[PATCH]: Address PR middle-end/35509 by adding a separate isinf_sign builtin

[Kaveh R. Ghazi]

From: "Joseph S. Myers" <joseph@codesourcery.com>
> On Sun, 18 May 2008, Kaveh R. GHAZI wrote:
>
>> @@ -6294,8 +6295,10 @@ the same names as the standard macros (
>>  @code{islessgreater}, and @code{isunordered}) , with @code{__builtin_}
>>  prefixed.  We intend for a library implementor to be able to simply
>>  @code{#define} each standard macro to its built-in equivalent.
>> -In the same fashion, GCC provides @code{isfinite} and @code{isnormal}
>> -built-ins used with @code{__builtin_} prefixed.
>> +In the same fashion, GCC provides @code{isfinite}, @code{isinf_sign}
>> +and @code{isnormal} built-ins used with @code{__builtin_} prefixed.
>> +The @code{isinf} and @code{isnan} builtins appear both with and
>> +without the @code{__builtin_} prefix.
>
> This doesn't actually say what __builtin_isinf_sign does (that is, that it
> can be used to implement the standard isinf macro with particular rules
> for the sign of the return value).

Okay, I'll add something more to the docs.  Otherwise okay?


> Do we have a bug for __builtin_signbit not being type-generic (it's
> BT_FN_INT_DOUBLE)?  It's the odd one out of these built-in functions in
> not being usable directly to implement the standard macro

I'm not aware of a PR for this.  AFAICT, it happened because the signbit 
builtin was written before type-generic builtins (and attribute "type 
generic") were created.  (If this is fixed, we should also remember to 
remove the solaris_math_8 fixincludes hack.)  But I'd like to keep that 
separate from this patch.

> (although we
> don't have a built-in function at all for fpclassify, where the
> library-dependent FP_* return values complicate things).

Agreed, figuring out a clean solution was a source of frustration for me. 
Suggestions?

        Thanks,
        --Kaveh
--
Kaveh R. Ghazi