Re: FLOATING-POINT CONSISTENCY, -FFLOAT-STORE, AND X86

[Joe Buck <jbuck at Synopsys dot COM>]

N8TM@aol.com writes:

> burley@gnu.org writes:

No, Craig didn't write what you quote, I did:

>  >... avoids transformations that can change numerical results,
>  >such as pre-evaluating expressions with 64-bit that would otherwise
>  >be evaluated using 80-bit precision at runtime >>

N8TM again:

> A good point.  Among other things, this will require a good strtold (?)
> conversion from decimal to binary, which I don't think is available.

No, it suffices to read the constants the user provided as double if they
are double precision literals.  And if the compiler
supports long double it already has the "strtold" equivalent.

> At least this needs some planning.

What it means is that the compiler would need to evaluate constant
expressions using long double, and store them in the executable as long
double, in any case where the unoptimized code would do this on the
same processor.

That is, if we have (yes, this is a contrived example)

double one_third(double z)
{
	double x, y;
	x = 1.0;
	y = 3.0;
	return z * (x / y);
}

if x, y, and z are in registers, we will compute an 80-bit approximation
to 1/3.  If the compiler changed this to

double one_third(double z)
{
	return z * 0.33333333333333333;
}

we have a 64-bit approximation to 1/3.  The compiler must instead produce

double one_third(double z)
{
	return z * 0.3333333333333333333333L;
}

to make the results invariant under optimization.