This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
- From: "ghazi at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Mar 2008 15:45:01 -0000
- Subject: [Bug middle-end/35509] [4.3/4.4 Regression] builtin isinf() mismatch to compile-time substitution
- References: <bug-35509-6291@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from ghazi at gcc dot gnu dot org 2008-03-08 15:45 -------
(In reply to comment #2)
> Note that one might argue that the testcase is invalid as as you say, C99 only
> says isinf returns non-zero. So strictly speaking comparing the return value
> of two invocations is not a way to check if both values are an infinity.
> Of course this is at least an QOI issue. The question is what behavior to
> retain? The glibc manpage documents returning -1 for -Inf and +1 for +Inf,
> which we could preserve on glibc targets then not expanding via
> isgreater(fabs(x),DBL_MAX).
When I wrote this, I was relying on the minimal C99 requirements, and Rth's
blessing here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30652#c2
One of my goals in writing these builtins was that GCC could always rely on the
inline expansion, perhaps allowing libc implementors to just define isinf into
the builtin. I'd like to keep that as much as possible.
So on glibc systems, instead of bypassing the expansion, perhaps we could
instead enhance it to return the sign dependent value using builtin signbit to
determine the sign and paste it (bitop it) into the result.
Another option would be to inline a variant of the ieee glibc isinf function
code which seems to be very small. I don't know how generic it is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35509