Hi Kaveh,
Andreas Tobler wrote:
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.
Well, thinking about it again, if we want to have our test suite clean
then we probably have to fix the header. Grr, magic fixinclude.....
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.
Sigh, time goes by...
So, the first variant does not work as expected on 4.2.3 (I used the
release tree, but that should not matter).
The second variant does also pass (as expected) on 4.2.3 :)
I hope it might help.
Andreas
