John Maddock wrote:
Johan Råde wrote:
Win32 / Intel 7.? / ia32
where: basic_test<float> line 242 what: !isinf(signalling_NaN()) why: broken numeric_limits<T>::signaling_NaN
Not sure about that: the std lib is the same as that used by VC6, however these are both old compilers now, so maybe ignor this one for now (your code doesn't compile on VC6 anyway).
I'm quite sure. Which of the following two facts are you not sure about? ;-) Fact 1: numeric_limits<float>::signaling_NaN on Win32/Intel 7/ia32 returns a number with binary expansion ff 80 00 00 Fact 2: Under the IEEE754 standard, ff 80 00 00 is the binary expansion of single precision negative infinity. I will disable the signaling_NaN tests on Intel <= 7.
HP-UX / aCC / ia64
where: basic_test<float> line 122 what: fpclassify(-denorm_min()) == FP_SUBNORMAL why: multiple definitions of FP_SUBNORMAL ?
I suspect that the negation of the denorm causes it to round down to zero maybe?
I agree. Your suggestion 4 below should take care of that.
Linux / Intel 9.1 / ia64
where: basic_test<float> line 139 what: fpclassify(min()/2) == FP_SUBNORMAL why: broken numeric_limits<T>::min ?
My suspicion would be that:
x = (std::numeric_limits<T>::min)() / 2;
either underflows to zero, or is evaluated by the compiler at compile time maybe?
I agree. Your suggestion 4 below should take care of that.
Could you run the inspect tool on the last two platforms as well?
Here's HP-UX:
[snip]
And Intel on Linux/IA64
[snip] The results are as expected.
Can I make a couple of suggestions with respect to your test program?
1) It would be useful if the asserts were changed to something that didn't abort so we could see all the possible failures at once. 2) It would be useful if failed tests printed out the binary representation of the failed value (merge the inspect tool into the test. 3) It would help to check whether numeric_limits::has_infinity/has_denorm etc is true before testing those features. 4) It might pay to sanity check that denorm test values aren't zero or >= numeric_limits<>::min() before using them. That would catch out clever compilers right away: there's no point in testing for a denorm if the value isn't a denorm! :-)
I agree with all 4 suggestions. And time spent building good tools usually pays off. I will do 3 and 4, and add -denorm_min and min/2 to the inspect tool today. I will do 1 and 2 later. --Johan