public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
@ 2003-05-14 20:56 Wolfgang Bangerth
0 siblings, 0 replies; 8+ messages in thread
From: Wolfgang Bangerth @ 2003-05-14 20:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- 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 Im 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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
@ 2003-05-14 19:26 omar beo
0 siblings, 0 replies; 8+ messages in thread
From: omar beo @ 2003-05-14 19:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- 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 Im 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
@ 2003-05-14 15:16 omar beo
0 siblings, 0 replies; 8+ messages in thread
From: omar beo @ 2003-05-14 15:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- 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 wasnt 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
@ 2003-05-14 15:14 bangerth
0 siblings, 0 replies; 8+ messages in thread
From: bangerth @ 2003-05-14 15:14 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, omarbeo
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
@ 2003-05-14 14:36 Christian Ehrhardt
0 siblings, 0 replies; 8+ messages in thread
From: Christian Ehrhardt @ 2003-05-14 14:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
@ 2003-05-14 10:48 giovannibajo
0 siblings, 0 replies; 8+ messages in thread
From: giovannibajo @ 2003-05-14 10:48 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, omarbeo
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
@ 2003-05-14 6:26 Dara Hazeghi
0 siblings, 0 replies; 8+ messages in thread
From: Dara Hazeghi @ 2003-05-14 6:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode
@ 2003-05-13 18:26 omarbeo
0 siblings, 0 replies; 8+ messages in thread
From: omarbeo @ 2003-05-13 18:26 UTC (permalink / raw)
To: gcc-gnats
>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:
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-05-14 20:56 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-14 20:56 optimization/10772: Result differences between debug and optmize libs on linux; and with sol/nt on optimize mode Wolfgang Bangerth
-- strict thread matches above, loose matches on Subject: below --
2003-05-14 19:26 omar beo
2003-05-14 15:16 omar beo
2003-05-14 15:14 bangerth
2003-05-14 14:36 Christian Ehrhardt
2003-05-14 10:48 giovannibajo
2003-05-14 6:26 Dara Hazeghi
2003-05-13 18:26 omarbeo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).