Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I've Cc'd bde@ because this relates to the FPU initialisation - which
he is the expert on.

On Thu, Nov 15, 2007 at 12:54:29PM +0000, Pete French wrote:
>> 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!

OK, sorry for the confusion.

>Interestingly, if you recode like this:
> double x =3D atof("3.2");
> double y =3D atof("3.200");
> if(x =3D=3D y)
> puts("They are equal");
> else
> puts("They are NOT equal!");
>Then the problem goes away! Glancing at the assembly code they both appear=

>be doing the same thing as regards the comparison.

The underlying problem is that the amd64 FPU is initialised to 64-bit
precision mode, whilst the i386 FPU is initialised to 53-bit precision
mode (__INITIAL_FPUCW__ in amd64/include/fpu.h vs __INITIAL_NPXCW__ in
i386/include/npx.h). It looks like the FPU is initialised during the
machine-dependent CPU initialisation and then inherited by subsequent
processes as they are fork()d. The fix is probably to explicitly
initialise the FPU for legacy mode processes on the amd64.

A work-around would be to call fpsetprec(FP_PD) (see )
at the start of main().

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.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v2.0.4 (FreeBSD)