Re: Adding isinfl() and isnanl()

Corinna Vinschen <[email protected]> Sat, 7 Feb 2026 10:45:54 +0100
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
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?


Corinna