Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zimmerma+gcc at loria dot fr
GCC build triplet: sparc-sun-solaris2.10
GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10
--- Comment #1 from zimmerma+gcc at loria dot fr 2009-07-15 02:02 ---
Note this bug was noticed on a Sun T5240, and might be specific to T2+.
David Kirkby offers access to the machine for gcc developers who might want
to reproduce/isolate/fix the bug.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from zimmerma+gcc at loria dot fr 2009-07-16 07:52 ---
Created an attachment (id=18203)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18203&action=view)
preprocessed version of the file mpn_exp.c from mpfr-2.4.1
Note that replacing line 74:
MPN_ZERO (a
--- Comment #14 from zimmerma+gcc at loria dot fr 2009-07-17 00:57 ---
> You haven't mentioned what options you compiled this file with.
the problem appears both with -O0, -O1 and -O2.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
-Wa,-mppc64 -
mcpu=970
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zimmerma+gcc at loria dot fr
GCC b
--- Comment #1 from zimmerma+gcc at loria dot fr 2009-03-11 16:51 ---
This problem was discovered while trying to compile GMP with ABI=mode32:
http://gmplib.org/list-archives/gmp-bugs/2009-March/001307.html
If either one of the three options -mpowerpc64 -Wa,-mppc64 -mcpu=970 is
removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96044
Paul Zimmermann changed:
What|Removed |Added
CC||zimmerma+gcc at loria dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96044
--- Comment #9 from Paul Zimmermann ---
Dear Richard, about mini-gmp, note that MPFR 4.1.0 (rc2 now in test) will come
with improved mini-gmp support. From NEWS:
- Mini-gmp support: replaced --enable-mini-gmp configure option by
--with-mini-gmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
Paul Zimmermann changed:
What|Removed |Added
CC||zimmerma+gcc at loria dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181
Paul Zimmermann changed:
What|Removed |Added
CC||zimmerma+gcc at loria dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318
Paul Zimmermann changed:
What|Removed |Added
CC||zimmerma+gcc at loria dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488
--- Comment #7 from Paul Zimmermann ---
I agree that near zeroes we can expect large errors. However for other
functions
I got only small errors in ulps, maybe I was unlucky. Also the ultimate goal is
to get correct rounding, even near zeroes.
Assignee: unassigned at gcc dot gnu.org
Reporter: zimmerma+gcc at loria dot fr
on https://gcc.gnu.org/onlinedocs/libquadmath.pdf, page 7,
"simulataneously" should read "simultaneously"
Assignee: unassigned at gcc dot gnu.org
Reporter: zimmerma+gcc at loria dot fr
For the input aa below (with 36 digits, we can recover the exact 113-bit binary
value by rounding to nearest) mpfr_y0 gets the result cc (more precisely, the
corresponding 113-bit binary value) which should be
ression] wrong conversion from unsigned int/long
to float
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy
--- Comment #4 from zimmerma+gcc at loria dot fr 2010-09-07 11:47 ---
this is indeed a duplicate of #44631. It can be reproduced also with GCC 4.3
and
-mcpu=v9.
I suggest adding GMP-ECM "make check" in the regression tests for GCC (some
time
ago it was used for the effici
--- Comment #12 from zimmerma+gcc at loria dot fr 2010-09-07 11:47 ---
*** Bug 45559 has been marked as a duplicate of this bug. ***
--
zimmerma+gcc at loria dot fr changed:
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #5 from Paul Zimmermann 2010-10-20
09:54:01 UTC ---
(In reply to comment #3)
> You should use -ffloat-store to remove excess precision.
the main issue is not the excess of precision, but the fact that identical
calls
to printf with i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #9 from Paul Zimmermann 2010-10-21
19:26:11 UTC ---
(In reply to comment #8)
> You really should use hex float to see the diferences. I bet it is just the
> final digit of the hex float that is different and only by one. This is
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #11 from Paul Zimmermann 2010-10-22
06:56:20 UTC ---
(In reply to comment #10)
> You can use -fno-errno-math if you don't want errno to be set, then there will
> be no calls to sqrtf and all 3 calls should at least when optimizing eva
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46180
Summary: CSE across calls to fesetround()
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.or
c
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zimmerma+gcc at loria dot fr
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet:
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zimmerma+gcc at loria dot fr
Target Milestone: ---
with the following program:
#include
#include
#include
const long double a = 0xc.90fdaa22168c235p-1l;
const long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498
--- Comment #12 from Paul Zimmermann ---
I confirm this is fixed with gcc version 11.3.0 (Debian 11.3.0-1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
--- Comment #23 from Paul Zimmermann ---
for the record here is what I get with the code from comment 20 with gcc 11.3.0
from Debian on a x86_64:
$ gcc -S -O1 test.cc -o-
.file "test.cc"
.text
.globl _Z3addR4pairS0_
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zimmerma+gcc at loria dot fr
Target Milestone: ---
The following code:
#include
#include
#pragma STDC FENV_ACCESS ON
int main()
{
fesetround (FE_UPWARD);
float x = 0x1.e90026p+4f + 0x1.fp-21;
printf ("x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112367
--- Comment #2 from Paul Zimmermann ---
> Build a newer one on cfarm117?
it would be a waste of time, I guess people having access to an ARM machine
with a recent version of gcc can confirm or say the issue is fixed.
> Also, what CHOST?
sorry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112367
--- Comment #7 from Paul Zimmermann ---
thank you all and sorry for the noise
28 matches
Mail list logo
