--- 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"))
[...]
--- Comment #8 from vincent at vinc17 dot org 2009-05-18 14:56 ---
Are you sure that this comes from the extended precision? This would mean that
GCC does implicit extended -> double conversions in an asymmetric way, and
IIRC, I've never seen that.
I can't reproduce the p
--- 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
--- 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
--- 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 increa
--- 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 h
--- 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 chan
--- 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 assignm
--- 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.
>
--- 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 do
--- Comment #5 from vincent at vinc17 dot org 2006-02-14 17:03 ---
(In reply to comment #4)
> Note however, that the true accurate value for d, calculated at infinite
> precision, is 1-(2^-16). So, the absolute error for gcj is 1+(2^-16) and the
> absolute error with correct
--- Additional Comments From vincent at vinc17 dot org 2004-12-08 15:13
---
I'm wrong. gcc 3.4 (from Debian) still has this problem. So, -ffloat-store is
still needed for C compliance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
--- You are receiving this mail be
--- Additional Comments From vincent at vinc17 dot org 2004-11-29 15:35
---
In Comment 5, I wrote:
> The real problem is that intermediate results in extended precision are not
converted back to double after a cast or an assignment; this is required by the
C standard, whet
--
What|Removed |Added
CC||vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16122
--- You are receiving this
--- Additional Comments From vincent at vinc17 dot org 2004-06-22 06:04
---
I don't know very much about Java, but I've talked with someone who has some
knowledge in Java and floating point, and according to him, Java FP arithmetic
operations must round exactly in double preci
--
What|Removed |Added
CC||vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
--- You are receiving this
--- Additional Comments From vincent at vinc17 dot org 2004-03-28 13:53
---
I don't think that glibc is wrong by defining __STDC_IEC_559__ (computing in an
extended type is allowed by the IEEE-754 standard) as long as FLT_EVAL_METHOD is
correctly set. The real problem is
17 matches
Mail list logo
