🚀 go-pugleaf

This is a summary of responses I received to my post.  On August 13, 1995, 
Irv Lustig <irv@dizzy.cplex.com> (that's me!) wrote:
>
>I'm having a disagreement with a compiler vendor (who shall remain nameless)
>for the Intel 386/486/Pentium as to whether the following is allowed by the C
>standard.  
>
>The issue is as follows:
>The vendor does a double precision calculation and stores the result in a
>floating point register, which is 80 bits long.  This result is then used in a
>second calculation, so the arithmetic is done in extended precision.  Then the
>result is stored in a variable of type "double" by doing truncation.
>
>You end up with the following odd situation, which I claim is illegal:
>
>a = b (64-bit binary representations are the same)
>c = d (64-bit binary representations are the same)
>
>but  (a + c) != (b + d)
>
>This happens because a and c were each arrived at by computations that are
>stored temporarily in a register, so their internal representation (80 bits
>each) during the course of the calculation was different.  Hence, a and c are
>added in extended precision, and the extra 16 bits influence the result.
>
>In essence, the vendor has promoted the variables a and c to long double, but
>it's not clear to me that they are allowed to do that, according to the ANSI C
>standard.
>
>So, is this allowed?  If so, can someone point me to the section in the ANSI C
>standard that describes this?
>
***Stuff deleted***

Below is part of the actual code that demonstrated the problem:

>  x = x + x1*x1;
>  z = y*y;
>  sum = x + z;     /* x and z are in registers, so sum is computed in 80 bits
>*/
>  sm2 = x3 + x4;

And here is part of the output

>x and x3 are equal
>z and x4 are equal
>the sums (x+z) and (x3+x4) are not equal

The question regarding the standard here is whether x and z, which are computed
in 80 bit precision, must be truncated to 64 bits before the variable sum is
computed.

In the e-mails I received, I received mixed opinions.  The parts of the
standard that were quoted were:

> ANSI C describes this in paragraph 3.2.1.5 where one can read at the end:
>  
> =====================================================================
> The values of floating operands and of the results of floating
> expressions may be represented in greater precision and range than
> required by the type; the types are not changed thereby.
> =====================================================================
>  
> Then a footnote reads:
>  
> =====================================================================
> The cast and assignment operators still must perform their specified
> conversions, as described in 3.2.1.3 and 3.2.1.4
> =====================================================================
> 
It seems to me that the footnote indicates that the values of x and z must be
converted to 64 bits before computing  sum = x + z.   So the vendor is wrong in
claiming what they are doing is allowed by the standard.  However, they do have
an option to turn off this behavior - it's just poorly documented.

I studied the vendor's assembly code, and when using this option, the compiler
(as expected) generates slower code, since x and z must be stored in memory,
and then retrieved from memory before being used to compute x and z.

Thanks to all who responded.  If anyone has any followup to this post, please
also send me a copy via e-mail, as I am not a regular reader of this newsgroup.

        -Irv Lustig                          irv@dizzy.cplex.com
        Director of Numerical Optimization
        CPLEX Optimization, Inc.             http://www.cplex.com/