Float problen running i386 inary on amd64

Peter Jeremy peterjeremy at optushome.com.au
Fri Nov 16 12:35:15 PST 2007

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("NOT Equal");
    return (0);
jashank% cc -O2 -fno-strict-aliasing -pipe -march=athlon  y.c  -static -o y
jashank% ./y
jashank% /sbin/sha256 y
SHA256 (y) = d44fe8c4c4b4beab6125ba603f2a34fa4d0280ff04d697e22594debf9efc9a1a

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

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

More information about the freebsd-stable mailing list