[Bug sanitizer/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 --- Comment #15 from Kostya Serebryany kcc at gcc dot gnu.org --- (In reply to Joost VandeVondele from comment #14) (In reply to Jonathan Wakely from comment #10) No, you're right, that's a different issue. I think we've just been relying on loads of (correctly-aligned) _Atomic_word being atomic, although that's not going to keep tsan happy! There's no barrier on the read, but I think the worst that will happen is we won't see the correct value and the CAS loop will go round again. We won't see __count==0 spuriously, because once that count reaches zero it never gets incremented again. Interestingly, a very similar comment was made yesterday in the context of libgomp: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194#c4 If for performance reasons a plain load would nevertheless be preferred over an atomic one, Why would that be? relaxed atomic loads end up generating the same instructions as plain loads. I wonder if these threading libraries could e.g. use conditional compilation such that, when compiled with -fsanitize=thread, an atomic load is used nevertheless. Does -fsanitize=thread define a __SANITIZE_THREAD_IN_USE or similar ? In clang, tsan uses __has_feature(thread_sanitizer). In gcc asan defines __SANITIZE_ADDRESS__, but I don't think we have __SANITIZE_THREAD__ and it would be very pity if we have to use it in libstdc++
[Bug bootstrap/59206] [4.9 regression] many bootstrap comparison failures on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59206 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com --- Bootstrap at r205061 succeeded.
[Bug target/53976] [SH] Unnecessary clrt after bt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976 --- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Thu Nov 21 08:19:38 2013 New Revision: 205191 URL: http://gcc.gnu.org/viewcvs?rev=205191root=gccview=rev Log: PR target/53976 * config/sh/sh_optimize_sett_clrt.cc: New SH specific RTL pass. * config/sh/sh.c (register_sh_passes): Add sh_optimize_sett_clrt pass. * config/sh/sh/t-sh (sh_optimize_sett_clrt pass.o): New entry. * config.gcc (sh[123456789lbe]*-*-* | sh-*-*): Add sh_optimize_sett_clrt pass.o toextra_objs. PR target/53976 * gcc.target/sh/pr53976-1.c: New. Added: trunk/gcc/config/sh/sh_optimize_sett_clrt.cc trunk/gcc/testsuite/gcc.target/sh/pr53976-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/t-sh trunk/gcc/testsuite/ChangeLog
[Bug libfortran/59227] New: [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 Bug ID: 59227 Summary: [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Blocks: 49024 Target: ia64-*-* $ gcc/gfortran -Bgcc/ -Bia64-suse-linux/./libgfortran/ ../gcc/testsuite/gfortran.dg/erf_3.F90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fno-range-check -ffree-line-length-none -O0 -Bia64-suse-linux/./libgfortran/.libs -Lia64-suse-linux/./libgfortran/.libs -Bia64-suse-linux/./libquadmath/.libs -Lia64-suse-linux/./libquadmath/.libs -lm -o ./erf_3.exe $ LD_LIBRARY_PATH=ia64-suse-linux/libgfortran/.libs:ia64-suse-linux/libquadmath/.libs ./erf_3.exe 0.000 0.000 0.000 0.000 0.000 0.000 0.000 1.000E+ 1.000E+ 0.000 0.000 0.000 0.000 0.000 0.000 0.000 1.000E+ 3.11594175678318376063235411046565406E+0955 Program aborted. Backtrace: #0 0x2008084F #1 0x2008477F #2 0x202665DF #3 0x4000161F in check.850 at erf_3.F90:? #4 0x40001F3F in MAIN__ at erf_3.F90:? Aborted
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Thu Nov 21 08:45:00 2013 New Revision: 205193 URL: http://gcc.gnu.org/viewcvs?rev=205193root=gccview=rev Log: PR libfortran/59227 * intrinsics/erfc_scaled.c (erfc_scaled_r16): Don't define if __float128 is not available. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/erfc_scaled.c
[Bug libfortran/49024] REAL*16 ERFC_SCALED inaccuracy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49024 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Fixed on trunk.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Fixed on trunk. Sorry, and thanks Andreas for the report!
[Bug libfortran/49024] REAL*16 ERFC_SCALED inaccuracy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49024 Bug 49024 depends on bug 59227, which changed state. Bug 59227 Summary: [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/53976] [SH] Unnecessary clrt after bt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #4)
One option to get rid of the redundant clrt and sett in BBs that are reached
with a conditional branch would be to add an SH specific RTL pass that
analyses the BBs and eliminates the insns in question.
Another option could be to try and inject artificial sett / clrt insns at
the start of BBs that are reached by conditional branches, and then split
them away to nops or output empty asm with insn length 0. The idea would be
to let other already existing RTL passes figure out the redundant T bit sets.
I've decided to do it with an RTL pass, as it's easier and less obscure.
The initial version committed in r205191 only eliminates redundant sett / clrt
insns. However, there are also some opportunities to e.g. hoist sett / clrt
insns out of loops:
long long test0 (long long* a, unsigned int c)
{
long long s = 0;
do s += *a++; while (--c);
return s;
}
Currently compiles to:
_test0:
mov #0,r0
mov #0,r1
.align 2
.L3:
mov.l @r4+,r2
mov.l @r4+,r3
clrt
addcr3,r1
addcr2,r0
add #-1,r5
tst r5,r5
bf .L3
rts
nop
The previous T bit value at the clrt insn in the loop basic block is currently
detected to have an unknown value from the first basic block and value = 0
after the end of the loop.
In this case the clrt insn can be removed from the loop and put into the first
basic block:
_test0:
mov #0,r0
mov #0,r1
clrt
.align 2
.L3:
mov.l @r4+,r2
mov.l @r4+,r3
addcr3,r1
addcr2,r0
add #-1,r5
tst r5,r5
bf .L3
rts
nop
[Bug tree-optimization/59058] [4.7/4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Nov 21 09:15:05 2013 New Revision: 205197 URL: http://gcc.gnu.org/viewcvs?rev=205197root=gccview=rev Log: 2013-11-21 Richard Biener rguent...@suse.de PR tree-optimization/59058 * tree-loop-distribution.c (struct partition_s): Add plus_one member. (build_size_arg_loc): Apply niter adjustment here. (generate_memset_builtin): Adjust. (generate_memcpy_builtin): Likewise. (classify_partition): Do not use number_of_exit_cond_executions but record whether niter needs to be adjusted. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug libfortran/49024] REAL*16 ERFC_SCALED inaccuracy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49024 Bug 49024 depends on bug 59227, which changed state. Bug 59227 Summary: [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2013-11-21 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org --- That's a different bug.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- What does this output, when compiled with -fno-range-check -ffree-line-length-none -O0? $ cat test.f90 program test real(kind=16) :: x x = 12 print *, erfc_scaled(real(12,kind=16)) print *, erfc_scaled(x) end program test
[Bug sanitizer/59148] FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test on darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148 --- Comment #3 from Alexander Potapenko glider at google dot com --- GCC emits calls to __strcpy_chk and __strncpy_chk in this test, which happens because of source fortification being on by default on Darwin. In Clang we're passing -D_FORTIFY_SOURCE=0 when compiling with -fsanitize=address. I've checked that manually adding -D_FORTIFY_SOURCE=0 fixes strncpy-overflow-1.c Jack, can you please make the changes in the GCC driver?
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org --- 4.68542210148937626195884133993966578E-0002 -1.87533922948603221391158058278771595E+0920
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227
--- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #5)
4.68542210148937626195884133993966578E-0002
-1.87533922948603221391158058278771595E+0920
And this (at -O2)?
__float128 foo (__float128 x)
{
__float128 sum = 0, oldsum;
__float128 inv2x2 = 1 / (2 * x * x);
__float128 fac = 1;
int n = 1;
while (n 200)
{
fac *= - (2*n - 1) * inv2x2;
oldsum = sum;
sum += fac;
__builtin_printf (%lg\n, (double) fac);
if (sum == oldsum)
break;
n++;
}
return (1 + sum) / x * (1.1283791670955125738961589031215452Q / 2);
}
int main (void)
{
__float128 x = 12;
x = foo(x);
__builtin_printf (%lg\n, (double) x);
}
[Bug fortran/59228] New: ICE with assume type and ASYNCHRONOUS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59228 Bug ID: 59228 Summary: ICE with assume type and ASYNCHRONOUS Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Dear All The following wrong code is producing an ICE with gcc version 4.9.0 20131119. Should gcc report an error rank mismatch instead? Valery cat gcc_1.f90 MODULE mp IMPLICIT NONE interface subroutine test(base) TYPE(*), ASYNCHRONOUS :: base end subroutine Test end interface CONTAINS SUBROUTINE foo ( data ) REAL( kind=8 ), DIMENSION( : ), ASYNCHRONOUS :: data CALL test ( data ) END SUBROUTINE foo END MODULE mp gfortran-trunk -c gcc_1.f90 f951: internal compiler error: Segmentation fault 0x9eabbf crash_signal ../../trunk-src/gcc/toplev.c:334 0x57148e compare_parameter ../../trunk-src/gcc/fortran/interface.c:2091 0x57148e compare_actual_formal ../../trunk-src/gcc/fortran/interface.c:2589 0x571d23 gfc_procedure_use(gfc_symbol*, gfc_actual_arglist**, locus*) ../../trunk-src/gcc/fortran/interface.c:3292 0x5bd966 resolve_specific_s0 ../../trunk-src/gcc/fortran/resolve.c:3185 0x5bd966 resolve_specific_s ../../trunk-src/gcc/fortran/resolve.c:3204 0x5bd966 resolve_call ../../trunk-src/gcc/fortran/resolve.c:3360 0x5c2a47 resolve_code ../../trunk-src/gcc/fortran/resolve.c:9925 0x5c45ce resolve_codes ../../trunk-src/gcc/fortran/resolve.c:14546 0x5c44d7 resolve_codes ../../trunk-src/gcc/fortran/resolve.c:14532 0x5b53a5 gfc_resolve ../../trunk-src/gcc/fortran/resolve.c:14574 0x5b53a5 gfc_resolve(gfc_namespace*) ../../trunk-src/gcc/fortran/resolve.c:14560 0x5aabfa gfc_parse_file() ../../trunk-src/gcc/fortran/parse.c:4672 0x5e87c5 gfc_be_parse_file ../../trunk-src/gcc/fortran/f95-lang.c:188 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #7 from Andreas Schwab sch...@linux-m68k.org --- -0.00347222 3.6169e-05 -6.27934e-07 1.52623e-08 -4.76946e-10 1.82167e-11 -8.22281e-13 4.28272e-14 -2.52799e-15 1.66777e-16 -1.21608e-17 9.71178e-19 -8.43037e-20 7.90347e-21 -7.95835e-22 8.56628e-23 -9.81553e-24 1.19286e-24 -1.53249e-25 2.07525e-26 -2.95435e-27 4.41101e-28 -6.8922e-29 1.12477e-29 -1.91367e-30 3.38879e-31 -6.23632e-32 1.19096e-32 -2.35711e-33 4.82881e-34 -1.02277e-34 2.23731e-35 -5.04948e-36 1.17471e-36 -2.8144e-37 6.93827e-38 0.0468542
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #8 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- So the calculation inside __gfortran_erfc_scaled_r16 is correct, but the result is printed incorrectly. Can you try this: program test real(kind=16) :: x x = 10.9_16 ; print *, erfc_scaled(x) x = 11.9_16 ; print *, erfc_scaled(x) x = 12.0_16 ; print *, erfc_scaled(x) x = 12.1_16 ; print *, erfc_scaled(x) x = 13.1_16 ; print *, erfc_scaled(x) x = 14.1_16 ; print *, erfc_scaled(x) end program test Also, can you confirm that binary128 is not the same as long double on ia64? (I've sent a request to reopen my old account on the compile farm… If this drags out, I'll investigate on my own there. But for now, I don't have access to an ia64.)
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #9 from Andreas Schwab sch...@linux-m68k.org --- Looks like inv2x2 is wrong in _gfortran_erfc_scaled_r16: (gdb) i reg r42 r43 r420x0 0 r430x40072000 4613691527636451328
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #10 from Andreas Schwab sch...@linux-m68k.org --- 5.15453772226367323012693682499968245E-0002 4.72452324840876699523132987063922456E-0002 -1.87533922948603221391158058278771595E+0920 -5.09942677661379357690770320803840300E+0921 -2.70969365071138516780674252318715535E+0935 -1.40653905502094549174911373980686654E+0948
[Bug fortran/59229] New: [4.9.0 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 Bug ID: 59229 Summary: [4.9.0 Regression] ICE in ix86_expand_set_or_movmem Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de This happens in one of the most important codes in High energy physics, Pythia, (Janus may well know its importance), I would kindly urge you to solve this problem before the 4.9.0 release... Please. I do not break it down, and send the package as a whole. The regression happened within the last 4-8 weeks I would say, our continuos integration started failing this week (so it might be a _very_ recent commit. Ok, most probably, the file size is too big, here is a link: http://whizard.hepforge.org/svn/tags/release_2.2.0_alpha-4/src/pythia/pythia.f And this is the error: /bin/sh ../../libtool --tag=F77 --mode=compile gfortran -fopenmp -g -O2 -c -o pythia.lo ../../../src/pythia/pythia.f libtool: compile: gfortran -fopenmp -g -O2 -c ../../../src/pythia/pythia.f -fno-common -o .libs/pythia.o ../../../src/pythia/pythia.f: In function 'pygive': ../../../src/pythia/pythia.f:60990:0: internal compiler error: in ix86_expand_set_or_movmem, at config/i386/i386.c:23974 CHNAM=CHBIT(1:LNAM-1)//' ' ^ ../../../src/pythia/pythia.f:60990:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) ../../libtool: line 1122: 69952 Abort trap: 6 gfortran -fopenmp -g -O2 -c ../../../src/pythia/pythia.f -fno-common -o .libs/pythia.o
[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 --- Comment #22 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Manuel López-Ibáñez from comment #19) (In reply to Vincent Lefèvre from comment #18) This seems to be fixed in the trunk. Is there an XPASS for gcc.dg/uninit-pr19430.c ? Actually, with trunk revision 203899, only the last 3 tests now get the warning (those corresponding to -Wuninitialized). The first one (which should be a may be uninitialized) is still silent.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #11 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- So, it looks like the same code that works fine in an external C program, is miscompiled in libgfortran's _gfortran_erfc_scaled_r16. Do you agree? Can you remove the __builtin_printf call inside foo() in comment #6, and compile with the same flags as used to compile libgfortran? For me, that would be -std=gnu99 -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 Just to be sure…
[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 --- Comment #23 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- BTW, I suppose that in this test, -Wuninitialized should be changed to -Wuninitialized -Wmaybe-uninitialized in case it is decided later that -Wuninitialized no longer enables -Wmaybe-uninitialized (see PR59223 about that).
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Keywords||wrong-code --- Comment #12 from Andreas Schwab sch...@linux-m68k.org --- 1 / (2 * x * x) is calling __divtf3 from glibc, which operates on long double, not quad float. The function from libgcc.a should have been called instead.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #13 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #12) 1 / (2 * x * x) is calling __divtf3 from glibc, which operates on long double, not quad float. The function from libgcc.a should have been called instead. Because ia64 uses TFmode for both long double and __float128, while i386 uses XFmode for long double, is that it? I'm not sure what I can do, then… and don't understand why this does not happen in the standalone test case in comment #6.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Keywords|wrong-code | --- Comment #14 from Andreas Schwab sch...@linux-m68k.org --- I think this can be considered a glibc bug, which should not have defined __divtf3 in the first place (the function should have been called __divxf3), and the test should be XFAILd on ia64.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227
--- Comment #15 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #14)
I think this can be considered a glibc bug, which should not have defined
__divtf3 in the first place (the function should have been called __divxf3),
and the test should be XFAILd on ia64.
Is ia64-*-linux the right triplet? If you can confirm that the following
patch works as expect on your system, I'll commit it:
Index: erf_3.F90
===
--- erf_3.F90(revision 205151)
+++ erf_3.F90(working copy)
@@ -1,20 +1,29 @@
-! { dg-do run }
+! { dg-do run { xfail spu-*-* ia64-*-linux } }
! { dg-options -fno-range-check -ffree-line-length-none -O0 }
! { dg-add-options ieee }
!
! Check that simplification functions and runtime library agree on ERF,
! ERFC and ERFC_SCALED, for quadruple-precision.
+!
+! XFAILed for SPU targets because our library implementation of
+! the double-precision erf/erfc functions is not accurate enough.
+!
+! XFAILed for IA64 Linux because of a glibc bug:
+! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227
program test
+ use, intrinsic :: iso_fortran_env
implicit none
- real(kind=16) :: x16
+ ! QP will be the largest supported real kind, possibly real(kind=16)
+ integer, parameter :: qp = real_kinds(ubound(real_kinds,dim=1))
+ real(kind=qp) :: x
#define CHECK(a) \
- x16 = a ; \
- call check(erf(real(a,kind=16)), erf(x16)) ; \
- call check(erfc(real(a,kind=16)), erfc(x16)) ; \
- call check(erfc_scaled(real(a,kind=16)), erfc_scaled(x16))
+ x = a ; \
+ call check(erf(real(a,kind=qp)), erf(x)) ; \
+ call check(erfc(real(a,kind=qp)), erfc(x)) ; \
+ call check(erfc_scaled(real(a,kind=qp)), erfc_scaled(x))
CHECK(0.0)
CHECK(0.9)
@@ -36,7 +45,7 @@ program test
contains
subroutine check (a, b)
-real(kind=16), intent(in) :: a, b
+real(kind=qp), intent(in) :: a, b
print *, abs(a-b) / spacing(a)
if (abs(a - b) 10 * spacing(a)) call abort
end subroutine
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #16 from Andreas Schwab sch...@linux-m68k.org --- Perhaps a suitable workaround would be to force linking the right __divtf3 into libgfortran.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #17 from Andreas Schwab sch...@linux-m68k.org --- ia64 was using TFmode for 80 bit long double before r72916, so the __divtf3 name sticked for compatibility.
[Bug fortran/59229] [4.9.0 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-21 CC||Joost.VandeVondele at mat dot ethz ||.ch Ever confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Confirmed... very satisfying to see that this single file 8 lines programs are still bleeding edge.
[Bug fortran/59229] [4.9.0 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- reducing..
[Bug fortran/59229] [4.9.0 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 --- Comment #3 from Jürgen Reuter juergen.reuter at desy dot de --- Haha, thanks for the comment. To save my colleagues, they completely rewrote the program in C++ in a modern way, but experimental physicists are changing running system extremely reluctantly (remember what the Space Shuttles are running at^^)
[Bug fortran/59229] [4.9.0 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Reduced test case:
SUBROUTINE PYGIVE(CHIN)
IMPLICIT INTEGER(I-N)
CHARACTER CHIN*(*),CHBIT*104,CHNAM*6
LNAM=1
150 LNAM=LNAM+1
IF(CHBIT(LNAM:LNAM).NE.'('.AND.CHBIT(LNAM:LNAM).NE.'='.AND.
LNAM.LE.6) GOTO 150
CHNAM=CHBIT(1:LNAM-1)//' '
RETURN
END
-O2 is enough to trigger the ICE. Revision 203859 (2013-10-19) is OK, revision
204945(2013-11-18) gives the ICE.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #18 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Thu Nov 21 11:37:07 2013 New Revision: 205210 URL: http://gcc.gnu.org/viewcvs?rev=205210root=gccview=rev Log: PR libfortran/59227 * gfortran.dg/erf_3.F90: XFAIL on spu-* and ia64-*-linux*. Make more generic for other platforms. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/erf_3.F90
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #19 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #16) Perhaps a suitable workaround would be to force linking the right __divtf3 into libgfortran. I'm not sure how to force linking in libgfortran, but if it helps reliably fix quad-precision math on ia64, that sounds like a good option. Meanwhile, I've xfail'ed the test (also on spu-* due to a library issue there, similar to erf_2.F90).
[Bug fortran/59229] [4.9.0 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Revision 204901 (2013-11-16) seems OK (latest revision on an other machine, I'll have to check more carefully).
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #20 from Andreas Schwab sch...@linux-m68k.org --- It's not really a glibc bug, but a compatilibity wart.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #21 from Andreas Schwab sch...@linux-m68k.org --- I'm not sure how to force linking in libgfortran Add libgcc/divtf3_s.o to the link line.
[Bug sanitizer/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 --- Comment #7 from Dmitry Vyukov dvyukov at google dot com --- I've committed the fix into llvm: http://llvm.org/viewvc/llvm-project?view=revisionrevision=195345
[Bug target/59230] New: __divtf3@@GCC_4.4.0 missing from libgcc_s.so.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59230 Bug ID: 59230 Summary: __divtf3@@GCC_4.4.0 missing from libgcc_s.so.1 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Blocks: 59227 Target: ia64-*-* libgcc_s.so.1 does not provide the symbol __divtf3@@GCC_4.4.0, only the __divtf3@GCC_3.0 compatibility alias. This is causing the __divtf3 reference in libgfortran to be unversioned, and resolved to the compatibility alias during runtime.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 --- Comment #22 from Andreas Schwab sch...@linux-m68k.org --- Actually it appears to be a libgcc bug.
[Bug c/54954] malloc optimizations not disabled by -fno-builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54954
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Resolution|INVALID |WORKSFORME
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
I said it works for me because it works with -fno-builtin-malloc.
Andrew, you are wrong - the malloc attribute itself does not tell us
that the malloc call may not clobber global memory.
I've massaged the testcase to build w/o warnings:
m.c:
#include string.h
#include stdio.h
void *__libc_malloc(size_t size);
void *malloc(size_t size)
{
increment_count();
return (void*)__libc_malloc(size);
}
t.c:
#include assert.h
#include stdlib.h
#include stdio.h
static int count = 0;
void increment_count(void)
{
count++;
}
int main (void)
{
char *ptr;
count = 0;
ptr = malloc(1);
assert(ptr);
assert(count);
printf(%p\n, ptr);
free(ptr);
return 0;
}
rguenther@murzim:/tmp /space/rguenther/install/gcc-4.7.0/bin/gcc -o t t.c m.c
-O2 -fno-builtin-malloc
rguenther@murzim:/tmp ./t
0x1127010
rguenther@murzim:/tmp /space/rguenther/install/gcc-4.7.0/bin/gcc -o t t.c m.c
-O2
rguenther@murzim:/tmp ./t
t: t.c:18: main: Assertion `count' failed.
Aborted
Works with all GCC versions I tried. I tried on x86_64-linux (just in case
RTL optimizers break this in which case the target architecture may be
important).
[Bug c/59219] ____builtin___memcpy_chk and -fno-builtin-memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59219 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-21 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Please specify more thoroughly what you are asking for. Are you complaining that eventually calls to __memcpy_chk are emitted? Or are you complaining that we still expand memcpy inline even though you specified -fno-builtin? (but you used __builtin__memcpy_chk which retains its 'memcpy' specification because of the __builtin prefix)
[Bug fortran/59229] [4.9 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|[4.9.0 Regression] ICE in |[4.9 Regression] ICE in |ix86_expand_set_or_movmem |ix86_expand_set_or_movmem
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|V_MAY_DEF (taking address |taking address of a var |of var) causes missing |causes missing |uninitialized warning |uninitialized warning Severity|minor |enhancement --- Comment #24 from Richard Biener rguenth at gcc dot gnu.org --- Well, fact is we still don't have the machinery that warns for the use of uninitialized memory - and we never had. The cases that work by accident are for loads that alias-analysis can prove we can move to the function entry (well, a little less than that).
[Bug tree-optimization/59221] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59221 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-21 Target Milestone|--- |4.9.0 Summary|wrong code at -O2 and -O3 |[4.9 Regression] wrong code |on x86_64-linux-gnu |at -O2 and -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, disabling VRP fixes it.
[Bug tree-optimization/59245] New: ICE on valid code at -O3 on x86_64-linux-gnu in set_value_range, at tree-vrp.c:443
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59245
Bug ID: 59245
Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
set_value_range, at tree-vrp.c:443
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes).
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20131121 (experimental) [trunk revision 205234] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-4.8.2 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn2’:
small.c:18:1: internal compiler error: in set_value_range, at tree-vrp.c:443
fn2 ()
^
0xba89bc set_value_range
../../gcc-trunk/gcc/tree-vrp.c:443
0xbb913a extract_range_from_assert
../../gcc-trunk/gcc/tree-vrp.c:1749
0xbb913a extract_range_from_assignment
../../gcc-trunk/gcc/tree-vrp.c:3772
0xbba671 vrp_visit_assignment_or_call
../../gcc-trunk/gcc/tree-vrp.c:6742
0xbba671 vrp_visit_stmt
../../gcc-trunk/gcc/tree-vrp.c:7553
0xb00612 simulate_stmt
../../gcc-trunk/gcc/tree-ssa-propagate.c:324
0xb00bfd simulate_block
../../gcc-trunk/gcc/tree-ssa-propagate.c:447
0xb00bfd ssa_propagate(ssa_prop_result (*)(gimple_statement_base*, edge_def**,
tree_node**), ssa_prop_result (*)(gimple_statement_base*))
../../gcc-trunk/gcc/tree-ssa-propagate.c:854
0xbbb66b execute_vrp
../../gcc-trunk/gcc/tree-vrp.c:9710
0xbbb66b execute
../../gcc-trunk/gcc/tree-vrp.c:9801
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$
int a, b, c, e, g;
char d[5], f;
int
fn1 ()
{
if (b)
{
g = 0;
return 0;
}
for (f = 0; f != 1; f--)
;
return 0;
}
void
fn2 ()
{
d[4] = -1;
for (a = 4; a; a--)
{
fn1 ();
e = c -2147483647 - 1 - d[a] ? c : 0;
}
}
[Bug c++/59246] New: GCC should issue runtime error for calling pure virtual function with definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59246
Bug ID: 59246
Summary: GCC should issue runtime error for calling pure
virtual function with definition
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
Consider the following code:
struct Base
{
virtual void f() = 0 ;
virtual ~Base() ;
} ;
// pure virtual function with definition
void Base::f() { }
Base::~Base()
{
// call by unqualified name is virtual function call.
// virtual function call during destruction is undefined.
f() ;
}
GCC does not issue runtime abort for a virtual function that also has
definition.
According to the standard(10.4 paragraph 6), this is undefined.
Since this is undefined, GCC can do anything.
But I think GCC should issue runtime abort if it is technically possible.
Clang issues runtime abort for this code.
[Bug libstdc++/59247] New: Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59247 Bug ID: 59247 Summary: Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace' Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ai.azuma at gmail dot com I have come across errors in stage 1 build of libstdc++ when trying to build GCC 4.9-20131117 with the following commands on an x86_64-unknown-linux-gnu machine: $ $SRCDIR/configure --enable-languages=c,c++ --enable-symvers=gnu-versioned-namespace $ make Bootstrap succeeds when `--enable-symvers=gnu-versioned-namespace' is unset. GCC 4.7-20131116 and 4.8-20131107 can be built successfully with the option, thus this seems a regression.
[Bug c++/59246] GCC should issue runtime error for calling pure virtual function with definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59246 --- Comment #1 from Ryou Ezoe boostcpp at gmail dot com --- According to the de facto standard C++ ABI: http://mentorembedded.github.io/cxx-abi/abi.html#pure-virtual __cxa_pure_virtual will be called: if the user calls a non-overridden pure virtual function, which has undefined behavior according to the C++ Standard. When this abstract class Base's destructor was called, class objects derived from Base are already destructed. So it is non-overridden and it is also undefined behavior.
[Bug c++/59248] New: [4.8 regression] pointless -Wconversion warning with sizeof, take 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59248
Bug ID: 59248
Summary: [4.8 regression] pointless -Wconversion warning with
sizeof, take 2
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
The simple case was fixed with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56930 (thanks, Jason), but a
slightly more involved case still warns spuriously:
$ g++ -Wconversion -std=c++11 x.cc
x.cc: In function ‘int main()’:
x.cc:3:12: warning: conversion to ‘int’ from ‘long unsigned int’ may alter its
value [-Wconversion]
int x = 2*sizeof(int);
^
x.cc:4:12: warning: conversion to ‘int’ from ‘long unsigned int’ may alter its
value [-Wconversion]
int y { 2* sizeof(int) };
^
This didn't produce any warnings with gcc 4.7.3.
[Bug tree-optimization/59221] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59221 --- Comment #4 from Jeffrey A. Law law at redhat dot com --- Patch testing now.
[Bug tree-optimization/59025] [4.9 Regression] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-21 Ever confirmed|0 |1 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- This still needs more analysis I guess.
[Bug c++/59231] [4.8/4.9 Regression] gcc misses [-Werror=sign-compare] when inside a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59231 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #47 from Paulo J. Matos pa...@matos-sorge.com --- Would like to add that I backported the patch locally and all the testsuite is passing until now. The ICE I initially got is not gone as well. So I can confirm that as far as I know, the patch is indeed fine in 4.8.
[Bug ada/59234] New: Legal program rejected, a generic package having intricate formal package parameters could not be instantiated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59234 Bug ID: 59234 Summary: Legal program rejected, a generic package having intricate formal package parameters could not be instantiated Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: demoonlit at panathenaia dot halfmoon.jp Created attachment 31263 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31263action=edit minimal bug triggering source code It could not compile a generic package having intricate formal package parameters. The generic package (X) having two formal package parameters, another generic package (Y) and its child generic package (Y.C). The 2nd generic package (Y) also having a formal package parameter that is 4th generic package (Z). In this case, The generic package X could not be instantiated. (If Y.C or Z is removed, X would be able to be instantiated.) An example is in the attached file: $ gnatmake main.adb gcc -c main.adb main.adb:8:30: actual parameter must be instance of nested main.adb:8:30: instantiation abandoned gnatmake: main.adb compilation error This bug has also been discussed on comp.lang.ada. Some people suggested me to report. https://groups.google.com/d/msg/comp.lang.ada/3UyNvf6KXRE/sjJB1zcmg7kJ Regards.
[Bug target/59239] [SH] Improve decrement-and-test insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59239 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- Created attachment 31265 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31265action=edit Reduced test case There is one weird case in CSiBE in linux-2.4.23-pre3-testplatform/fs/iobuf.c (alloc_kiobuf_bhs) though, where the individual decrement and test insns end up in different basic blocks and only at the very end are emitted right next to each other without a label in between. Attached is the reduced case of the above.
[Bug fortran/45586] [4.8/4.9 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #97 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Richard Biener from comment #89) I believe the correct solution will involve implementing the proposal for introducing explicit restrict tags and using that in the fortran frontend (removing the restrict qualification work). See http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01011.html. I guess that has now become: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02727.html progress!
[Bug target/59233] [4.9 Regression] C++ failures after revision 205058 on *-apple-darwin* with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|x86_64-apple-darwin13 |*-apple-darwin* Host|x86_64-apple-darwin13 |*-apple-darwin* Summary|[4.9 Regression] C++|[4.9 Regression] C++ |failures after revision |failures after revision |205058 on |205058 on *-apple-darwin* |x86_64-apple-darwin13 with |with -m32 |-m32| Build|x86_64-apple-darwin13 |*-apple-darwin* --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The PR is exposed by r205058: if I compile the tests with r205057 (back to r202590) and -freorder-blocks-and-partition, I get the ICE. I see the same behavior on powerpc-apple-darwin9 (for both -m32 and -m64) and x86_64-apple-darwin10. Note that I don't get the ICE under a debugger.
[Bug c++/59236] Mixing -O0 and -O2 object causes link error because of corrupted comadts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59236 --- Comment #2 from Rafael Avila de Espindola rafael.espindola at gmail dot com --- (In reply to H.J. Lu from comment #1) Works on Linux/x86-64. Yes, it is a COFF only issue (tested on mingw).
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #45 from Paulo J. Matos pa...@matos-sorge.com --- Can we backport Bernd's patch of the 20th of September to 4.8? I just met this ICE in 4.8 and I guess we should still try to fix them in 4.8 since it's still maintained.
[Bug bootstrap/59235] New: [4.9 regression] SEGV in sparc_output_scratch_registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59235
Bug ID: 59235
Summary: [4.9 regression] SEGV in
sparc_output_scratch_registers
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, law at gcc dot gnu.org
Host: sparc-sun-solaris2.*
Target: sparc-sun-solaris2.*
Build: sparc-sun-solaris2.*
Solaris/SPARC bootstrap got broken between rev 204842 and 205096: the stage2
sparcv9 libgcc fails to configure, as can be seen with the following testcase:
$ cat conftest.c
int
main (void)
{
return 0;
}
$ ./cc1 -fpreprocessed conftest.c -mptr64 -mstack-bias -mno-v8plus -mcpu=v9
-quiet -m64 -o conftest.s
conftest.c: In function 'main':
Segmentation Fault
The SEGV happens here:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x0069c314 in sparc_output_scratch_registers(__FILE*) [clone .part.32] ()
(gdb) where
#0 0x0069c314 in sparc_output_scratch_registers(__FILE*) [clone .part.32] ()
#1 0x0069c3ac in sparc_asm_function_prologue(__FILE*, long long) ()
#2 0x00281df0 in final_start_function(rtx_def*, __FILE*, int) ()
#3 0x00282294 in (anonymous namespace)::pass_final::execute() ()
#4 0x003d3050 in execute_one_pass(opt_pass*) ()
#5 0x003d32e0 in execute_pass_list(opt_pass*) ()
#6 0x003d3304 in execute_pass_list(opt_pass*) ()
#7 0x003d3304 in execute_pass_list(opt_pass*) ()
#8 0x001c7bd4 in expand_function(cgraph_node*) ()
#9 0x001c9d74 in compile() ()
#10 0x001ca050 in finalize_compilation_unit() ()
#11 0x000d4f3c in c_write_global_declarations() ()
#12 0x004876a8 in compile_file() ()
#13 0x00489784 in toplev_main(int, char**) ()
#14 0x000c1074 in _start ()
A reghunt traced this to the following patch:
2013-11-19 Jeff Law l...@redhat.com
* tree-ssa-threadedge.c (thread_across_edge): After threading
through a joiner, allow threading a normal block requiring duplication.
* tree-ssa-threadupdate.c (thread_block_1): Improve code to detect
I'm currently running a bootstrap with the patch reverted to see if everything
is ok without.
Rainer
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/59179] [4.9 Regression] Wrong code generated with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59179 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-11-21 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- It prints ./prog 0x8e15008 0x8e15018 for me (x86_64 with -m32).
[Bug target/59239] [SH] Improve decrement-and-test insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59239
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #0)
Created attachment 31264 [details]
Possible cleanup patch
After applying the patch and replacing the doloop_end expander with
(define_expand doloop_end
[(use (match_operand:SI 0 arith_reg_dest)) ; loop count pseudo
(use (match_operand 1))] ; label
TARGET_SH2
{
emit_insn (gen_dect (operands[0], operands[0]));
emit_jump_insn (gen_branch_false (operands[1]));
DONE;
})
will expose the individual decrement-and-test and cbranch insns early. This
shows quite some changes in the CSiBE set. The decrement-and-test insn will be
used less frequently and there are some code size increases with the worst case
being
src/nrrd/convertNrrd 4868 - 5240+372 / +7.641742 %
On the other hand, it causes an overall code size decrease of -3944 bytes on
the whole CSiBE set with some of the highlights being
teem-1.6.0-src src/nrrd/tmfKernel 132652 - 131520 -1132 / -0.853361 %
mpeg2dec-0.3.1 libmpeg2/decode 2820 - 2620 -200 / -7.092199 %
it looks like fewer registers are used and some loop counter setup calculations
are smaller.
[Bug target/58630] [4.9 Regression] Revision 203171 breaks several MS-ABI tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58630 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|REOPENED|NEW --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #28 from Rick Regan exploringbinary at gmail dot com --- Yes, that makes sense. I originally (mistakingly) thought that SIGNIFICAND_BITS was the intermediate precision for mpfr_strtofr(), like it was for gcc's original algorithm. Then I talked myself out of the needs more precision argument based on my interpretation of your response. So then is the round to zero/stickiness just to avoid double rounding (as opposed to using round to nearest/no stickiness)? BTW, I'm testing out the code. I tried a test I found in float-exact-1.c: it's the literal assigned to the double named d1c. When I run it (on a 64-bit system) with the fix I get 0x0.1p-1022; strtod() (David Gay's and glibc's) gives me 0. Also, before the fix, I get warning: floating constant truncated to zero and the conversion is correct; after the fix, no message, and an incorrect conversion.
[Bug lto/51635] LTO should not merge (type) decls with different locations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Richard Biener rguenth at gcc dot gnu.org --- Let's close this - the new tree merging has landed and should have improved all this. (fingers crossing).
[Bug tree-optimization/59221] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59221 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law law at redhat dot com --- Fixed on trunk. Again, sorry for the breakage.
[Bug c++/59240] New: ICE in varpool_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59240 Bug ID: 59240 Summary: ICE in varpool_get_node Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kilobyte at angband dot pl Created attachment 31266 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31266action=edit deltaed test case With gcc-snapshot 20131121-1, running g++ on the attached code fails with: cc1plus: internal compiler error: in varpool_get_node, at cgraph.h:890 (the actual file the delta comes from is valid code).
[Bug c++/57946] [4.7/4.8/4.9 Regression] internal compiler error: Segmentation fault in int_fits_type_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57946 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/59133] [4.9 regression] ICE after r204219 on SPEC2006 435.gromacs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59133 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed I assume.
[Bug target/59233] [4.9 Regression] C++ failures after revision 205058 on *-apple-darwin* with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233 --- Comment #6 from Teresa Johnson tejohnson at google dot com --- On Thu, Nov 21, 2013 at 7:10 AM, tejohnson at google dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233 --- Comment #5 from Teresa Johnson tejohnson at google dot com --- Reproduced with cross compiler: $ /usr/local/google/home/tejohnson/gcc_trunk_9_x86_64-apple-darwin10/bld-gcc/./gcc/xg++ -B/usr/local/google/home/tejohnson/gcc_trunk_9_x86_64-apple-darwin10/bld-gcc/./gcc/ -B/usr/local/google/home/tejohnson/gcc_trunk_9_x86_64-apple-darwin10/install/x86_64-apple-darwin10/bin/ -B/usr/local/google/home/tejohnson/gcc_trunk_9_x86_64-apple-darwin10/install/x86_64-apple-darwin10/lib/ -isystem /usr/local/google/home/tejohnson/gcc_trunk_9_x86_64-apple-darwin10/install/x86_64-apple-darwin10/include -isystem /usr/local/google/home/tejohnson/gcc_trunk_9_x86_64-apple-darwin10/install/x86_64-apple-darwin10/sys-include -c -m32 -Os pr52772.C pr52772.C: In member function ‘int c8::tria(c7*, c5*)’: pr52772.C:85:1: internal compiler error: Segmentation fault } ^ 0xb657af crash_signal /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/toplev.c:336 0xff4e1d old_insns_match_p /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:1128 0xff4e1d old_insns_match_p /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:1093 0xff5943 outgoing_edges_match /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:1754 0xff5943 try_crossjump_to_edge /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:1927 0xff6ed4 try_crossjump_bb /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:2252 0xff6ed4 try_crossjump_bb /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:2138 0xff7a6c try_optimize_cfg /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:2808 0xff7a6c cleanup_cfg(int) /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:3014 0xff9836 execute_jump2 /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:3123 0xff9836 execute /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:3152 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. In debugger: Program received signal SIGSEGV, Segmentation fault. old_insns_match_p (i2=0x76390cc0, i1=0x76390d00, mode=2) at /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:1128 1128 if (GET_CODE (p1) != GET_CODE (p2)) (gdb) p p1 $1 = (rtx) 0x0 (gdb) p p2 $2 = (rtx) 0x0 (gdb) p i1 $3 = (rtx) 0x76390d00 (gdb) p i2 $4 = (rtx) 0x76390cc0 (gdb) p debug_rtx(i1) (note 170 134 58 7 NOTE_INSN_DELETED) $5 = void (gdb) p debug_rtx(i2) (note 169 130 87 11 NOTE_INSN_DELETED) $6 = void So it doesn't handle NOTE_INSN_DELETED. Looking at the caller: (gdb) up #1 old_insns_match_p (mode=2, i1=0x76390d00, i2=0x76390cc0) at /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:1093 1093 old_insns_match_p (int mode ATTRIBUTE_UNUSED, rtx i1, rtx i2) (gdb) up #2 0x00ff5944 in outgoing_edges_match (bb2=0x7639b270, bb1=0x7639b2d8, mode=2) at /usr/local/google/home/tejohnson/gcc_trunk_9/gcc/cfgcleanup.c:1754 1754 if (old_insns_match_p (mode, last1, last2) != dir_both) (gdb) p debug_bb(bb1) (code_label/s 131 154 134 7 17 [1 uses]) (note 134 131 170 7 [bb 7] NOTE_INSN_BASIC_BLOCK) (note 170 134 58 7 NOTE_INSN_DELETED) $11 = void (gdb) p debug_bb(bb2) (code_label/s 127 167 130 11 16 [1 uses]) (note 130 127 169 11 [bb 11] NOTE_INSN_BASIC_BLOCK) (note 169 130 87 11 NOTE_INSN_DELETED) $12 = void Looking to see what the right solution is here - either old_insns_match_p should handle this or caller outgoing_edges_match should avoid calling old_insns_match_p on these instruction types. I have added handling to outgoing_edges_match to ignore these and other types of notes that it doesn't understand, just as it was ignoring debug instructions. This fixes the immediate problem. But the next question is how does -freorder-blocks-and-partition cause an issue, since it won't do anything with -Os? The reason is that in except.c when expanding landing pads, under flag_reorder_blocks_and_partition the edges are marked with EDGE_PRESERVE, which means some block combining upstream of jump2 is not occurring, resulting in the attempt at optimizing this block. Note that later on the EDGE_PRESERVE flag is removed by find_rarely_executed_basic_blocks_and_crossing_edges. However, in this case since we have -Os, bbpart is gated off, and we never execute find_rarely_executed_basic_blocks_and_crossing_edges. Additionally, we can detect earlier during except.c that we will not even attempt bbpart. In order to do this I have moved the body of gate_handle_partition_blocks to a new function do_partition_blocks
[Bug tree-optimization/59221] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59221 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- It seems to be DOM1 doing strange things here, maybe Jeff would see immediately what goes wrong? This was working a month ago.
[Bug target/59233] New: [4.9 Regression] C++ failures after revision 205058 on x86_64-apple-darwin13 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233 Bug ID: 59233 Summary: [4.9 Regression] C++ failures after revision 205058 on x86_64-apple-darwin13 with -m32 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, tejohnson at gcc dot gnu.org Host: x86_64-apple-darwin13 Target: x86_64-apple-darwin13 Build: x86_64-apple-darwin13 Created attachment 31262 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31262action=edit Preprocessed file for g++.dg/torture/pr52772.C The following failures appeared on x86_64-apple-darwin13 with -m32 after revision 205058 (205507 is OK): FAIL: g++.dg/opt/pr57661.C (internal compiler error) FAIL: g++.dg/opt/pr57661.C (test for excess errors) FAIL: g++.dg/torture/pr52772.C -Os (internal compiler error) FAIL: g++.dg/torture/pr52772.C -Os (test for excess errors) FAIL: 23_containers/list/debug/invalidation/4.cc (test for excess errors) UNRESOLVED: 23_containers/list/debug/invalidation/4.cc compilation failed to produce executable FAIL: ext/rope/2.cc (test for excess errors) UNRESOLVED: ext/rope/2.cc compilation failed to produce executable FAIL: ext/rope/5.cc (test for excess errors) [Book15] f90/bug% g++ -c pr52772.ii -m32 -Os /opt/gcc/work/gcc/testsuite/g++.dg/torture/pr52772.C: In member function 'int c8::tria(c7*, c5*)': /opt/gcc/work/gcc/testsuite/g++.dg/torture/pr52772.C:85:1: internal compiler error: Segmentation fault: 11 } ^ /opt/gcc/work/gcc/testsuite/g++.dg/torture/pr52772.C:85:1: internal compiler error: Abort trap: 6 g++: internal compiler error: Abort trap: 6 (program cc1plus) Abort [Book15] f90/bug% g++ -c pr57661.ii -m32 -O2 -fno-tree-forwprop -std=gnu++11 /opt/gcc/work/gcc/testsuite/g++.dg/opt/pr57661.C: In destructor 'IU, V::~I() [with U = char; V = Cchar]': /opt/gcc/work/gcc/testsuite/g++.dg/opt/pr57661.C:50:3: internal compiler error: Segmentation fault: 11 } ^ /opt/gcc/work/gcc/testsuite/g++.dg/opt/pr57661.C:50:3: internal compiler error: Abort trap: 6 g++: internal compiler error: Abort trap: 6 (program cc1plus) Abort I am attaching the preprocessed file for g++.dg/torture/pr52772.C.
[Bug target/59233] [4.9 Regression] C++ failures after revision 205058 on *-apple-darwin* with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-21 Ever confirmed|0 |1 --- Comment #4 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Teresa Johnson from comment #3) On Thu, Nov 21, 2013 at 6:10 AM, dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- The ICE with -freorder-blocks-and-partition appeared between revisions 200946 (OK, 2013-07-14) and 201266 (ICE, 2013-07-26). Taking a look. Since I can't reproduce on x86-64-unknown-linux-gnu I am going to build a cross-compiler for x86_64-apple-darwin10 and see if I can reproduce it. I looked at the range of revisions you mention above and there weren't any partitioning specific changes, so it is probably a side effect of some other change in that range. confirmed with TOT on x86_64-darwin12 for -m32 -Os only, other optimisation levels are OK. /src/gcc-live-trunk/gcc/testsuite/g++.dg/torture/pr52772.C: In member function ‘int c8::tria(c7*, c5*)’: /src/gcc-live-trunk/gcc/testsuite/g++.dg/torture/pr52772.C:85:1: internal compiler error: Segmentation fault: 11 }
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #27 from Joseph S. Myers jsm28 at gcc dot gnu.org --- No, it was lack of precision. MPFR may need to use many more than SIGNIFICAND_BITS internally in order to compute a result that is correctly rounded towards zero to SIGNIFICAND_BITS (plus the ternary value), but GCC doesn't need to know or care how many bits MPFR uses; all it needs to know is that SIGNIFICAND_BITS is at least 2 more than the largest number in any supported binary floating-point format. Having got the C11 features I wanted into 4.9 I then looked for bugs on my list of conformance issues that would be more suited to development stage 1 (ends today) than to subsequent stabilization stages. This was one.
[Bug target/59229] [4.9 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Priority|P3 |P1 Component|fortran |target
[Bug rtl-optimization/59137] [4.7/4.8/4.9 Regression] Miscompilation at -O1 on mips/mipsel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59137 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/59110] [4.9 Regression] [c++1y] ICE using auto in cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59110 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 --- Comment #25 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Vincent Lefèvre from comment #23) BTW, I suppose that in this test, -Wuninitialized should be changed to -Wuninitialized -Wmaybe-uninitialized in case it is decided later that -Wuninitialized no longer enables -Wmaybe-uninitialized (see PR59223 about that). I don't see any reason for -Wuninitialized to not enable -Wmaybe-uninitialized.
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 --- Comment #26 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Manuel López-Ibáñez from comment #25) I don't see any reason for -Wuninitialized to not enable -Wmaybe-uninitialized. I can see 3 kinds of use: 1. Users who are interested in neither: they just don't use these options (if they want to use -Wall, they need the -Wno- version). 2. Users interested in -Wuninitialized but not in -Wmaybe-uninitialized (to avoid potential many false positives). Because -Wuninitialized enables -Wmaybe-uninitialized, they need 2 options: -Wuninitialized -Wno-maybe-uninitialized. If -Wuninitialized did not enable -Wmaybe-uninitialized, only one option would be needed: -Wuninitialized. 3. Users interested in both. I think that -Wmaybe-uninitialized should enable -Wuninitialized because it makes no sense to have -Wmaybe-uninitialized but not -Wuninitialized. Indeed, if some variable is uninitialized, then it may be uninitialized. So, only one option should be needed in this case: -Wmaybe-uninitialized.
[Bug tree-optimization/59221] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59221 --- Comment #7 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Jeffrey A. Law from comment #6) Fixed on trunk. Again, sorry for the breakage. Thanks Jeff. That was quick!
[Bug fortran/59228] ICE with assume type and ASYNCHRONOUS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59228 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
[Bug tree-optimization/59058] [4.7/4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Nov 21 14:09:15 2013 New Revision: 205217 URL: http://gcc.gnu.org/viewcvs?rev=205217root=gccview=rev Log: 2013-11-21 Richard Biener rguent...@suse.de PR tree-optimization/59058 * tree-scalar-evolution.h (number_of_exit_cond_executions): Remove. * tree-scalar-evolution.c (number_of_exit_cond_executions): Likewise. * tree-vectorizer.h (LOOP_PEELING_FOR_ALIGNMENT): Rename to ... (LOOP_VINFO_PEELING_FOR_ALIGNMENT): ... this. (NITERS_KNOWN_P): Fold into ... (LOOP_VINFO_NITERS_KNOWN_P): ... this. (LOOP_VINFO_PEELING_FOR_NITER): Add. * tree-vect-loop-manip.c (vect_gen_niters_for_prolog_loop): Use LOOP_VINFO_PEELING_FOR_ALIGNMENT. (vect_do_peeling_for_alignment): Re-use precomputed niter instead of re-emitting it. * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Use LOOP_VINFO_PEELING_FOR_ALIGNMENT. * tree-vect-loop.c (vect_get_loop_niters): Use number_of_latch_executions. (new_loop_vec_info): Initialize LOOP_VINFO_PEELING_FOR_NITER. (vect_analyze_loop_form): Simplify. (vect_analyze_loop_operations): Move epilogue peeling code ... (vect_analyze_loop_2): ... here and adjust it to compute LOOP_VINFO_PEELING_FOR_NITER. (vect_estimate_min_profitable_iters): Use LOOP_VINFO_PEELING_FOR_ALIGNMENT. (vect_build_loop_niters): Emit on the preheader. (vect_generate_tmps_on_preheader): Likewise. (vect_transform_loop): Use LOOP_VINFO_PEELING_FOR_NITER instead of recomputing it. Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-scalar-evolution.h trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.h
[Bug c++/59236] New: Mixing -O0 and -O2 object causes link error because of corrupted comadts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59236
Bug ID: 59236
Summary: Mixing -O0 and -O2 object causes link error because of
corrupted comadts
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Target: mingw
$ cat test1.cpp
#include test.h
struct zed : public foo {
virtual ~zed();
};
zed::~zed() {}
$ cat test2.cpp
#include test.h
struct zed2 : public foo {
virtual ~zed2();
};
zed2::~zed2() {}
$ cat test.h
class foo {
virtual void bar() { __builtin_unreachable(); }
};
$ i686-w64-mingw32-g++ -fno-rtti -fno-exceptions -c test1.cpp
$ i686-w64-mingw32-g++ -fno-rtti -fno-exceptions -c test2.cpp -O2
$ i686-w64-mingw32-g++ -fno-rtti -fno-exceptions test1.o test2.o -o t.so
-shared
test2.o:test2.cpp:(.text$_ZN3foo3barEv+0x0): multiple definition of
`foo::bar()'
test1.o:test1.cpp:(.text$_ZN3foo3barEv[__ZN3foo3barEv]+0x0): first defined here
collect2: error: ld returned 1 exit status
The problem seems to be that test1.o has
3 .text$_ZN3foo3barEv 000c 014c 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE, LINK_ONCE_DISCARD
(COMDAT __ZN3foo3barEv 4)
while test2.o has
4 .text$_ZN3foo3barEv 2**4
ALLOC, LOAD, READONLY, CODE, LINK_ONCE_DISCARD
noticed that the comdat symbol is missing.
[Bug libgomp/59194] tsan detects race for real variables in an OMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #9 from Dmitry Vyukov dvyukov at google dot com --- (In reply to Jakub Jelinek from comment #4) Because CPUs obviously don't have floating point atomic instructions, what the compiler does is just load it as an integer, view convert to floating point, perform arithmetics, view convert result back to integer, and compare and swap (if unsuccessful loop). I bet tsan complains because the load is not atomic, but does it really matter? If we read garbage there, compare and swap will fail and next time we'll have hopefully correct value already from what compare and swap said was the previous value. Data races do not work this way. It's undefined behavior: http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong The code must use relaxed atomic load. If the code becomes slower due to that then: (1) the current generated code is incorrect or (2) there is a performance bug in gcc handling of atomic operations
[Bug target/59216] [4.9 Regression] ARM negdi*extendsidi regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59216 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Summary|[[4.9 Regression] ARM] |[4.9 Regression] ARM |negdi*extendsidi regression |negdi*extendsidi regression
[Bug c++/59238] New: Dynamic allocating a list-initialized object of a type with private destructor fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238
Bug ID: 59238
Summary: Dynamic allocating a list-initialized object of a type
with private destructor fails.
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Consider:
class foo {
~foo() {}
};
int main() {
new foo; // OK
new foo(); // OK
new foo{}; // error: 'foo::~foo()' is private
}
The last line shouldn't fail to compile since the destructor is not invoked.
FWIW, it compiles fine with clang. It also compiles fine with gcc 4.9.0
20131109 if foo has a user declared default constructor.
[Bug tree-optimization/59221] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59221 --- Comment #5 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Thu Nov 21 19:45:16 2013 New Revision: 205229 URL: http://gcc.gnu.org/viewcvs?rev=205229root=gccview=rev Log: PR tree-optimization/59221 * tree-ssa-threadedge.c (thread_across_edge): Properly manage temporary equivalences when threading through joiner blocks. PR tree-optimization/59221 * gcc.c-torture/execute/pr59221.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr59221.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadedge.c
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #26 from Rick Regan exploringbinary at gmail dot com --- So the problem was never lack of precision -- just lack of stickiness. We were seeing higher precision making more conversions work (e.g., more worked with 192 bits than 160), but ultimately, stickiness was required to augment the limited precision. This will fix the architecture-dependent aspect of the bug as well. I suppose you could have fixed the existing algorithm, although admittedly using MPFR is a simple and elegant solution. BTW, why was this fixed now, and not when an MPFR based solution was discussed four/five/six years ago? You certainly could have done it a few weeks ago, before I wrote all those articles :).
[Bug sanitizer/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Fixed (works for me now).
[Bug bootstrap/59235] [4.9 regression] SEGV in sparc_output_scratch_registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59235 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-21 Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Probably the same dumb oversight that's causing 59221. I will, of course, verify that and take appropriate action. It's things like this that sometimes makes me question bootstrapping and regression testing's value :( Note that this is precisely a bootstrap failure, just not on your platform.
[Bug sanitizer/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #16 from Dmitry Vyukov dvyukov at google dot com --- (In reply to Jonathan Wakely from comment #10) No, you're right, that's a different issue. I think we've just been relying on loads of (correctly-aligned) _Atomic_word being atomic, although that's not going to keep tsan happy! There's no barrier on the read, but I think the worst that will happen is we won't see the correct value and the CAS loop will go round again. We won't see __count==0 spuriously, because once that count reaches zero it never gets incremented again. Data races do not work this way. It's undefined behavior: http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong The code must use relaxed atomic load. If the code becomes slower due to that then: (1) the current generated code is incorrect or (2) there is a performance bug in gcc handling of atomic operations
[Bug sanitizer/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Kostya Serebryany from comment #1) one other problem would be that we have zero tests for tsan in gcc :( It would be great if someone could do something about that, even just a single test would have shown this problem, which I think has been there for at least a week.
[Bug libstdc++/59237] New: FAIL: ext/random/hypergeometric_distribution/operators/values.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59237
Bug ID: 59237
Summary: FAIL:
ext/random/hypergeometric_distribution/operators/value
s.cc (test for excess errors)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
On x86, I got
/export/gnu/import/git/gcc/libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/operators/values.cc:
In function 'void test01()':^M
/export/gnu/import/git/gcc/libstdc++-v3/testsuite/ext/random/hypergeometric_distribution/operators/values.cc:36:42:
error: missing template arguments before 'hd1'^M
__gnu_cxx::hypergeometric_distribution hd1{15, 3, 2};^M
^^M
