[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=35509

--- Comment #13 from Andrew Pinski  ---
See PR 35509 which added the _sign version and all.

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread amonakov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #12 from Alexander Monakov  ---
We can expand isinf{f,l} according to BSD semantics in a BSD-targeting
compiler, sure. But the functions are not defined by C or POSIX, so expanding
them that way when targeting GNU libc makes it a GCC bug, no?

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread rearnsha at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #11 from Richard Earnshaw  ---
(In reply to Richard Earnshaw from comment #10)
> additionally, gcc provides __builtin_isinf_sign() &c.  I suspect that if gcc

s/gcc/glibc/

> wants the compiler to respect its extended semantics for isinf, then its
> headers should arrange for the function to be remapped accordingly.
> 
> But that makes this a glibc bug.

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread rearnsha at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #10 from Richard Earnshaw  ---
additionally, gcc provides __builtin_isinf_sign() &c.  I suspect that if gcc
wants the compiler to respect its extended semantics for isinf, then its
headers should arrange for the function to be remapped accordingly.

But that makes this a glibc bug.

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread rearnsha at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #9 from Richard Earnshaw  ---
If you want to get the glibc implementation compile with -fno-builtin-isinff,
etc

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #8 from Andrew Pinski  ---
Netbsd's isinff does not require the -1:
https://man.netbsd.org/isinff.3

Looks like a glibc extension which really should just be removed as documented.

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #7 from Andrew Pinski  ---
(In reply to lukewang from comment #3)
> https://man7.org/linux/man-pages/man3/finite.3.html
> The isinf(), isinff(), and isinfl() functions return 1 if x is
> positive infinity, -1 if x is negative infinity, and 0 otherwise.
> 
> Why is this behavior inconsistent with that in the Linux manual?

Because they are wrong. And has always been wrong.

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread amonakov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
Why is this closed as invalid? POSIX and C do not the f/l-suffixed versions of
the isinf macro. We aren't allowed to expand it the same way as isinf.

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #5 from Richard Biener  ---
You want to look a thttps://man7.org/linux/man-pages/man3/fpclassify.3.html
btw.

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #4 from Richard Biener  ---
(In reply to lukewang from comment #3)
> https://man7.org/linux/man-pages/man3/finite.3.html
> The isinf(), isinff(), and isinfl() functions return 1 if x is
> positive infinity, -1 if x is negative infinity, and 0 otherwise.
> 
> Why is this behavior inconsistent with that in the Linux manual?

It's consistent with C99 requirements.  Possibly POSIX requires the negative
return value, but I didn't check.

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread 314575546 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #3 from lukewang <314575546 at qq dot com> ---
https://man7.org/linux/man-pages/man3/finite.3.html
The isinf(), isinff(), and isinfl() functions return 1 if x is
positive infinity, -1 if x is negative infinity, and 0 otherwise.

Why is this behavior inconsistent with that in the Linux manual?

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread rearnsha at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

Richard Earnshaw  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Richard Earnshaw  ---
See comment from Uros

[Bug c/123987] isinfl isinff incorrectly for x86 and arm64

2026-02-05 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123987

--- Comment #1 from Uroš Bizjak  ---
https://cppreference.com/w/c/numeric/math/isinf.html

Return value:
Nonzero integral value if arg has an infinite value, ​0​ otherwise.