Since we upgraded to redhat 9 I don't remember ever running the
confidence tests. But I just did and noticed that HalfTest fails
while testing the bit-patterns:
nan 0 11111111 10000000000000000000000 0 11111
1000000000
nan 0 11111111 10000000000000000000000
error: expected 0 11111 1111111111, got 0 11111 1000000000
I don't think the problem is that the float->half->float conversions
are wrong, but rather that the test is producing the wrong 32 bit float
bit-pattern to begin with in the floatPosQNan1() routine. Well, the
bit-pattern it produces is still technically a nan, but just not what
the test program is expecting.
I narrowed down the issue to a problem with gcc-322 when using -O2
optimizations. If you compile the attached source using
g++ testNan.cpp -o testNan
and execute it you will see that both the int and float bit patterns
are the same. But if you compile it with -O2 and then run it, the
bit patterns are different.
Again, this is using redhat 9 with gcc-322. If I use gcc-332 then
the problem goes away.
Is anybody else experiencing this?
Thanks.
--Ken
#include <float.h>
#include <iostream>
#include <string.h>
#include <assert.h>
using namespace std;
union uif
{
unsigned int i;
float f;
};
void
printBits (ostream &os, float f)
{
uif x;
x.f = f;
for (int i = 31; i >= 0; i--)
{
os << (((x.i >> i) & 1)? '1': '0');
if (i == 31 || i == 23)
os << ' ';
}
}
void
printBits (ostream &os, unsigned int ui)
{
for (int i = 31; i >= 0; i--)
{
os << (((ui >> i) & 1)? '1': '0');
if (i == 31 || i == 23)
os << ' ';
}
}
int
main( int argc, char **argv )
{
uif x;
x.i = 0x7fffffff;
cout << "x.i = " << x.i << " ";
printBits( cout, x.i );
cout << endl;
cout << "x.f = " << x.f << " ";
printBits( cout, x.f );
cout << endl;
return 0;
}
_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel