[Bug c/40757] New: gcc 4.4.0 miscompiles mpfr-2.4.1
See http://websympa.loria.fr/wwsympa/arc/mpfr/2009-07/msg00031.html and the following discussion. This was on t2.math.washington.edu with /usr/local/gcc-4.4.0-sun-linker/bin/gcc: zimme...@t2:/tmp/mpfr-2.4.1$ /usr/local/gcc-4.4.0-sun-linker/bin/gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /home/kirkby/gcc-4.4.0/configure CC=/usr/sfw/bin/gcc --prefix=/usr/local/gcc-4.4.0-sun-linker --without-gnu-as --without-gnu-ld --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-languages=c,c++,fortran --with-mpfr-lib=/usr/local/lib --with-mpfr-include=/usr/local/include --with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib --with-libiconv-prefix=/usr/lib/iconv Thread model: posix gcc version 4.4.0 (GCC) -- Summary: gcc 4.4.0 miscompiles mpfr-2.4.1 Product: gcc Version: 4.4.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: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- 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/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- 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, n - 1);
by:
{ int n1 = n - 1; MPN_ZERO (a, n1); }
fixes the problem, where MPN_ZERO is defined as:
#define MPN_ZERO(dst, n) memset((dst), 0, (n)*BYTES_PER_MP_LIMB)
and BYTES_PER_MP_LIMB is 4.
If I write "size_t n1" or "unsigned int n1" above instead of "int n1",
the bug reappears.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- 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
[Bug c/39435] New: invalid assembly produced with -mpowerpc64 -Wa,-mppc64 -mcpu=970
The following code gives:
zimme...@gcc40:~$ /opt/cfarm/release/4.3.3/bin/gcc -mpowerpc64 -Wa,-mppc64
-mcpu=970 -c bug.c
/tmp/ccCzXnwd.s: Assembler messages:
/tmp/ccCzXnwd.s:24: Error: junk at end of line: `1'
zimme...@gcc40:~$ cat bug.c
typedef unsigned long long int mp_limb_t;
typedef const mp_limb_t *mp_srcptr;
typedef long int mp_size_t;
void
foo (mp_srcptr src, mp_limb_t divisor)
{
mp_limb_t h, s;
mp_limb_t p0;
for (;;)
{
s = src[0];
h = bar (&p0, divisor > s, divisor);
}
}
--
Summary: invalid assembly produced with -mpowerpc64 -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 build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc970-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39435
[Bug c/39435] invalid assembly produced with -mpowerpc64 -Wa,-mppc64 -mcpu=970
--- 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, the compilation works. -- zimmerma+gcc at loria dot fr changed: What|Removed |Added CC||zimmerma+gcc at loria dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39435
[Bug middle-end/96044] GCC hangs in tight loop resolving __builtin_jn using MPFR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96044 Paul Zimmermann changed: What|Removed |Added CC||zimmerma+gcc at loria dot fr --- Comment #7 from Paul Zimmermann --- the problem is partly solved in MPFR development branch, where jn(7,7) now takes about 2 seconds on my machine, and jn(73,73) about 4 minutes. Note that Wolfram Alpha fails for jn(7,7), and Pari/GP fails for jn(73,73). Maybe a timeout should be put into the constant folding code? With MPFR I get 4.9602731659759520e-03 whereas gcc -fno-builtin gives 4.9602731659753978e-03, which is off by 639 ulps (assuming the MPFR value is correct).
[Bug middle-end/96044] GCC hangs in tight loop resolving __builtin_jn using MPFR
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 (still experimental, read doc/mini-gmp). Feel free to exercise this within GCC.
[Bug rtl-optimization/80491] [7 Regression] Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491 Paul Zimmermann changed: What|Removed |Added CC||zimmerma+gcc at loria dot fr --- Comment #15 from Paul Zimmermann --- I just checked with gcc 9.2.1 20191109 (Debian 9.2.1-19) and it seems -O1 produces better code than -O3. Is there a non-regression test? $ gcc -S -O3 test.cc -o- .file "test.cc" .text .p2align 4 .globl _Z3addR4pairS0_ .type _Z3addR4pairS0_, @function _Z3addR4pairS0_: .LFB0: .cfi_startproc movq(%rsi), %rax xorl%ecx, %ecx addq(%rdi), %rax setc%cl movq8(%rsi), %rdx addq8(%rdi), %rdx addq%rcx, %rdx ret .cfi_endproc .LFE0: .size _Z3addR4pairS0_, .-_Z3addR4pairS0_ .ident "GCC: (Debian 9.2.1-19) 9.2.1 20191109" .section.note.GNU-stack,"",@progbits $ gcc -S -O1 test.cc -o- .file "test.cc" .text .globl _Z3addR4pairS0_ .type _Z3addR4pairS0_, @function _Z3addR4pairS0_: .LFB0: .cfi_startproc movq(%rdi), %rax movq8(%rsi), %rdx addq(%rsi), %rax adcq8(%rdi), %rdx ret .cfi_endproc .LFE0: .size _Z3addR4pairS0_, .-_Z3addR4pairS0_ .ident "GCC: (Debian 9.2.1-19) 9.2.1 20191109" .section.note.GNU-stack,"",@progbits
[Bug target/60181] constant folding of complex number incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181
Paul Zimmermann changed:
What|Removed |Added
CC||zimmerma+gcc at loria dot fr
--- Comment #9 from Paul Zimmermann ---
Here is another example:
$ cat t.c
#include
#include
#include
_Complex double __attribute__ ((noinline))
calc_div (_Complex double a, _Complex double b)
{
return a / b;
}
_Complex double __attribute__ ((noinline))
calc_mul (_Complex double a, _Complex double b)
{
return a * b;
}
int
main (int argc, char **argv)
{
double x, y, z, t;
_Complex double a, b, c, d;
x = -1.0689346237980500e+252; y = 7.8846096489686452e-145;
z = 5.1152592576527620e-318; t = 6.7327111521288819e+78;
a = calc_div (x + y * I, z + t * I);
b = (x + y * I) / (z + t * I);
printf ("calc_div: %ap + %ap * i\n", creal (a), cimag (a));
printf ("div: %ap + %ap * i\n", creal (b), cimag (b));
x = -4.8798814420289904e-22; y = -6.4569205261627488e+209;
z = -1.0918976936190148e+147; t = -8.2942999263695497e-85;
c = calc_mul (x + y * I, z + t * I);
d = (x + y * I) * (z + t * I);
printf ("calc_mul: %ap + %ap * i\n", creal (c), cimag (c));
printf ("mul: %ap + %ap * i\n", creal (d), cimag (d));
return 0;
}
With gcc version 9.2.1 20200123 (Debian 9.2.1-25) on x86_64 I get:
$ gcc -O0 t.c; ./a.out
calc_div: 0x1.5ac8471ecdabp-741p + 0x1.48aa457eda0eep+575p * i
div: 0x1.5ac8471ecdabp-741p + 0x1.48aa457eda0eep+575p * i
calc_mul: -0x1.07a6046b053p+410p + infp * i
mul: -0x1.07a6046b053p+410p + infp * i
$ gcc -O2 t.c; ./a.out
calc_div: 0x1.5ac8471ecdabp-741p + 0x1.48aa457eda0eep+575p * i
div: -0x1.4d35f7c831ef5p-746p + 0x1.48aa457eda0eep+575p * i
calc_mul: -0x1.07a6046b053p+410p + infp * i
mul: -0x1.07a6046b053p+410p + infp * i
For division, the correctly rounded result is the one for "div" with -O2
(negative real part).
For multiplication, all results are incorrectly rounded, we should get
-0x1.07a6046b05347p410 if I'm correct.
I understand there is no accuracy requirement, but I thought with -O2 gcc was
using GNU MPC to get correct rounding, thus with -O2 both the "div" and "mul"
results should be correctly rounded. Why isn't it the case for mul?
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 Paul Zimmermann changed: What|Removed |Added CC||zimmerma+gcc at loria dot fr --- Comment #2 from Paul Zimmermann --- I was able to reproduce with gcc 7.2.0 and: GNU libc version: 2.24 GNU libc release: stable Paul Zimmermann
[Bug libquadmath/63488] large errors in y0q
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.
[Bug libquadmath/63487] New: typo in documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63487 Bug ID: 63487 Summary: typo in documentation Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libquadmath 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"
[Bug libquadmath/63488] New: large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 Bug ID: 63488 Summary: large errors in y0q Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath 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 correctly rounded, and y0q gets the result dd which differs from 180688 ulps. aa=8.935761195587725798762818805462843676e-01 cc=-7.446238819993339201075302662649733975e-07 [MPFR] dd=-7.446238819993339201075302662815669696e-07 ulp difference = 180688.00 For other functions and one million random inputs per function, I got much smaller differences (at most 42 ulps). The compiler was gcc 4.6.3. Paul Zimmermann
[Bug c/45559] New: [4.4 regression] wrong conversion from unsigned int/long to float
With the following program:
#include
int
main()
{
unsigned int t = 254733465;
float f;
f = (float) t;
printf ("t=%u f=%.0f\n", t, f);
}
I get with gcc 4.3 the expected result:
t=254733465 f=254733472
but with gcc 4.4.5:
t=254733465 f=482062944
which is clearly wrong.
Note: this was obtained on smetana.debian.org with
gcc 4.4.5 20100824 (prerelease) (Debian 4.4.4-11)
Note 2: this bug makes GMP-ECM fail:
https://buildd.debian.org/fetch.cgi?pkg=gmp-ecm&arch=sparc&ver=6.3-2&stamp=1281775571&file=log&as=raw
--
Summary: [4.4 regression] 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: zimmerma+gcc at loria dot fr
GCC build triplet: sparc-linux-gnu
GCC host triplet: sparc-linux-gnu
GCC target triplet: sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45559
[Bug target/45559] [4.4 regression] wrong conversion from unsigned int/long to float
--- 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 efficiency tests). This would have hit this bug before the release of 4.4. Paul Zimmermann *** This bug has been marked as a duplicate of 44631 *** -- zimmerma+gcc at loria dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45559
[Bug target/44631] [sparc] long long to double conversion error
--- 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 CC||zimmerma+gcc at loria dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
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 identical arguments give different values in the same program! The fact that different versions of GCC behave differently vs precision is a different issue. Paul
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
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 > actually ok IIRC. see comment 5. (Moreover the sqrt function must return correct rounding according to IEEE 754, thus even a difference of 1 ulp is *not* ok.) Paul Zimmermann
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
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 evaluate
> in extended precision.
indeed with -fno-math-errno I get three identical results on a 64-bit Core 2
with gcc 4.4.4:
tarte% cat bug.c
#include
#include
float x=(float) 2.0;
int main() {
printf ("%.10f\n%.10f\n%.10f\n",sqrtf(x),sqrtf(x),sqrtf(x));
return 0;
}
tarte% gcc -mfpmath=387 bug.c -lm
tarte% ./a.out
1.4142135382
1.4142135382
1.4142135624
tarte% gcc -mfpmath=387 -fno-math-errno bug.c -lm
tarte% ./a.out
1.4142135624
1.4142135624
1.4142135624
However setting errno should not have side effects on the results.
Paul
[Bug c/46180] New: CSE across calls to fesetround()
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.org
ReportedBy: zimmerma+...@loria.fr
with this program:
#include
#include
int main()
{
double x = 3.0;
fesetround (FE_DOWNWARD);
printf ("1/3 arrondi vers -Inf: %.17f\n", 1.0 / x);
fesetround (FE_UPWARD);
printf ("1/3 arrondi vers +Inf: %.17f\n", 1.0 / x);
}
I get with gcc 4.4.4:
tarte% gcc -O1 ex.c -lm
tarte% ./a.out
1/3 arrondi vers -Inf: 0.1
1/3 arrondi vers +Inf: 0.1
while -O0 gives the expected results:
tarte% ./a.out
1/3 arrondi vers -Inf: 0.1
1/3 arrondi vers +Inf: 0.7
Kaveh Ghazi believes this is due to incorrect CSE across calls to fesetround().
Also the following program:
#include
#include
#include
int main()
{
double x = 3.0;
fesetround (FE_DOWNWARD);
printf ("sin(3) arrondi vers -Inf: %.17f\n", sin (x));
fesetround (FE_UPWARD);
printf ("sin(3) arrondi vers +Inf: %.17f\n", sin (x));
fesetround (FE_TONEAREST);
printf ("sin(3) arrondi au plus proche : %.17f\n", sin (x));
fesetround (FE_TOWARDZERO);
printf ("sin(3) arrondi vers 0 : %.17f\n", sin (x));
}
gives with -O0:
tarte% gcc -O0 ex2.c -lm; ./a.out
sin(3) arrondi vers -Inf: 2.78837698122124511
sin(3) arrondi vers +Inf: 0.14112000805986724
sin(3) arrondi au plus proche : 0.14112000805986721
sin(3) arrondi vers 0 : 2.78837698122124511
And with -O1 or -O2:
tarte% gcc -O1 ex2.c -lm ; ./a.out
sin(3) arrondi vers -Inf: 0.14112000805986721
sin(3) arrondi vers +Inf: 0.14112000805986721
sin(3) arrondi au plus proche : 0.14112000805986721
sin(3) arrondi vers 0 : 0.14112000805986721
Kaveh Ghazi found that when compiling the code with -fdump-tree-all
-frounding-math -lm -O1 the
body of main() is transformed into the code below:
main ()
{
double D.4342;
:
fesetround (1024);
D.4342_2 = sin (3.0e+0);
printf (&"sin(3) arrondi vers -Inf: %.17f\n"[0], D.4342_2);
fesetround (2048);
printf (&"sin(3) arrondi vers +Inf: %.17f\n"[0], D.4342_2);
fesetround (0);
printf (&"sin(3) arrondi au plus proche : %.17f\n"[0], D.4342_2);
fesetround (3072);
printf (&"sin(3) arrondi vers 0 : %.17f\n"[0], D.4342_2);
return;
}
which clearly shows that sin(3.0) is computed only once, although the rounding
mode changed.
Paul Zimmermann
PS: a separate issue is that the rounding of sin(3) towards 0 and -Inf are
completely out of the allowed range [-1,1] for -O0...
[Bug c/36296] New: wrong warning about potential uninitialized variable
When compiling mpfr-2.3.1 with gcc-4.3, one gets the following warning
(among others):
{{{
lngamma.c: In function 'mpfr_lngamma_aux':
lngamma.c:160: warning: 'B' may be used uninitialized in this function
}}}
However, looking at the code shows that this variable cannot be used
uninitialized:
* a variable Bm is initialized to zero
* if Bm=0, B is initialized using an auxiliary function, and Bm is set to 2
(this code is in a do { ... } while loop, thus is always executed)
--
Summary: wrong warning about potential uninitialized variable
Product: gcc
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: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug c/102498] New: wrong output of printf with long double constant and non-default rounding mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102498
Bug ID: 102498
Summary: wrong output of printf with long double constant and
non-default rounding mode
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
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 double b = 0xc.90fdaa22168c235p-2l;
int main()
{
fesetround (FE_TONEAREST);
printf ("FE_TONEAREST: a=%La b=%La\n", a, b);
fesetround (FE_TOWARDZERO);
printf ("FE_TOWARDZERO: a=%La b=%La\n", a, b);
fesetround (FE_UPWARD);
printf ("FE_UPWARD: a=%La b=%La\n", a, b);
fesetround (FE_DOWNWARD);
printf ("FE_DOWNWARD: a=%La b=%La\n", a, b);
}
I get:
$ gcc -frounding-math -O0 -fno-builtin e.c -lm
$ ./a.out
FE_TONEAREST: a=0xc.90fdaa22168c235p-1 b=0xc.90fdaa22168c235p-2
FE_TOWARDZERO: a=0xc.90fdaa22168c235p-1 b=0xc.90fdaa22168c234p-2
FE_UPWARD: a=0xc.90fdaa22168c235p-1 b=0xc.90fdaa22168c235p-2
FE_DOWNWARD: a=0xc.90fdaa22168c235p-1 b=0xc.90fdaa22168c234p-2
The value 'a' is printed the same whatever the rounding mode, but 'b' (which
approximates pi to nearest) is wrongly printed for FE_TOWARDZERO and
FE_DOWNWARD.
According to Alexander Monakov, the same problem should happen with og_2 10,
log_2 e, log_10 2, and log_e 2, see
https://sourceware.org/pipermail/libc-alpha/2021-September/131411.html
[Bug target/102498] [9/10 Regression] Long double constant and non-default rounding mode on x86
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).
[Bug target/80491] [10/11/12/13 Regression] Compiler regression for long-add case.
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_ .type _Z3addR4pairS0_, @function _Z3addR4pairS0_: .LFB0: .cfi_startproc movq(%rdi), %rax movq8(%rdi), %rdx addq(%rsi), %rax adcq8(%rsi), %rdx ret .cfi_endproc .LFE0: .size _Z3addR4pairS0_, .-_Z3addR4pairS0_ .globl _Z4add1R4pairS0_ .type _Z4add1R4pairS0_, @function _Z4add1R4pairS0_: .LFB1: .cfi_startproc movq(%rsi), %rax addq(%rdi), %rax setc%cl movzbl %cl, %ecx movq8(%rdi), %rdx addq8(%rsi), %rdx addq%rcx, %rdx ret .cfi_endproc .LFE1: .size _Z4add1R4pairS0_, .-_Z4add1R4pairS0_ .ident "GCC: (Debian 11.3.0-3) 11.3.0" .section.note.GNU-stack,"",@progbits $ gcc -S -O3 test.cc -o- .file "test.cc" .text .p2align 4 .globl _Z3addR4pairS0_ .type _Z3addR4pairS0_, @function _Z3addR4pairS0_: .LFB0: .cfi_startproc movq(%rsi), %rax xorl%ecx, %ecx addq(%rdi), %rax setc%cl movq8(%rdi), %rdx addq8(%rsi), %rdx addq%rcx, %rdx ret .cfi_endproc .LFE0: .size _Z3addR4pairS0_, .-_Z3addR4pairS0_ .p2align 4 .globl _Z4add1R4pairS0_ .type _Z4add1R4pairS0_, @function _Z4add1R4pairS0_: .LFB1: .cfi_startproc movq(%rsi), %rax xorl%ecx, %ecx addq(%rdi), %rax setc%cl movq8(%rdi), %rdx addq8(%rsi), %rdx addq%rcx, %rdx ret .cfi_endproc .LFE1: .size _Z4add1R4pairS0_, .-_Z4add1R4pairS0_ .ident "GCC: (Debian 11.3.0-3) 11.3.0" .section.note.GNU-stack,"",@progbits
[Bug c/112367] New: wrong rounding of sum of floating-point constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112367
Bug ID: 112367
Summary: wrong rounding of sum of floating-point constants
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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=%a\n", x);
}
yields on cfarm117 with gcc 6.3.0:
zimmerma@cfarm117:~/core-math$ gcc -frounding-math e.c -lm; ./a.out
x=0x1.e90026p+4
whereas one would expect 0x1.e90028p+4.
I don't have access to an ARM machine with a recent version of gcc.
[Bug c/112367] wrong rounding of sum of floating-point constants
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 I'm not sure to understand. Here is the full gcc -v output: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/6/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-arm64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-arm64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-arm64 --with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --enable-fix-cortex-a53-843419 --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu Thread model: posix gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
[Bug middle-end/112367] wrong rounding of sum of floating-point constants with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112367 --- Comment #7 from Paul Zimmermann --- thank you all and sorry for the noise
[Bug target/120910] spurious underflow with float to half-float conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120910 --- Comment #3 from Paul Zimmermann --- note that clang does not emit underflow also with -ftrapping-math: zimmerma@biscotte:/tmp$ clang -ftrapping-math -O1 -march=x86-64-v3 -frounding-math /tmp/e.c -lm && ./a.out underflow: 0 y=inf
[Bug c/120910] New: spurious underflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120910 Bug ID: 120910 Summary: spurious underflow Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zimmerma+gcc at loria dot fr Target Milestone: --- Created attachment 61775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61775&action=edit source file to reproduce the bug with the attached code, gcc emits a spurious underflow. This was reported by Maxence Ponsardin. zimmerma@biscotte:/tmp/core-math$ gcc -O1 -march=x86-64-v3 -frounding-math /tmp/e.c -lm && ./a.out underflow: 16 y=inf clang 19.1.7 does not emit any underflow: zimmerma@biscotte:/tmp/core-math$ clang -O1 -march=x86-64-v3 -frounding-math /tmp/e.c -lm && ./a.out underflow: 0 y=inf My guess is that the branch prediction precomputes the result of the cast from 0x1p-25f to _Float16, which would give an underflow, but in the end this branch is not taken.
