On Sat, Nov 17, 2007 at 04:53:22AM +1100, Bruce Evans wrote:
>Behaviour like this should be expected on i386 but not on amd64. It
>gives the well-known property of the sin() function, that sin(x) != sin(x)
>for almost all x (!). It happens because expressions _may_ be evaluated
>in extra precision (this is perfectly standard), so identical expressions
>may sometimes be evaluated in different precisions even, or especially,
>if they are on the same line.
Thank you for your detailed analysis. Hwever, I believe you missed
the critical point (I may have removed too much reference to the
actual problem that Pete French saw): I can take a program that was
statically compiled on FreeBSD/i386, run it in legacy (i386) mode on
FreeBSD-6.3/amd64 and get different results.
Another (admittedly contrived) example:
jashank% uname -a
FreeBSD jashank.vk2pj.dyndns.org 6.1-STABLE FreeBSD 6.1-STABLE #15: Wed Aug 2 18:35:57 EST 2006 root at jashank.vk2pj.dyndns.org:/usr/obj/usr/src/sys/jashank i386
jashank% cat y.c
#include <stdio.h>
double one = 1.0;
double three = 3.0;
double third = 1.0/3.0;
int main(int argc, char **argv)
{
if (one/three == third)
puts("Equal");
else
puts("NOT Equal");
return (0);
}
jashank% cc -O2 -fno-strict-aliasing -pipe -march=athlon y.c -static -o y
jashank% ./y
Equal
jashank% /sbin/sha256 y
SHA256 (y) = d44fe8c4c4b4beab6125ba603f2a34fa4d0280ff04d697e22594debf9efc9a1a
jashank%
turion% uname -a
FreeBSD turion.vk2pj.dyndns.org 6.2-STABLE FreeBSD 6.2-STABLE #30: Tue Jul 31 20:29:49 EST 2007 root at turion.vk2pj.dyndns.org:/usr/obj/usr/src/sys/turion amd64
turion% scp -p jashank:y .
y 100% 146KB 145.9KB/s 00:00
turion% /sbin/sha256 y
SHA256 (y) = d44fe8c4c4b4beab6125ba603f2a34fa4d0280ff04d697e22594debf9efc9a1a
turion% ./y
NOT Equal
turion%
This is identical code being executed in supposedly equivalent
environments giving different results.
I believe the fix is to initialise the FPU using __INITIAL_NPXCW__ in
ia32_setregs(), though I'm not sure how difficult this is in reality.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20071116/d1cf0398/attachment.pgp