Re: optimization/9736: same fp comparison can lead to different results

Re: optimization/9736: same fp comparison can lead to different results

[ebotcazou]

Synopsis: same fp comparison can lead to different results

State-Changed-From-To: feedback->suspended
State-Changed-By: ebotcazou
State-Changed-When: Wed Mar  5 07:46:15 2003
State-Changed-Why:
    Weird but nonetheless documented behaviour of GCC on x86.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9736

Re: optimization/9736: same fp comparison can lead to different results

[Richard Addison-Wood]

The following reply was made to PR optimization/9736; it has been noted by GNATS.

From: Richard Addison-Wood <richard@wetafx.co.nz>
To: richard@wetafx.co.nz, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org
Cc:  
Subject: Re: optimization/9736: same fp comparison can lead to different results
Date: Wed, 05 Mar 2003 16:17:29 +1300

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9736
 
 Why is the State of this Problem Report set to 'feedback'?

Re: optimization/9736: same fp comparison can lead to different results

[Richard Addison-Wood]

The following reply was made to PR optimization/9736; it has been noted by GNATS.

From: Richard Addison-Wood <richard@wetafx.co.nz>
To: richard@wetafx.co.nz, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org
Cc:  
Subject: Re: optimization/9736: same fp comparison can lead to different results
Date: Thu, 27 Feb 2003 20:37:25 +1300

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9736
 
 From various parts of the ISO/IEC C++ standard:
 
   5 Expressions
 
   ...
 
   Many binary operators that expect operands of
   arithmetic or enumeration type cause conversions
   and yield result types in a similar way. The
   purpose is to yield a common type, which is also
   the type of the result. This pattern is called
   the usual arithmetic conversions, which are
   defined as follows:
 
     If either operand is of type long double, the
     other shall be converted to long double.
 
     Otherwise, if either operand is double, the
     other shall be converted to double.
 
     Otherwise, if either operand is float, the
     other shall be converted to float.
 
     ...
 
   The values of the floating operands and the
   results of floating expressions may be
   represented in greater precision and range than
   that required by the type; the types are not
   changed thereby.  55)
 
   ...
 
   55) The cast and assignment operators must still
   perform their specific conversions as described
   in 5.4, 5.2.9 and 5.17.
 
 ...
 
   5.17 Assignment operators
 
   There are several assignment operators, all of
   which group right-to-left. All require a
   modifiable lvalue as their left operand, and the
   type of an assignment expression is that of its
   left operand. The result of the assignment
   operation is the value stored in the left
   operand after the assignment has taken place;
   the result is an lvalue.
 
   ...
 
   In simple assignment (=), the value of the
   expression replaces that of the object referred
   to by the left operand.
 
 ...
 
   4 Standard conversions
 
   ... A standard conversion sequence will be
   applied to an expression if necessary to convert
   it to a required destination type.
 
   [Note: expressions with a given type will be
   implicitly converted to other types in several
   contexts:
 
   -- When used as operands of operators. The
   operator's requirements for its operands dictate
   the destination type (clause 5).
 
   ...
 
   -- When used as the source expression for an
   initialization (which includes use as an
   argument in a function call and use as the
   expression in a return statement). The type of
   the entity being initialized is (generally) the
   destination type. See 8.5, 8.5.3.
 
   -- end note]
 
 ...
 
   4.8 Floating point conversions
 
   An rvalue of floating point type can be
   converted to an rvalue of another floating point
   type. If the source value can be exactly
   represented in the destination type, the result
   of the conversion is that exact
   representation. If the source value is between
   two adjacent destination values, the result of
   the conversion is an implementation-defined
   choice of either of those values. Otherwise, the
   behavior is undefined.
 
 
 
 
 Consider this small test program:
 
 // original.cc:
 int f(float x, float y, float z, float w)
 {
   float v = x*x+y*y+z*z+w;
   int test1 = v < 1.0f ? 1 : 2;
   return test1;
 }
 int main(void)
 {
   return f(0.5f, 0.5f, 0.5f, 0.25f-1.0f/67108864.0f);
 }
 
 The standard allows the intermediate calculations
 for v to be at greater precision than float,
 although the types are still considered to be
 float.  However, when v itself is initialized,
 there is an implicit standard conversion to float.
 Thus, we are allowed rewrite the small test
 program as this (where the types represent the
 actual precision):
 
 // transformed.cc:
 int f(float x, float y, float z, float w)
 {
   const long double temp_x = x;
   const long double temp_y = y;
   const long double temp_z = z;
   const long double temp_w = w;
   const long double temp_xx = temp_x*temp_x;
   const long double temp_yy = temp_y*temp_y;
   const long double temp_xxpyy = temp_xx+temp_yy;
   const long double temp_zz = temp_z*temp_z;
   const long double temp_xxpyypzz = temp_xxpyy+temp_zz;
   const long double temp_xxpyypzzpw = temp_xxpyypzz+temp_w;
   float v = temp_xxpyypzzpw;
   int test1 = v < 1.0f ? 1 : 2;
   return test1;
 }
 int main(void)
 {
   return f(0.5f, 0.5f, 0.5f, 0.25f-1.0f/67108864.0f);
 }
 
 I expect both programs to initialize v to 1.0f
 (and return 2 from f() and main()).  However, with
 -O1, original.cc is not compiled according to the
 standard.
 
 [Paradoxically, transformed.cc is compiled
 correctly with -O1.  The generated code is
 essentially the same except for transformed.cc
 that the proper conversion to float is generated
 for initializing v.]

Re: optimization/9736: same fp comparison can lead to different results

[Tim Prince]

The following reply was made to PR optimization/9736; it has been noted by GNATS.

From: Tim Prince <timothyprince@sbcglobal.net>
To: Eric Botcazou <ebotcazou@libertysurf.fr>,
   Richard Addison-Wood <richard@wetafx.co.nz>
Cc: gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9736: same fp comparison can lead to different results
Date: Wed, 19 Feb 2003 05:56:06 -0800

 On Wednesday 19 February 2003 01:02, Eric Botcazou wrote:
 > > If the compiler produces valid assembly code that does not
 > > correctly execute the input source code, that is a compiler bug.
 >
 > Sure. But why do you keep using a compilation mode that you know will
 > generate a faulty executable for your program? I can't say much more than
 > the GCC manual here: if your program relies on exact IEEE floating-point
 > semantics to properly work, compile it with -ffloat-store. Otherwise
 > eliminate the dependencies on the IEEE format.
 You might consider the options -march=pentium[34] -mfpmath=sse, or changing 
 the precision mode you run in, since you seem to want an alternative to 
 -ffloat-store to achieve those effects.
 -- 
 Tim Prince

Re: optimization/9736: same fp comparison can lead to different results

[Eric Botcazou]

The following reply was made to PR optimization/9736; it has been noted by GNATS.

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Richard Addison-Wood <richard@wetafx.co.nz>
Cc: gcc-bugs@gcc.gnu.org,
 nobody@gcc.gnu.org,
 gcc-gnats@gcc.gnu.org
Subject: Re: optimization/9736: same fp comparison can lead to different results
Date: Wed, 19 Feb 2003 10:02:14 +0100

 > If the compiler produces valid assembly code that does not
 > correctly execute the input source code, that is a compiler bug.
 
 Sure. But why do you keep using a compilation mode that you know will 
 generate a faulty executable for your program? I can't say much more than 
 the GCC manual here: if your program relies on exact IEEE floating-point 
 semantics to properly work, compile it with -ffloat-store. Otherwise 
 eliminate the dependencies on the IEEE format.
 
 -- 
 Eric Botcazou

Re: optimization/9736: same fp comparison can lead to different results

[Richard Addison-Wood]

The following reply was made to PR optimization/9736; it has been noted by GNATS.

From: Richard Addison-Wood <richard@wetafx.co.nz>
To: ebotcazou@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, richard@wetafx.co.nz, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/9736: same fp comparison can lead to different results
Date: Wed, 19 Feb 2003 11:12:55 +1300

 If the compiler produces valid assembly code that does not
 correctly execute the input source code, that is a compiler bug.

Re: optimization/9736: same fp comparison can lead to different results

[ebotcazou]

Synopsis: same fp comparison can lead to different results

State-Changed-From-To: open->feedback
State-Changed-By: ebotcazou
State-Changed-When: Tue Feb 18 08:04:35 2003
State-Changed-Why:
    What do you want GCC to do exactly in this case? It already provides an option to fix the problem.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9736

optimization/9736: same fp comparison can lead to different results

[richard]

>Number:         9736
>Category:       optimization
>Synopsis:       same fp comparison can lead to different results
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 17 23:16:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     richard@wetafx.co.nz
>Release:        g++3 (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
>Organization:
>Environment:
Linux 2.4.18-xfssmp #1 SMP i686
>Description:
//////////bug.cc:
void access(const float&) {}
int test(float t)
{
  float v = 0.75f+t;
  int test1 = v < 1.0f ? 1 : 2;
  int test2 = v < 1.0f ? 1 : 2;
  access(v);
  return test1*10+test2;
}
int main(void) { return test(0.25f-1.0f/67108864.0f); }
//////////GNUmakefile
bug: bug.cc; g++3 -O1 -o bug bug.cc
>How-To-Repeat:
With the two specified files, use gmake to build.

With -O1, the values computed for test1 and test2
are different while the source code is identical.
>Fix:
Can use the -ffloat-store option, but that is a mighty
big hammer.
>Release-Note:
>Audit-Trail:
>Unformatted: