Re: Adding isinfl() and isnanl()

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
>