Kaveh R. Ghazi wrote:
Great, we're making progress.
On mainline only (not 4.2 or prior) does this work instead?
Yep, trunk.
[ultra10:gcc/testsuite/gcc.dg] andreast% diff -u
/usr/include/iso/math_c99.h.orig /usr/include/iso/math_c99.h
--- /usr/include/iso/math_c99.h.orig Mon Feb 4 21:55:29 2008
+++ /usr/include/iso/math_c99.h Tue Feb 5 22:54:34 2008
@@ -67,10 +67,14 @@
__builtin_isunordered(__x_n, __x_n); })
#endif
#undef isinf
+#if __GNUC__ >= 4
+#define isinf(x) __builtin_isinf(x)
+#else
#define isinf(x) __extension__( \
{ __typeof(x) __x_i = (x); \
__x_i == (__typeof(__x_i)) INFINITY || \
__x_i == (__typeof(__x_i)) (-INFINITY); })
+#endif
#undef isfinite
#define isfinite(x) __extension__( \
{ __typeof(x) __x_f = (x); \
#undef isinf
#define isinf(x) __builtin_isinf(x)
[ultra10:head/objdir/gcc] andreast% gmake
RUNTESTFLAGS='dg.exp=c99-math-*' check
=== gcc Summary ===
# of expected passes 6
How about this? (Can be run on any branch) Hopefully there are no
typos...
#undef isinf
#define isinf(x) __extension__( \
{ __typeof(x) __x_i = (x); ! isnan(__x_i) && \
(__x_i == (__typeof(__x_i)) INFINITY || \
__x_i == (__typeof(__x_i)) (-INFINITY)); })
[ultra10:gcc/testsuite/gcc.dg] andreast# diff -u
/usr/include/iso/math_c99.h.orig /usr/include/iso/math_c99.h
--- /usr/include/iso/math_c99.h.orig Mon Feb 4 21:55:29 2008
+++ /usr/include/iso/math_c99.h Tue Feb 5 23:01:37 2008
@@ -68,9 +68,9 @@
#endif
#undef isinf
#define isinf(x) __extension__( \
- { __typeof(x) __x_i = (x); \
- __x_i == (__typeof(__x_i)) INFINITY || \
- __x_i == (__typeof(__x_i)) (-INFINITY); })
+ { __typeof(x) __x_i = (x); ! isnan(__x_i) &&\
+ (__x_i == (__typeof(__x_i)) INFINITY || \
+ __x_i == (__typeof(__x_i)) (-INFINITY)); })
#undef isfinite
#define isfinite(x) __extension__( \
{ __typeof(x) __x_f = (x); \
gmake RUNTESTFLAGS='dg.exp=c99-math-*' check
=== gcc Summary ===
# of expected passes 6
Both tests were done on trunk, 4.3.
I might test on 4.2.x later tomorrow, if needed.
The __builtin_inf(x) style up above is what is done on mainline for
solaris10. The second one is what is done in the solaris11 system
header but I added a !isnan(x). I'm not sure which of these styles
makes the most sense to plug into fixincludes.
Another option would be to file a bug report with sun and have them fix
the header internally using one of these three methods. I think they'd
choose the latter as it should work with any gcc version, not just the
latest ones. But that's up to them. In fixincludes we're free to make
any choice we want for mainline and/or branches as needed.
Filing bugs is nice, but do not expect a fast solution. So, if _we_ need
a solution, we have to act. If opensolaris needs a solution, they have
to act.
Personally I'd like them to 'fix' the issue. Otherwise we're 'papering'
over an issue they have!?
Thoughts?
I'll give you feedback about 4.2.x later to tomorrow.
Thanks again,
Andreas
