--- Comment #11 from vincent at vinc17 dot org 2008-09-06 22:19 ---
(In reply to comment #10)
> The funny thing is that this only happens with -O2 or -O1 but not with -O0 ie
> no optimization it is all correct , when we optimize the results start
> varying.
Because with -O0, some value
--- Comment #10 from niklaus at gmail dot com 2008-09-06 21:23 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Does increasing bits cause floating point errors. How could 64 bit precison
> > give correct result where as 80 bit give incorrect one.
>
> You can have rounding er
--- Comment #9 from brian at dessent dot net 2008-09-06 20:31 ---
Subject: Re: wrong-code on i486-linux-gnu with -O[12], -O0
works
pinskia at gmail dot com wrote:
> Because on x86 gnu/Linux, the precision is set to 80bits rather than
> 64bit like it is on windows.
That is only true
--- Comment #8 from vincent at vinc17 dot org 2008-09-06 18:42 ---
(In reply to comment #7)
> Does increasing bits cause floating point errors. How could 64 bit precison
> give correct result where as 80 bit give incorrect one.
You can have rounding errors whether you increase the preci
--- Comment #7 from niklaus at gmail dot com 2008-09-06 18:28 ---
(In reply to comment #5)
> Subject: Re: wrong-code on i486-linux-gnu with -O[12], -O0 works
>
> Because on x86 gnu/Linux, the precision is set to 80bits rather than
> 64bit like it is on windows.
> >
Does increasing
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-06 18:01 ---
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gmail dot com 2008-09-06 17:56 ---
Subject: Re: wrong-code on i486-linux-gnu with -O[12], -O0 works
Sent from my iPhone
On Sep 6, 2008, at 10:42, "niklaus at gmail dot com" <[EMAIL PROTECTED]
> wrote:
>
>
> --- Comment #4 from niklaus at gmail d
Sent from my iPhone
On Sep 6, 2008, at 10:42, "niklaus at gmail dot com" <[EMAIL PROTECTED]
> wrote:
--- Comment #4 from niklaus at gmail dot com 2008-09-06 17:42
---
On the below version of gcc on cygwin (winXP SP3) i don't have any
problems
with optimization on or off. They
--- Comment #4 from niklaus at gmail dot com 2008-09-06 17:42 ---
On the below version of gcc on cygwin (winXP SP3) i don't have any problems
with optimization on or off. They produce consistent correct result. Why is it
a problem with linux ? or am i doing something wrong.
I tried gcc
--- Comment #3 from doko at ubuntu dot com 2008-09-06 14:18 ---
> So I don't know what else to say
mark as duplicate of PR 323?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37390
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-05 22:54 ---
I think this is really PR 323. Using -ffloat-store gives the correct answer.
D.2639 = pow ((double) a, (double) b + 1.0e+0);
num = (ull) D.2639 - 1.0e+0;
So I don't know what else to say, except -ffloat-store o
--- Comment #1 from doko at ubuntu dot com 2008-09-05 22:43 ---
Created an attachment (id=16238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16238&action=view)
example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37390
12 matches
Mail list logo
