Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Nov 2007 12:54:29 +0000
From:      Pete French <petefrench@ticketswitch.com>
To:        peterjeremy@optushome.com.au
Cc:        stable@freebsd.org
Subject:   Re: Float problen running i386 inary on amd64
Message-ID:  <E1IseEn-000315-Uy@dilbert.ticketswitch.com>
In-Reply-To: <20071115062002.GK89746@server.vk2pj.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, Nov 02, 2007 at 10:04:48PM +0000, Pete French wrote:
> >	int
> >	main(int argc, char *argv[])
> >	{
> >        	if(atof("3.2") =3D=3D atof("3.200"))
> >                	puts("They are equal");
> >        	else
> >                	puts("They are NOT equal!");
> >        	return 0;
> >	}
>
> Since the program as defined above does not include any prototype for
> atof(), its return value is assumed to be int.  The i386 code for the
> comparison is therefore:

Sorry, I didn't bother sticking the include lines in when I sent it
to the mailing list as I assumed it would be ovious that you need
to include the prototypes! In the actual tests I did I included <stdio.h>
and <stdlib.h>, so the compiler did know the return type. The result is the
same, different behaviour when running the i386 binary on amd64.

> Note that this is comparing the %eax returned by each atof().  Since
> atof() actually returns a double in %st(0) and %eax is a scratch
> register, the results are completely undefined.

I just tried this with the actual code I used for the test (i.e. with the
header files included) and I get something a lot longer than the
assembler you posted. I don't really understand what it is doing as I don't
read 386 assembler, and it's not exactly self explanatory. But the error
is still there.

Interestingly, if you recode like this:

        double x = atof("3.2");
        double y = atof("3.200");
        if(x == y)
                puts("They are equal");
        else
                puts("They are NOT equal!");

Then the problem goes away! Glancing at the assembly code they both appear to
be doing the same thing as regards the comparison.

> Unfortunately, I can't explain why an i386 would be different to an amd64
> in i386 mode.

me neither :-(

So, this is a bug, yes ? but it is a bug in FreeBSD or not ?

-pete.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1IseEn-000315-Uy>