Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

[Wolfgang Bangerth]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

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

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: omar beo <omarbeo@hotmail.com>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Subject: Re: optimization/10772: Result differences between debug and optmize
 libs on linux; and with sol/nt on optimize mode
Date: Wed, 14 May 2003 15:52:52 -0500 (CDT)

 > But this did not answer the original question, why I’m not getting the same 
 > results in the other platforms?
 
 Because x86 has a fundamentally broken floating point model with different 
 accuracy of floats in registers and in memory. x86 FP computations are 
 fundamentally unreliable if you're used to thinking in what "decent" 
 processors do.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 

Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

[omar beo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]

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

From: "omar beo" <omarbeo@hotmail.com>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, omarbeo@hotmail.com, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/10772: Result differences between debug and optmize libs on
 linux; and with sol/nt on optimize mode
Date: Wed, 14 May 2003 13:20:26 -0600

 Hi,
 I tried your suggestion, and build the libs using " -ffloat-store " flag.
 It is true that now "Optimized and debug compilations give the same result 
 on Linux".
 But this did not answer the original question, why I’m not getting the same 
 results in the other platforms?
 
 If you run the test I provided, you will see that the result should be 
 00005975 in every case, but it is not when i run on linux. Why?
 
 If you are getting the same number in every case, could you please send me 
 the compilation arguments you used?
 
 The results of the test:
 Linux: debug or optimize libs
 var_1: 00005975
 var_2: 00005974  ...... * should be 00005974
 var_3: 00005975
 var_4: 00005974  .........* should be 00005974
 var_5: 00005975
 
 While sol debug or optimize give:
 var_1: 00005975
 var_2: 00005975
 var_3: 00005975
 var_4: 00005975
 var_5: 00005975
 
 
 >From: bangerth@dealii.org
 >Reply-To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,  
 >nobody@gcc.gnu.org, omarbeo@hotmail.com, gcc-gnats@gcc.gnu.org
 >To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org,  
 >omarbeo@hotmail.com
 >Subject: Re: optimization/10772: Result differences between debug and 
 >optmize libs on linux; and with sol/nt on optimize mode
 >Date: 14 May 2003 15:14:49 -0000
 >
 >Synopsis: Result differences between debug and optmize libs on linux; and 
 >with sol/nt on optimize mode
 >
 >State-Changed-From-To: feedback->closed
 >State-Changed-By: bangerth
 >State-Changed-When: Wed May 14 15:14:48 2003
 >State-Changed-Why:
 >     Not a bug. Optimized and debug compilations give the same
 >     result is -ffloat-store is used. On NT, a similar accuracy
 >     truncation mechanism is used by default. On Solaris, all
 >     accuracy is 64bit.
 >
 >     W.
 >
 >http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10772
 
 _________________________________________________________________
 STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
 http://join.msn.com/?page=features/junkmail
 

Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

[omar beo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5122 bytes --]

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

From: "omar beo" <omarbeo@hotmail.com>
To: giovannibajo@libero.it, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, omarbeo@hotmail.com, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/10772: Result differences between debug and optmize libs on
 linux; and with sol/nt on optimize mode
Date: Wed, 14 May 2003 09:08:14 -0600

 Hi,
 This problem could be related to the Rounding as many suggested, but how 
 come I got different numbers between debug and optimize libs when I run on 
 linux?
 Why this code generates the same numbers on NT and Unix, but not on linux?
 
 Unfortunately, I wasn’t able to create an identical test case to the one i'm 
 currently testing, probably because this behavior only happened when you run 
 a large application and not just a small test case.
 But i included a simalr test case with a similar behavior.
 
 Could you look at the assembly code generated on debug and optimize mode, 
 and tell me if they are equivalent. Because they don't produce the same 
 numbers .
 
 Thank you.
 
 
 Here the C++ code:
 
 double this->factor;
 int this->GetP() {}
 int object::GetPS() {}
 
 double this->factor;
 int this->GetP() {}
 int object::GetPS()
 {
 double aa = (double)this->GetP() * this->factor;
 int bb = (int) aa;
 return bb;
 }
 
 Here the Assembly code generated in linux in optimize mode (O3):
 ===================
 .LFE223:
 .Lfe223:
         .size   _ZN17object9GetPSEv,.Lfe223-_ZN17object9GetPSEv
         .align 2
         .p2align 4,,15
 .globl _ZN17object13GetPSEv
         .type   _ZN17object13GetPSEv,@function
 _ZN17object13GetPSEv:
 .LFB224:
         pushl   %ebp
 .LCFI739:
         movl    %esp, %ebp
 .LCFI740:
         subl    $24, %esp
 .LCFI741:
         movl    %ebx, -4(%ebp)
 .LCFI742:
         movl    8(%ebp), %ebx
         movl    (%ebx), %eax
         movl    %ebx, (%esp)
         call    *220(%eax)
         pushl   %eax
         fildl   (%esp)
         addl    $4, %esp
         fmull   116(%ebx)
         fnstcw  -6(%ebp)
         movl    -4(%ebp), %ebx
         movzwl  -6(%ebp), %eax
         orw     $3072, %ax
         movw    %ax, -8(%ebp)
         fldcw   -8(%ebp)
         fistpl  -12(%ebp)
         fldcw   -6(%ebp)
         movl    -12(%ebp), %eax
         movl    %ebp, %esp
         popl    %ebp
         ret
 .LFE224:
 .Lfe224:
         .size   _ZN17object13GetPSEv,.Lfe224-_ZN1object13GetPSEv7
         .align 2
         .p2align 4,,15
 
 ===================
 Here the Assembly code generated in linux in optimize mode (O3):
 
 .LFE183:
 .Lfe183:
         .size   _ZN17object9GetPSEv,.Lfe183-_ZN17object9GetPSEv
         .align 2
 .globl _ZN17object13GetPSEv
         .type   _ZN17object13GetPSEv,@function
 _ZN17object13GetPSEv:
 .LFB184:
         .loc 1 5737 0
 .LBB414:
         pushl   %ebp
 .LCFI554:
         movl    %esp, %ebp
 .LCFI555:
         subl    $24, %esp
 .LCFI556:
         .loc 1 5739 0
         movl    8(%ebp), %eax
         movl    (%eax), %edx
         addl    $220, %edx
         movl    8(%ebp), %eax
         movl    %eax, (%esp)
         movl    (%edx), %eax
         call    *%eax
         pushl   %eax
         fildl   (%esp)
         leal    4(%esp), %esp
         movl    8(%ebp), %eax
         fmull   116(%eax)
         fstpl   -8(%ebp)
         .loc 1 5740 0
         fldl    -8(%ebp)
         fnstcw  -14(%ebp)
         movzwl  -14(%ebp), %eax
         orw     $3072, %ax
         movw    %ax, -16(%ebp)
         fldcw   -16(%ebp)
         fistpl  -12(%ebp)
         fldcw   -14(%ebp)
         .loc 1 5741 0
         movl    -12(%ebp), %eax
 .LBE414:
         pushl   %ebp
 .LCFI554:
         movl    %esp, %ebp
         .loc 1 5742 0
         leave
         ret
 .LFE184:
 .Lfe184:
 
 
 
 i was able to create a test case that shows the same behavior:
 
 ----
 #include <stdio.h>
 #include <stdlib.h>
 
 
 double tt = 0.000000005975;
 
 double afunction()
 {
   return (5.975e-9);
 }
 
 
 long getS()
 {
   return 3332;
 }
 
 long getP()
 {
   return 6665;
 }
 
 double getPSFactor()
 {
   return ( (double) getS() / (double) getP());
 }
 
 
 int main(int argc, char* argv[])
 {
 
 double temp = 1e12*afunction();
 long var_1 = (long)temp;
 long var_2 = (long)(1e12*afunction()) ;
 long var_3 = (long)(1e12*5.975e-9) ;
 double temp1 = tt;
 long var_4 = (long)(1e12*temp1) ;
 long var_5 = (long) (1e12*tt+0.5) ;
 printf("var_1: %08d\n", var_1);
 printf("var_2: %08d\n", var_2);
 printf("var_3: %08d\n", var_3);
 printf("var_4: %08d\n", var_4);
 printf("var_5: %08d\n", var_5);
 
   return 0;
 }
 
 
 ---
 
 
 results using:
 linux: debug libs
 var_1: 00005975
 var_2: 00005974
 var_3: 00005975
 var_4: 00005974
 var_5: 00005975
 
 linux opt libs:
 var_1: 00005975
 var_2: 00005975
 var_3: 00005975
 var_4: 00005974
 var_5: 00005975
 
 sol/nt:
 var_1: 00005975
 var_2: 00005975
 var_3: 00005975
 var_4: 00005975
 var_5: 00005975
 
 _________________________________________________________________
 Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
 http://join.msn.com/?page=features/junkmail
 

Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

[bangerth]

Synopsis: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

State-Changed-From-To: feedback->closed
State-Changed-By: bangerth
State-Changed-When: Wed May 14 15:14:48 2003
State-Changed-Why:
    Not a bug. Optimized and debug compilations give the same
    result is -ffloat-store is used. On NT, a similar accuracy
    truncation mechanism is used by default. On Solaris, all
    accuracy is 64bit.
    
    W.

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

Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

[Christian Ehrhardt]

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

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
  nobody@gcc.gnu.org, omarbeo@hotmail.com
Cc:  
Subject: Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
Date: Wed, 14 May 2003 16:26:46 +0200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10772
 
 Please also review the section ``Problems with floating point computations.''
 from http://gcc.gnu.org/bugs.html and see if this explains your problem.
 
    regards  Christian
 
 -- 
 THAT'S ALL FOLKS!

Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

[giovannibajo]

Synopsis: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

State-Changed-From-To: open->feedback
State-Changed-By: bajo
State-Changed-When: Wed May 14 10:48:08 2003
State-Changed-Why:
    See Dara's question.

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

Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

[Dara Hazeghi]

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

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, omarbeo@hotmail.com
Cc:  
Subject: Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
Date: Tue, 13 May 2003 23:16:14 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=10772
 
 Hello,
 
 you're attachment didn't make it with the bug report. Further, you're  
 going to have a more complete description of your problem: "this didn't  
 work" isn't specific enough. You need to include a complete  
 self-contained test-case, along with the exact options you're using to  
 compile it and the exact output you're getting. Without these, it's  
 going to be very difficult if not impossible to determine what's going  
 wrong. So can you please followup with the necessary information for  
 this report? Thanks,
 
 Dara
 

optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode

[omarbeo]

>Number:         10772
>Category:       optimization
>Synopsis:       Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 13 18:26:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     omarbeo@hotmail.com
>Release:        GCC 3.2
>Organization:
>Environment:

>Description:
Hi,
I'm seeing differences between nt/sol and linux when i run my application; i'm not sure if this a bug or not.
the interresting thing is that linux-64 optmize and linux-32 debug results will match the nt/sol results.

Here the code:
double get_p() { ... };  // multiple oprations: multiplication, division,..
int get_p() { ... }
double a;
int res;

a = ( (double) get_p() . get_g());
res = (int) a;


i run this test on nt, unix, and linux platforms.
nt and unix (sol) match, while linux data don't (off by 1 unit).
when i run this test using linux debug libs, the results maches those of nt/sol!

So i'm not sure why this is happening?

This could be caused by us not rounding the numbers; but then why linux results differ based on how we build the libs ( optimize and debug).

Thanks,
salim
>How-To-Repeat:

>Fix:
I'm attaching the Assemly code generated on linux in debug and optmize mode.
I found a workaround which will make linux match the two other platforms as follow:

static bool turn_off = false
..
a = ( (double) get_p() . get_g());
if (turn_off) printf("", a)
res = (int) a;
>Release-Note:
>Audit-Trail:
>Unformatted: