Re: Adding isinfl() and isnanl()

Joel Sherrill <[email protected]> Mon, 9 Feb 2026 08:49:13 -0600
Newsgroups gmane.comp.lib.newlib
Message-ID <CAF9ehCXdy1U64_ucT2DpbS_wB0yDoWY==8G1TX0_LhCHeR=Dxw@mail.gmail.com>
I went looking for a permissively licensed implementation over the weekend
and found this:

https://github.com/JuliaMath/openlibm/blob/master/src/s_isinf.c

Is that OK to add to libm/common?

If that's OK, would the cygwin guard on isinf*() in math.h just get deleted?

--joel

--joel

On Sat, Feb 7, 2026 at 4:57 PM Joel Sherrill <[email protected]>
wrote:

>
>
> On Sat, Feb 7, 2026 at 1:52 PM Brian Inglis <
> [email protected]> wrote:
>
>> 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.
>>
>
> And that's the rub. The library call is not there for newlib.
>
> --joel
>
>>
>> --
>> 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
>>
>