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