[Bug 28810] d3dx9_36/tests/mesh.ok: D3DXLoadMeshTest fails under valgrind
wine-bugs at winehq.org
wine-bugs at winehq.org
Sat Nov 19 07:34:35 CST 2011
http://bugs.winehq.org/show_bug.cgi?id=28810
--- Comment #2 from Dan Kegel <dank at kegel.com> 2011-11-19 07:34:35 CST ---
I'm not sure this is related. I reduced your case to
#include <stdio.h>
int main(int argc, char **argv)
{
int ivalue = 0x1ffffff;
float res = ivalue;
printf("%f %f\n", res, (float)ivalue);
}
$ gcc -m32 buggy8.c
$ ./a.out
33554432.000000 33554431.000000
$ gcc -m64 buggy8.c
$ ./a.out
33554432.000000 33554432.000000
$ gcc -mfpmath=387 -m64 buggy8.c
$ ./a.out
33554432.000000 33554431.000000
$ gcc -mfpmath=387 -ffloat-store -m64 buggy8.c
$ ./a.out
33554432.000000 33554432.000000
$ perl -e 'print 0x1ffffff'
33554431
So: single precision floats aren't big enough to hold
that integer precisely, but doubles are. You get the
value 33554432.000000 whenever you really go through
a single precision float. You get the value 33554431.000000
when the value stays as a double the whole way through,
which it will in 387 mode if the compiler doesn't see
any reason to reduce precision. I think.
You can get a mixed source and assembly listing if you want with
gcc -m32 -Wa,-adhln -g buggy8.c
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the wine-bugs
mailing list