Re: Adding isinfl() and isnanl()

On 2026-02-07 02:45, Corinna Vinschen wrote:
> On Feb  6 14:30, Brian Inglis wrote:
>> On 2026-02-05 17:53, Joel Sherrill wrote:
>>> On Thu, Feb 5, 2026 at 9:28 AM Corinna Vinschen <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>      On Feb  5 09:09, Joel Sherrill wrote:
>>>       > Hi
>>>       >
>>>       > math.h:123 has isinfl () and isnanl() as this:
>>>       > [...]
>>>       > The winsup implementation has them as simple wrappers for the
>>>       > corresponding built-in functions such as __builtin_isinf_sign().
>>>       >
>>>       > If I copied the winsup/ implementation and put each in a new file
>>>       > in newlib/libm so they are always available, is that OK?
>>>
>>>      Barring other problems, you should just move them out of winsup into
>>>      newlib.
>>>
>>>       > If so, any suggestions on location inside libm for simple wrappers
>>>       > for the corresponding builtin?
>>>
>>>      libm/common
>>>
>>>       > What would the conditional guard need to be? Just Cygwin and RTEMS?
>>>       > or more?
>>>
>>>      I think this would have to be target cpu dependent.
>>>
>>>       > Anything I am missing?
>>>
>>>      Is it a safe bet that these builtins are available as inline functions
>>>      on all supported target cpus and compilers?  Unimplemented builtins just
>>>      point to their corresponding C lib function, isn't it?
>>
>> You can use __has_builtin since gcc 10:
>>
>> 	$ info cpp __has_builtin		# gcc 13.4 4.2.9
>>
>> https://gcc.gnu.org/onlinedocs/gcc-13.4.0/cpp/_005f_005fhas_005fbuiltin.html
>>
>> $ info gcc 'C Extensions' 'Other Builtins'	# gcc 13.4 6.59
>>
>> https://gcc.gnu.org/onlinedocs/gcc-13.4.0/gcc/Other-Builtins.html
>>
>> Two paras above builtin_alloca:
>> https://gcc.gnu.org/onlinedocs/gcc-13.4.0/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005falloca
>>
>> ...
>> "GCC provides built-in versions of the ISO C99 floating-point comparison
>> macros that avoid raising exceptions for unordered operands.
>> They have the same names as the standard macros ( ‘isgreater’, ‘isgreaterequal’,
>> ‘isless’, ‘islessequal’, ‘islessgreater’, and ‘isunordered’) , with
>> ‘__builtin_’ prefixed.
>> *We intend for a library implementor to be able to simply ‘#define’ each
>> standard macro to its built-in equivalent.*
>> In the same fashion, GCC provides ‘fpclassify’, ‘isfinite’, ‘isinf_sign’,
>> ‘isnormal’ and ‘signbit’ built-ins used with ‘__builtin_’ prefixed.
>> The ‘isinf’ and ‘isnan’ built-in functions appear both with and without the
>> ‘__builtin_’ prefix.
>> With ‘-ffinite-math-only’ option the ‘isinf’ and ‘isnan’ built-in functions
>> will always return 0."
>>
>>> Thanks. This one comment makes me want to avoid doing this.
>>>
>>> I can easily test the ~15 RTEMS architectures but that leaves a lot
>>> I can't easily check. I will see if the code using this can be done a different
>>> way. Suggestions on that?
>>
>> Avoid target builtins?
> 
> What about platforms not implementing FP functions in silicon?

It does say that generating the builtin code is an optimization considered by 
the compiler, otherwise it degrades to the library function call.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry