--- Comment #138 from pinskia at gcc dot gnu dot org 2010-09-16 17:08
---
*** Bug 45691 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #137 from jvdelisle at gcc dot gnu dot org 2010-08-04 02:42
---
*** Bug 45175 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #136 from pinskia at gcc dot gnu dot org 2010-05-19 18:05
---
*** Bug 44198 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #135 from jsm28 at gcc dot gnu dot org 2009-10-31 18:37 ---
*** Bug 41867 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #134 from jsm28 at gcc dot gnu dot org 2009-10-29 20:26 ---
*** Bug 41867 has been marked as a duplicate of this bug. ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #133 from pinskia at gcc dot gnu dot org 2009-09-20 21:28
---
*** Bug 41195 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #130 from nszabolcs at gmail dot com 2009-07-22 12:10 ---
(In reply to comment #129)
I am a bit wondering if this bug is also for the case (a b) (b a) ==
true. Is it?
i guess so, see:
#include stdlib.h
#include stdio.h
#define axiom_order(a,b) !(a b b a)
--- Comment #131 from vincent at vinc17 dot org 2009-07-22 17:33 ---
(In reply to comment #130)
#define axiom_order(a,b) !(a b b a)
#define axiom_eq(a) a == a
#define third ((double)atoi(1)/atoi(3))
[...]
in C99 (+TC1,TC2,TC3) different precision is not
--- Comment #132 from ich at az2000 dot de 2009-07-22 20:54 ---
So that means that this C++ example could crash under certain circumstances
(depending on how far the compiler is optimising here)?
#include set
#define third ((double)atoi(1)/atoi(3))
int main() {
--- Comment #128 from pinskia at gcc dot gnu dot org 2009-05-18 14:11
---
*** Bug 40186 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #129 from ich at az2000 dot de 2009-05-18 14:24 ---
I am a bit wondering if this bug is also for the case (a b) (b a) ==
true. Is it?
Because if so, this becomes way more serious, as for example std::setdouble
is broken then (and depending on the STL implementation, it
--- Comment #126 from jsm28 at gcc dot gnu dot org 2009-03-30 01:51 ---
Subject: Bug 323
Author: jsm28
Date: Mon Mar 30 01:50:44 2009
New Revision: 145272
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145272
Log:
PR rtl-optimization/323
* c-common.c
--- Comment #127 from jsm28 at gcc dot gnu dot org 2009-03-30 01:57 ---
Fixed for C (and ObjC) for 4.5 with the new -fexcess-precision=standard
support.
The issue remains for other languages (and maybe for some m68k processors);
I quote from my original message
--- Comment #125 from vincent at vinc17 dot org 2008-11-11 10:13 ---
(In reply to comment #124)
It seems like the C99 standard prohibits double rounding,
only if Annex F is claimed to be supported (note: Annex F is not just IEEE 754,
it also contains specific bindings). IEEE 754
--- Comment #124 from David dot Monniaux at imag dot fr 2008-11-11 07:46
---
Vincent Lefèvre is right: the issue is quite subtle. (I should mention that
Vincent is an expert in computer arithmetics, which I'm not.)
As he rightly points, conformance to IEEE-754 should be evaluated for
--- Comment #123 from jsm28 at gcc dot gnu dot org 2008-11-04 13:25 ---
Subject: Bug 323
Author: jsm28
Date: Tue Nov 4 13:24:30 2008
New Revision: 141578
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141578
Log:
PR rtl-optimization/323
* c-common.c
--- Comment #122 from pinskia at gcc dot gnu dot org 2008-09-06 18:01
---
*** Bug 37390 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #119 from mbrudka at filbico dot pl 2008-07-17 10:45 ---
Another example related with fp on x87?
EXPECTED RESULT:
0 (with EPS accuracy)
0 (with EPS accuracy)
0 (with EPS accuracy)
0 (with EPS accuracy)
REAL RESULT:
5.313991e+33
5.313991e+33
0.00e+00
0.00e+00
CODE
--- Comment #120 from vincent at vinc17 dot org 2008-07-17 12:41 ---
(In reply to comment #119)
REAL RESULT:
5.313991e+33
5.313991e+33
0.00e+00
0.00e+00
Only without optimizations. But since the ISO C standard allows expressions to
be evaluated in a higher precision,
--- Comment #121 from mbrudka at filbico dot pl 2008-07-17 12:51 ---
Thank you Vincent. I fact after commenting I realized that this is a plain
numerical error on the last digit of double in multiplication. I think that my
comment was rather irrelevant and I am the more ashamed the more
--- Comment #117 from pepalogik at seznam dot cz 2008-06-24 20:12 ---
(In reply to comment #116)
Yes, but this requires quite a complicated workaround (solution (4) in my
comment #109).
The problem is on the compiler side, which could store every result of a cast
or an
--- Comment #118 from vincent at vinc17 dot org 2008-06-24 20:45 ---
(In reply to comment #117)
By a lucky hit, I have found this in the GCC documentation:
-mpc32
-mpc64
-mpc80
OK, this is new in gcc 4.3. I haven't tried, but if gcc just changes the
precision without changing the
--- Comment #114 from pepalogik at seznam dot cz 2008-06-22 16:59 ---
(In reply to comment #113)
It is available when storing a result to memory.
Yes, but this requires quite a complicated workaround (solution (4) in my
comment #109). So you could say that the IEEE754 double precision
--- Comment #115 from pepalogik at seznam dot cz 2008-06-22 17:28 ---
That #174; should be (R).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #116 from vincent at vinc17 dot org 2008-06-22 21:14 ---
(In reply to comment #114)
Yes, but this requires quite a complicated workaround (solution (4) in my
comment #109).
The problem is on the compiler side, which could store every result of a cast
or an assignment to
--- Comment #112 from pepalogik at seznam dot cz 2008-06-21 22:38 ---
(In reply to comment #111)
Concerning the standards: The x87 FPU does obey the IEEE754-1985 standard,
which *allows* extended precision, and double precision is *available*.
It's true that double *precision* is
--- Comment #113 from vincent at vinc17 dot org 2008-06-22 00:52 ---
(In reply to comment #112)
It's true that double *precision* is available on x87. But not the *IEEE-754
double precision type*.
It is available when storing a result to memory.
Beside the precision of mantissa,
--- Comment #111 from vincent at vinc17 dot org 2008-06-20 16:09 ---
(In reply to comment #109)
WHERE'S THE BUG
This is really not a GCC bug. The bug is actually in the x87 FPU because it
doesn't obey the IEEE standard.
Concerning the standards: The x87 FPU does obey the
--- Comment #110 from pepalogik at seznam dot cz 2008-06-12 14:14 ---
I used an old version of GCC documentation so I omitted some new processors
with SSE: core2, k8-sse3, opteron-sse3, athlon64-sse3, amdfam10 and barcelona.
I think you can use -march=pentium3 for all Intel's CPUs (of
--- Comment #109 from pepalogik at seznam dot cz 2008-05-20 16:59 ---
I also encountered such problems and was going to report it as a bug in GCC...
But in the GCC bug (not) reporting guide, there is fortunately a link to this
page and here (comment #96) is a link to David Monniaux's
--- Comment #108 from rguenth at gcc dot gnu dot org 2008-03-14 17:30
---
*** Bug 35585 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #105 from pinskia at gcc dot gnu dot org 2008-03-06 22:44
---
*** Bug 35488 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #106 from rguenth at gcc dot gnu dot org 2008-03-06 23:14
---
*** Bug 35488 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #107 from pinskia at gcc dot gnu dot org 2008-03-06 23:58
---
*** Bug 35489 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #103 from pinskia at gcc dot gnu dot org 2008-02-27 20:38
---
*** Bug 35389 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
any rounding or approximation. That is
8 = 1* 2^3
1 = 1* 2^0
65 = (1 + 1/64) * 2^6
-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 27, 2008 12:39 PM
To: Wei, Yongbin
Subject: [Bug rtl-optimization/323] optimized code gives
--- Comment #102 from pinskia at gcc dot gnu dot org 2008-01-27 23:17
---
*** Bug 34992 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #101 from pinskia at gcc dot gnu dot org 2008-01-24 04:51
---
*** Bug 34951 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #99 from macracan at yahoo dot com 2007-10-01 17:43 ---
*** Bug 33611 has been marked as a duplicate of this bug. ***
--
macracan at yahoo dot com changed:
What|Removed |Added
--- Comment #98 from sliwa at cft dot edu dot pl 2007-08-03 12:09 ---
*** Bug 32976 has been marked as a duplicate of this bug. ***
--
sliwa at cft dot edu dot pl changed:
What|Removed |Added
--- Comment #97 from pinskia at gcc dot gnu dot org 2007-06-19 08:11
---
*** Bug 32391 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #96 from David dot Monniaux at ens dot fr 2007-04-20 21:19
---
The following paper explains how this kind of behaviour occurs, why it is
correct, why it is difficult to fix but how it can be partly fixed, and how
this breaks many testing and proving techniques:
--- Comment #95 from guillaume dot melquiond at ens-lyon dot fr 2007-04-03
17:51 ---
I think that Uros' patch to add a -mpc switch for precision control would
fix this.
The real fix would be to automatically insert fldcw instructions before
float/double operations, in order to
--- Comment #94 from bonzini at gnu dot org 2007-04-02 16:20 ---
I think that Uros' patch to add a -mpc switch for precision control would fix
this.
The real fix would be to automatically insert fldcw instructions before
float/double operations, in order to limit the precision of the
--- Comment #91 from pinskia at gcc dot gnu dot org 2007-03-09 20:11
---
*** Bug 31114 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #92 from whaley at cs dot utsa dot edu 2007-03-09 20:22 ---
I'd like to welcome the newest members of the bug 323 community, where all x87
floating point errors in gcc come to die! All floating point errors that use
the x87 are welcome, despite the fact that many of them
--- Comment #93 from pinskia at gcc dot gnu dot org 2007-03-09 22:45
---
*** Bug 31114 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #90 from rguenth at gcc dot gnu dot org 2007-03-01 16:43
---
*** Bug 31008 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #89 from brooks at gcc dot gnu dot org 2007-02-10 00:55 ---
*** Bug 30752 has been marked as a duplicate of this bug. ***
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #87 from bruno at clisp dot org 2006-12-21 15:08 ---
The option -ffloat-store, recommended by Richard Henderson, has the effect of
decreasing the performance of floating-point operations for the entire
compilation unit. If you want a minimal fix that does not affect other
--- Comment #85 from pinskia at gcc dot gnu dot org 2006-12-18 20:16
---
*** Bug 30255 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #86 from pinskia at gcc dot gnu dot org 2006-12-18 22:04
---
*** Bug 30255 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #84 from pinskia at gcc dot gnu dot org 2006-10-25 22:05
---
*** Bug 29597 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #83 from aph at gcc dot gnu dot org 2006-08-02 10:56 ---
*** Bug 16825 has been marked as a duplicate of this bug. ***
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #82 from pinskia at gcc dot gnu dot org 2006-06-28 18:49
---
*** Bug 28191 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #81 from pinskia at gcc dot gnu dot org 2006-01-28 03:56
---
*** Bug 26000 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #80 from pinskia at gcc dot gnu dot org 2005-12-08 01:47
---
*** Bug 25303 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #79 from pinskia at gcc dot gnu dot org 2005-11-10 03:41
---
*** Bug 7935 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #78 from pinskia at gcc dot gnu dot org 2005-10-21 20:24
---
*** Bug 24479 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #77 from pinskia at gcc dot gnu dot org 2005-10-15 18:34
---
*** Bug 24387 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:48 ---
*** Bug 24014 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-16
13:22 ---
*** Bug 23318 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
21:23 ---
*** Bug 23407 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-09
15:59 ---
*** Bug 23298 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-10
18:09 ---
*** Bug 22394 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-19
11:05 ---
Reopening...
--
What|Removed |Added
Status|RESOLVED|REOPENED
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-19
11:09 ---
...to end this pointless discussion.
Some people call this a bug in the x87 series. Other call it a bug in
gcc. See these mails at least for the reason why this could be considered
a bug in gcc:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-19
12:18 ---
*** Bug 1098 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
16:24 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
18:27 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:06 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:24 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:35 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:43 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:47 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29
19:56 ---
*** Bug 21809 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From mario dot tragni at planetek dot it
2005-05-20 08:40 ---
(In reply to comment #2)
State-Changed-From-To: open-closed
State-Changed-Why: See any faq on numerical analysis that mentions the x86.
You are seeing the results of excess precision in the FPU.
--- Additional Comments From cognot at earthdecision dot com 2005-05-20
10:03 ---
(In reply to comment #59)
I had this bug on x86 architecture, with no optimization of the code (no -OX)
and with float-store on. My workaround was to store the return of the double
function in a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-20
03:00 ---
*** Bug 7719 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
14:17 ---
*** Bug 20674 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-28
21:53 ---
*** Bug 20674 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-17
13:37 ---
*** Bug 20026 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09
06:35 ---
*** Bug 19837 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
18:47 ---
*** Bug 19675 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
19:07 ---
*** Bug 19675 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-17
15:40 ---
*** Bug 19469 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-15
14:05 ---
*** Bug 19011 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-15
15:10 ---
*** Bug 19011 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02
14:22 ---
*** Bug 18784 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19
15:33 ---
*** Bug 18567 has been marked as a duplicate of this bug. ***
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-01
15:12 ---
*** Bug 18756 has been marked as a duplicate of this
--- Additional Comments From eda-qa at disemia dot com 2004-12-01 16:24
---
To summarize, this defect effectively states that:
assert( (x/y) == (x/y) )
may cause an assertion if compiled with optimization.
While I understand why it happens, that doesn't mean it isn't a defect. This
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-19
15:32 ---
*** Bug 18567 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
92 matches
Mail list logo
