[Bug gcov-profile/57121] New: undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 Bug #: 57121 Summary: undefined reference to gcov_merge_init and gcov_merge_add Classification: Unclassified Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: netravathi.munir...@asia.thalesgroup.com Hi, I am trying to compile the code base while adding the following flags GCOV_CFLAGS = -fprofile-use -fprofile-arcs -ftest-coverage -fprofile-generate CXXFLAGS = $(DEBUGOPT) -m32 -pipe -fexceptions -fPIC -Wno-deprecated $(GCOV_CFLAGS) $(CXXDEFINES) $(CXXINCLUDE) CCFLAGS = $(DEBUGOPT) -m32 -pipe -fexceptions -fPIC $(GCOV_CFLAGS) $(CXXDEFINES) $(CXXINCLUDE) LDLIBS = $(ALAEXTLIB) $(SCS_LIB) $(ORB_LIB) $(APP_LIBDIR) $(APP_LIB) $(NELLIBDIR) $(TCL_LIB) -lgcov LDFLAGS = $(DEBUGOPT) $(GCOV_CFLAGS) -fPIC -m32 -s -O -shared -lgcov === After adding this Make file, I am getting the following errors /home/neldev/workspace/C755A-859/sim/mdb/obj/mdbc.o: In function `global constructors keyed to 0_mdbc_a_errstr': /home/neldev/workspace/C755A-859/mdb/MDB/MDBC/mdbc.c:718: undefined reference to `__gcov_init' /home/neldev/workspace/C755A-859/sim/mdb/obj/mdbc.o:(.data.rel+0xa24): undefined reference to `__gcov_merge_add' /home/neldev/workspace/C755A-859/sim/mdb/obj/mdb_query_i.o: In function `global constructors keyed to 0_mdb_query_g_cb': /home/neldev/workspace/C755A-859/mdb/QUERY/QUERY_I/mdb_query_i.c:6489: undefined reference to `__gcov_init' /home/neldev/workspace/C755A-859/sim/mdb/obj/mdb_query_i.o:(.data.rel+0x164): undefined reference to `__gcov_merge_add' /home/neldev/workspace/C755A-859/mdb/LIB/lib_mdb.a(mdb.o): In function `global constructors keyed to 0_mdb_init': /home/neldev/workspace/C755A-859/mdb/MDB/mdb.c:5832: undefined reference to `__gcov_init' /home/neldev/workspace/C755A-859/mdb/LIB/lib_mdb.a(mdb.o):(.data+0x2a4): undefined reference to `__gcov_merge_add' /home/neldev/workspace/C755A-859/mdb/LIB/lib_mdb.a(mdb_i.o): In function `global constructors keyed to 0_mdb_g_ctrl_init_rel': /home/neldev/workspace/C755A-859/mdb/MDB/mdb_i.c:7459: undefined reference to `__gcov_init' /home/neldev/workspace/C755A-859/mdb/LIB/lib_mdb.a(mdb_i.o):(.data+0x244): undefined reference to `__gcov_merge_add' /home/neldev/workspace/C755A-859/mdb/LIB/lib_mdb.a(mdb_sys_io.o): In function `global constructors keyed to 0__Z19mdb_sys_opencw_sficPc': /home/neldev/workspace/C755A-859/mdb/MDB/mdb_sys_io.c:254: undefined reference to `__gcov_init' /home/neldev/workspace/C755A-859/mdb/LIB/lib_mdb.a(mdb_sys_io.o):(.data+0x64): undefined reference to `__gcov_merge_add' /home/neldev/workspace/C755A-859/mdb/LIB/lib_mdb.a(mdb_sys_hpux.o): In function `global constructors keyed to 0_mdb_sys_g_tab_nbentcfg': /home/neldev/workspace/C755A-859/mdb/MDB/mdb_sys_hpux.c:1049: undefined reference to `__gcov_init' /home/neldev/workspace/C755A-859/mdb/LIB/lib_mdb.a(mdb_sys_hpux.o):(.data+0x84): undefined reference to `__gcov_merge_add' /home/neldev/workspace/C755A-859/mdb/LIB/lib_query.a(mdb_query.o): In function `global constructors keyed to 0_main': /home/neldev/workspace/C755A-859/mdb/QUERY/mdb_query.c:173: undefined reference to `__gcov_init' /home/neldev/workspace/C755A-859/mdb/LIB/lib_query.a(mdb_query.o):(.data+0x44): undefined reference to `__gcov_merge_add' /home/neldev/workspace/C755A-859/mdb/LIB/lib_query.a(mdb_query_cb.o): In function `global constructors keyed to 0__Z15mdb_query_cb_unP14mdb_t_cb_razonPcS1_': /home/neldev/workspace/C755A-859/mdb/QUERY/mdb_query_cb.c:927: undefined reference to `__gcov_init' /home/neldev/workspace/C755A-859/mdb/LIB/lib_query.a(mdb_query_cb.o):(.data+0x84): undefined reference to `__gcov_merge_add' /home/neldev/workspace/C755A-859/mdb/LIB/lib_query.a(mdb_query_trt.o): In function `global constructors keyed to 0_mdb_query_trt_n_line': /home/neldev/workspace/C755A-859/mdb/QUERY/mdb_query_trt.c:380: undefined reference to `__gcov_init' /home/neldev/workspace/C755A-859/mdb/LIB/lib_query.a(mdb_query_trt.o):(.data+0x44): undefined reference to `__gcov_merge_add' === I can get rid of this error while removing fprofile-arcs..so I am getting this error if I add -fprofile- flags. I did search in google and tried as much as I could however still the same.. Please guide me on the way to fix this errors. Thanks.
[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 Netra changed: What|Removed |Added Keywords||link-failure Severity|normal |blocker
[Bug middle-end/57107] [4.9 Regression] tree check fail in unlink_stmt_vdef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57107 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Component|c++ |middle-end AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.9.0 Summary|tree check fail in |[4.9 Regression] tree check |unlink_stmt_vdef|fail in unlink_stmt_vdef --- Comment #4 from Richard Biener 2013-04-30 08:24:44 UTC --- I will have a look.
[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 --- Comment #1 from Netra 2013-04-30 08:35:07 UTC --- adding on to my previous comment, running on RHEL 5.
[Bug sanitizer/57104] ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57104 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2013-04-30 08:56:02 UTC --- Author: jakub Date: Tue Apr 30 08:52:39 2013 New Revision: 198445 URL: http://gcc.gnu.org/viewcvs?rev=198445&root=gcc&view=rev Log: PR tree-optimization/57104 * tsan.c (instrument_expr): Don't instrument accesses to DECL_HARD_REGISTER VAR_DECLs. * gcc.dg/pr57104.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr57104.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tsan.c Author: jakub Date: Tue Apr 30 08:53:45 2013 New Revision: 198446 URL: http://gcc.gnu.org/viewcvs?rev=198446&root=gcc&view=rev Log: PR tree-optimization/57104 * tsan.c (instrument_expr): Don't instrument accesses to DECL_HARD_REGISTER VAR_DECLs. * gcc.dg/pr57104.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr57104.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tsan.c
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Paolo Carlini changed: What|Removed |Added CC||ktietz at gcc dot gnu.org Component|libstdc++ |target --- Comment #1 from Paolo Carlini 2013-04-30 09:23:39 UTC --- Kai, can you please help triaging this?
[Bug tree-optimization/57122] New: ICE in verify_loop_structure, at cfgloop.c:1647 (loop n’s latch does not have an edge to its header !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57122
Bug #: 57122
Summary: ICE in verify_loop_structure, at cfgloop.c:1647 (loop
n’s latch does not have an edge to its header !)
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Using GCC 4.9.0 as of 20130430 :
$ cat latch.c
unsigned a;
int b, c;
void f(void)
{
if(a)
{
for(a = 0; a < 2; a++)
a /= 7;
for(;; a++)
{
if(a)
lbl1:
b++;
if(c)
goto lbl1;
lbl2:
;
}
}
goto lbl2;
}
$ xgcc -O2 -w latch.c
latch.c: In function ‘f’:
latch.c:4:6: error: loop 2’s latch does not have an edge to its header
void f(void)
^
latch.c:4:6: internal compiler error: in verify_loop_structure, at
cfgloop.c:1647
0x61aba5 verify_loop_structure()
../../srcdir/gcc/cfgloop.c:1647
0x7fe2ad loop_optimizer_init(unsigned int)
../../srcdir/gcc/loop-init.c:110
0xa3cf4d do_pre
../../srcdir/gcc/tree-ssa-pre.c:4708
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 web/50642] onlinedocs formated text too small to read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50642 --- Comment #9 from Shakthi Kannan 2013-04-30 09:54:50 UTC --- Created attachment 29978 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29978 Override @smallexample attributes The attached patch overrides the default @smallexample attributes defined by makeinfo. It includes a html.css file where the smallexample attributes are defined to use a medium font size with a light blue background for readability and clarity. The patch has also been sent to the gcc-patches mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01766.html
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Kai Tietz 2013-04-30 10:33:59 UTC --- Hmm, I can't reproduce that. I just built things myself again for 4.8.1 gcc. I am a bit curious to read that due distributions like Fedora seem to be able to build stuff without isssues for 4.8.x gcc. First advice would be to look into libstdc++'s config.log to see why for you shared library isn't built. Second question is how you are actual configuring it, and what additional patches you might use on built?
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #3 from Dongsheng Song 2013-04-30 10:42:21 UTC --- Created attachment 29979 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29979 x86_64-w64-mingw32/libstdc++-v3/config.log
[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Kai Tietz 2013-04-30 10:42:28 UTC --- No this change wasn't hastily nor wrong. Actual the change makes things compliant to logic already used for cygwin for years. Additional it fixed a quirk there was about eh-code sometimes not using shared version, if it actual was necessary to. The point is, if you want to avoid dependency to DLL libgcc version, then please use support static option for it. Otherwise you might get dependencies to the shared version, and there is nothing wrong about that. I admit that some functions might be added to shared version, which would be for pe-coff better be placed into the pure static part of libgcc. But well that is an enhancment issue and not a bug.
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #4 from Dongsheng Song 2013-04-30 10:44:03 UTC --- Created attachment 29980 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29980 gcc/config.log
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #5 from Dongsheng Song 2013-04-30 10:46:54 UTC --- (In reply to comment #2) > Hmm, I can't reproduce that. I just built things myself again for 4.8.1 gcc. > I am a bit curious to read that due distributions like Fedora seem to be able > to build stuff without isssues for 4.8.x gcc. > First advice would be to look into libstdc++'s config.log to see why for you > shared library isn't built. Second question is how you are actual configuring > it, and what additional patches you might use on built? No additional patches applied. Here is my build cfg: $ /home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure --prefix=/home/cauchy/cross/x86_64-windows --with-sysroot=/home/cauchy/cross/x86_64-windows --target=x86_64-w64-mingw32 --enable-targets=all --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=x86-64 --with-tune=generic --with-fpmath=sse Please see attachments for config.log
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Dongsheng Song changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | --- Comment #6 from Dongsheng Song 2013-04-30 10:47:39 UTC --- OOPS, not RESOLVED.
[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 Dongsheng Song changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #2 from Dongsheng Song 2013-04-30 10:52:52 UTC --- (In reply to comment #1) > No this change wasn't hastily nor wrong. Actual the change makes things > compliant to logic already used for cygwin for years. Additional it fixed a > quirk there was about eh-code sometimes not using shared version, if it actual > was necessary to. > The point is, if you want to avoid dependency to DLL libgcc version, then > please use support static option for it. Otherwise you might get dependencies > to the shared version, and there is nothing wrong about that. > > I admit that some functions might be added to shared version, which would be > for pe-coff better be placed into the pure static part of libgcc. But well > that is an enhancment issue and not a bug. It's a regress to gcc 4.7, it't it ?
[Bug middle-end/57107] [4.9 Regression] tree check fail in unlink_stmt_vdef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57107
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Richard Biener 2013-04-30
10:53:21 UTC ---
(gdb) call debug_gimple_stmt (stmt)
# .MEM_159(ab) = VDEF <.MEM>
D.63506 ={v} {CLOBBER};
SSA form is not up-to-date. It's a latent issue with sinking clobbers
during EH cleanup. We have
:
# .MEM_32(ab) = VDEF <.MEM_31(ab)>
D.2688 ={v} {CLOBBER};
resx 3
:
# .MEM_61 = VDEF <.MEM_32(ab)>
MEM[(struct new_allocator *)&D.2706] ={v} {CLOBBER};
# .MEM_62 = VDEF <.MEM_61>
D.2706 ={v} {CLOBBER};
# .MEM_34 = VDEF <.MEM_62>
D.2706 ={v} {CLOBBER};
resx 2
:
# .MEM_35 = VDEF <.MEM_34>
t ={v} {CLOBBER};
resx 1
and first sink D.2688 ={v} {CLOBBER}; into the successor (L7), dropping
virtual operands. Then we continue sinking but call unlink_stmt_vdef
on the moved stmt which no longer has up-to-date SSA form and thus
we ICE.
As we only sink across forwarder edges we can trivially keep the original
virtual operands in place.
I have a patch.
[Bug rtl-optimization/56957] [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957 Andrey Belevantsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Andrey Belevantsev 2013-04-30 10:58:02 UTC --- Fixed with: Author: abel Date: Tue Apr 30 10:55:52 2013 New Revision: 198449 URL: http://gcc.gnu.org/viewcvs?rev=198449&root=gcc&view=rev Log: PR rtl-optimization/56957 PR rtl-optimization/57105 * sel-sched.c (move_op_orig_expr_found): Remove insn_emitted variable. Use just INSN_UID for determining whether an insn should be only disconnected from the insn stream. * sel-sched-ir.h (EXPR_WAS_CHANGED): Remove. * gcc.dg/pr57105.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr57105.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.h trunk/gcc/sel-sched.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/57105] [4.9 Regression] ICE: in add_insn_before_nobb, at emit-rtl.c:3883 with -Os -fselective-scheduling2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57105 Andrey Belevantsev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Andrey Belevantsev 2013-04-30 10:58:27 UTC --- Fixed with: Author: abel Date: Tue Apr 30 10:55:52 2013 New Revision: 198449 URL: http://gcc.gnu.org/viewcvs?rev=198449&root=gcc&view=rev Log: PR rtl-optimization/56957 PR rtl-optimization/57105 * sel-sched.c (move_op_orig_expr_found): Remove insn_emitted variable. Use just INSN_UID for determining whether an insn should be only disconnected from the insn stream. * sel-sched-ir.h (EXPR_WAS_CHANGED): Remove. * gcc.dg/pr57105.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr57105.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.h trunk/gcc/sel-sched.c trunk/gcc/testsuite/ChangeLog
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-30 Ever Confirmed|0 |1 --- Comment #7 from Kai Tietz 2013-04-30 11:00:13 UTC --- Hmm, only issue I see is the use of '--disable-nls' option, which is known to cause issue. See here PR 54659. Another question I have is, what mingw-w64 header-set,crt you are using? You will need for >= 4.8.x gcc version actual trunk version. I looked through the config.log and don't see anything showing that shared-version doesn't work, so I assume the underlying issue you see is PR 54659.
[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Kai Tietz 2013-04-30 11:03:30 UTC --- Would you please stop to change status? As I said, change is intended, it is no regression, it is actual a fix. In maximum it is a difference in behavior.
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #8 from Dongsheng Song 2013-04-30 11:29:10 UTC --- (In reply to comment #7) > Hmm, only issue I see is the use of '--disable-nls' option, which is known to > cause issue. See here PR 54659. > > Another question I have is, what mingw-w64 header-set,crt you are using? You > will need for >= 4.8.x gcc version actual trunk version. > Yes, I use mingw-w64 trunk. > I looked through the config.log and don't see anything showing that > shared-version doesn't work, so I assume the underlying issue you see is PR > 54659. OK, I will try without '--disable-nls' option.
[Bug fortran/57095] [Fortran-Dev] FAIL: gfortran.dg/alloc_comp_assign_[234].f90 -O* execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57095 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dominique d'Humieres 2013-04-30 11:35:06 UTC --- Fixed by revision 198440. Marked as a duplicate of 57090. *** This bug has been marked as a duplicate of bug 57090 ***
[Bug fortran/57090] [Fortran-Dev] FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O* execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57090 --- Comment #2 from Dominique d'Humieres 2013-04-30 11:35:06 UTC --- *** Bug 57095 has been marked as a duplicate of this bug. ***
[Bug fortran/57090] [Fortran-Dev] FAIL: gfortran.dg/alloc_comp_bounds_1.f90 -O* execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57090 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Dominique d'Humieres 2013-04-30 11:36:33 UTC --- Fixed by revision 198440 Author:burnus Date:Tue Apr 30 08:02:15 2013 UTC (3 hours, 31 minutes ago) Changed paths:4 Log Message: 2013-04-30 Tobias Burnus * trans-array.c (gfc_trans_dummy_array_bias, get_std_lbound, gfc_alloc_allocatable_for_assignment): Change ubound to extent. * trans-expr.c (gfc_trans_alloc_subarray_assign): Ditto. * trans-intrinsic.c (gfc_conv_intrinsic_bound): Ditto. Changed paths PathDetails branches/fortran-dev/gcc/fortran/ChangeLog.fortran-devmodified , text changed branches/fortran-dev/gcc/fortran/trans-array.cmodified , text changed branches/fortran-dev/gcc/fortran/trans-expr.cmodified , text changed branches/fortran-dev/gcc/fortran/trans-intrinsic.cmodified , text changed Closing as fixed.
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #9 from Dongsheng Song 2013-04-30 11:41:29 UTC --- Created attachment 29981 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29981 gcc/config-v2.log
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #10 from Dongsheng Song 2013-04-30 11:42:27 UTC --- Created attachment 29982 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29982 i686-w64-mingw32/libstdc++-v3/config-v2.log
[Bug fortran/57094] [Fortran-Dev] ICE: in lhd_incomplete_type_error, at langhooks.c:203
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57094 --- Comment #1 from Dominique d'Humieres 2013-04-30 11:42:49 UTC --- Reduced test for gfortran.dg/transfer_intrinsic_3.f90 module m implicit none contains pure function str_vs(vs) result(s) character, dimension(:), intent(in) :: vs character(len=size(vs)) :: s s = transfer(vs, s) end function str_vs end module m use m implicit none character, dimension(:), pointer :: QName character :: tmp(6) integer :: n allocate(qname(6)) qname = (/ 'a','b','c','d','e','f' /) tmp = str_vs(qname(1:n-1)) print *, tmp end transfer_intrinsic_3_red.f90: In function 'MAIN__': transfer_intrinsic_3_red.f90:19:0: internal compiler error: in lhd_incomplete_type_error, at langhooks.c:203 tmp = str_vs(qname(1:n-1)) Note that the test compiles, but generates a wrong code, without the module: implicit none character, dimension(:), pointer :: QName character :: tmp(6) integer :: n allocate(qname(6)) qname = (/ 'a','b','c','d','e','f' /) tmp = str_vs(qname(1:n-1)) print *, tmp contains pure function str_vs(vs) result(s) character, dimension(:), intent(in) :: vs character(len=size(vs)) :: s s = transfer(vs, s) end function str_vs end
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #11 from Dongsheng Song 2013-04-30 11:43:42 UTC --- Please see gcc/config-v2.log and i686-w64-mingw32/libstdc++-v3/config-v2.log, still not build libstdc++-6.dll
[Bug driver/57123] New: code compiled and linked with -fopenmp does not load the correct omp library at run-time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57123 Bug #: 57123 Summary: code compiled and linked with -fopenmp does not load the correct omp library at run-time Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@leicester.ac.uk code compiled and linked with -fopenmp will, at run-time, load the first libgomp it finds in the LD_LIBRARY_PATH (on linux). However, this may not be the correct one, causing run-time failure. This problem manifests itself if, for example, using a more recent version of gcc (4.7.0) than the default OS version (4.3.4), when upon running I get mycmd: /usr/lib64/libgomp.so.1: version `OMP_3.0' not found (required by mylib.so) where mycmd was made using gcc 4.7.0 (at /somepath/gcc/4.7.0/bin/gcc) with option -fopenmp both at compiling and linking. This behaviour is at odds with the documentation, according to which -fopenmp arranges for the automatic linking of the [correct] OpenMP library. Note that I can "fix" the problem by adding the path of the correct library, /somepath/gcc/4.7.0/lib64, to the environment variable LD_LIBRARY_PATH. However, this fiddling with the operating system is not desirable and potentially dangerous, as it may break the operating system itself. Instead, the correct library path should be hard-wired into the executable upon making it, i.e. at linking the -fopenmp option should effectuate to (-Wl) -rpath=/somepath/gcc/4.7.0/lib64. Note also that adding the correct path to the LD_RUN_PATH environment variable at compiling and linking (and running) has not the desired effect.
[Bug tree-optimization/57122] [4.9 Regression] ICE in verify_loop_structure, at cfgloop.c:1647 (loop n’s latch does not have an edge to its header !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57122 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-30 CC||mpolacek at gcc dot gnu.org Known to work||4.8.1 Summary|ICE in |[4.9 Regression] ICE in |verify_loop_structure, at |verify_loop_structure, at |cfgloop.c:1647 (loop n’s|cfgloop.c:1647 (loop n’s |latch does not have an edge |latch does not have an edge |to its header !)|to its header !) Ever Confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Marek Polacek 2013-04-30 11:49:33 UTC --- Confirmed.
[Bug tree-optimization/57122] [4.9 Regression] ICE in verify_loop_structure, at cfgloop.c:1647 (loop n’s latch does not have an edge to its header !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57122 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener 2013-04-30 11:50:44 UTC --- Mine.
[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 --- Comment #4 from Dongsheng Song 2013-04-30 11:53:35 UTC --- libgcc_s_sjlj-1.dll export the following symbos: [Ordinal/Name Pointer] Table [ 0] _Unwind_Backtrace [ 1] _Unwind_DeleteException [ 2] _Unwind_FindEnclosingFunction [ 3] _Unwind_Find_FDE [ 4] _Unwind_GetCFA [ 5] _Unwind_GetDataRelBase [ 6] _Unwind_GetGR [ 7] _Unwind_GetIP [ 8] _Unwind_GetIPInfo [ 9] _Unwind_GetLanguageSpecificData [ 10] _Unwind_GetRegionStart [ 11] _Unwind_GetTextRelBase [ 12] _Unwind_SetGR [ 13] _Unwind_SetIP [ 14] _Unwind_SjLj_ForcedUnwind [ 15] _Unwind_SjLj_RaiseException [ 16] _Unwind_SjLj_Register [ 17] _Unwind_SjLj_Resume [ 18] _Unwind_SjLj_Resume_or_Rethrow [ 19] _Unwind_SjLj_Unregister [ 20] __absvdi2 [ 21] __absvsi2 [ 22] __addtf3 [ 23] __addvdi3 [ 24] __addvsi3 [ 25] __ashldi3 [ 26] __ashrdi3 [ 27] __bswapdi2 [ 28] __bswapsi2 [ 29] __clear_cache [ 30] __clrsbdi2 [ 31] __clrsbsi2 [ 32] __clzdi2 [ 33] __clzsi2 [ 34] __cmpdi2 [ 35] __ctzdi2 [ 36] __ctzsi2 [ 37] __deregister_frame [ 38] __deregister_frame_info [ 39] __deregister_frame_info_bases [ 40] __divdc3 [ 41] __divdi3 [ 42] __divsc3 [ 43] __divtc3 [ 44] __divtf3 [ 45] __divxc3 [ 46] __emutls_get_address [ 47] __emutls_register_common [ 48] __enable_execute_stack [ 49] __eqtf2 [ 50] __extenddftf2 [ 51] __extendsftf2 [ 52] __extendxftf2 [ 53] __ffsdi2 [ 54] __ffssi2 [ 55] __fixdfdi [ 56] __fixsfdi [ 57] __fixtfdi [ 58] __fixtfsi [ 59] __fixunsdfdi [ 60] __fixunsdfsi [ 61] __fixunssfdi [ 62] __fixunssfsi [ 63] __fixunstfdi [ 64] __fixunstfsi [ 65] __fixunsxfdi [ 66] __fixunsxfsi [ 67] __fixxfdi [ 68] __floatdidf [ 69] __floatdisf [ 70] __floatditf [ 71] __floatdixf [ 72] __floatsitf [ 73] __floatundidf [ 74] __floatundisf [ 75] __floatunditf [ 76] __floatundixf [ 77] __floatunsitf [ 78] __gcc_personality_sj0 [ 79] __getf2 [ 80] __gttf2 [ 81] __letf2 [ 82] __lshrdi3 [ 83] __lttf2 [ 84] __moddi3 [ 85] __muldc3 [ 86] __muldi3 [ 87] __mulsc3 [ 88] __multc3 [ 89] __multf3 [ 90] __mulvdi3 [ 91] __mulvsi3 [ 92] __mulxc3 [ 93] __negdi2 [ 94] __negtf2 [ 95] __negvdi2 [ 96] __negvsi2 [ 97] __netf2 [ 98] __paritydi2 [ 99] __paritysi2 [ 100] __popcountdi2 [ 101] __popcountsi2 [ 102] __powidf2 [ 103] __powisf2 [ 104] __powitf2 [ 105] __powixf2 [ 106] __register_frame [ 107] __register_frame_info [ 108] __register_frame_info_bases [ 109] __register_frame_info_table [ 110] __register_frame_info_table_bases [ 111] __register_frame_table [ 112] __subtf3 [ 113] __subvdi3 [ 114] __subvsi3 [ 115] __trunctfdf2 [ 116] __trunctfsf2 [ 117] __trunctfxf2 [ 118] __ucmpdi2 [ 119] __udivdi3 [ 120] __udivmoddi4 [ 121] __umoddi3 [ 122] __unordtf2 If I use unwind-sjlj.rc (unwind-seh.rc, or unwind-dw2.rc) to make sure libgcc_s_sjlj-1.dll only export _Unwind_* symbols, is it acceptable ?
[Bug fortran/56937] Unnecessarily temporary with array-vector assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56937 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #7 from Thomas Koenig 2013-04-30 11:58:43 UTC --- (In reply to comment #6) > Apparently there is no dependency analysis for array-vector assignments. Correct, however... > The > following test create a temporary that is not needed > > integer :: r(10), idx(4), jdx(4) > r = [(i+10,i=1,10)] > idx = [1, 2, 3, 4] > jdx = [6, 7, 8, 9] > r(idx) = r(jdx) > print *, r > end > > r(idx) = r(jdx) > 1 > Warning: Creating array temporary at (1) Currently, we do not support assigning values to variables and then later using the values for dependency analysis. This would require forward propagation of values, which we don't do in the front end. Plus, a lot of dependency test cases where we used variables to hide them from the optimization would start failing ;-)
[Bug tree-optimization/57122] [4.9 Regression] ICE in verify_loop_structure, at cfgloop.c:1647 (loop n’s latch does not have an edge to its header !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57122 --- Comment #3 from Marek Polacek 2013-04-30 12:05:15 UTC --- Started with http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=198333 aka loops preservation patch.
[Bug rtl-optimization/56732] ICE in advance_target_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56732
enrico.scholz at informatik dot tu-chemnitz.de changed:
What|Removed |Added
CC||enrico.scholz at informatik
||dot tu-chemnitz.de
--- Comment #5 from enrico.scholz at informatik dot tu-chemnitz.de 2013-04-30
12:07:46 UTC ---
I can reproduce this error message with gcc-4.8 (patched by OpenEmbedded) on an
ARM platform with a simple
extern void bar();
void __attribute__((__naked__)) foo(void)
{
bar();
}
$ arm-linux-gnueabi-gcc -O2 -c /tmp/xxx.c
/tmp/xxx.c: In function 'foo':
/tmp/xxx.c:5:1: internal compiler error: in advance_target_bb, at
sched-rgn.c:3552
[Bug driver/57123] code compiled and linked with -fopenmp does not load the correct omp library at run-time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57123 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek 2013-04-30 12:12:05 UTC --- That is a user error, gcc isn't supposed to handle this for you. If you have multiple versions of libgomp.so on your system, just use -Wl,-rpath,/some/path/ or LD_LIBRARY_PATH to point the program at the right version. Like glibc, libgomp is symbol versioned and backward compatible, keeping the same SONAME, so you really want the latest version of the library from all versions needed by programs that link against it.
[Bug fortran/57116] [OOP] ICE for pointer assignment inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57116 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|CLASS(*) - ICE for pointer |[OOP] ICE for pointer |assignment inside SELECT|assignment inside SELECT |TYPE on UP entity |TYPE --- Comment #2 from janus at gcc dot gnu.org 2013-04-30 12:13:49 UTC --- Reduced test case for the ICE, which shows that unlimited polymorphism is not required to trigger the bug: implicit none type :: foo real :: v end type contains subroutine extract(this, v) class(foo), target :: this(:) real, pointer :: v(:) select type (this) class is (foo) v => this(1:2)%v end select end subroutine end
[Bug fortran/56937] Unnecessarily temporary with array-vector assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56937 --- Comment #8 from Dominique d'Humieres 2013-04-30 12:15:00 UTC --- > Currently, we do not support assigning values to variables > and then later using the values for dependency analysis. > ... What about integer :: r(10) r = [(i+10,i=1,10)] r([1, 2, 3, 4]) = r([6, 7, 8, 9]) print *, r end r([1, 2, 3, 4]) = r([6, 7, 8, 9]) 1 Warning: Creating array temporary at (1)
[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57117 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|CLASS(*): ICE for sourced |[OOP] ICE for sourced |allocation of a UP entity |allocation of a polymorphic |that uses the transpose |entity using TRANSPOSE |intrinsic | --- Comment #2 from janus at gcc dot gnu.org 2013-04-30 12:22:40 UTC --- Also this one can be triggered without UP: implicit none type :: ti end type class(ti), allocatable :: x(:,:), y(:,:) allocate(y(3,3), source=transpose(x)) end
[Bug tree-optimization/57124] New: 254.gap@spec2000 got miscompare after r198413
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124 Bug #: 57124 Summary: 254.gap@spec2000 got miscompare after r198413 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: izamya...@gmail.com Happens for example for option set "-O2 -ffast-math -march=corei7". Unfortunately, now have no possibility to make some reproducer
[Bug libstdc++/50160] vector comparison very slow (no overload)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160 brett davis changed: What|Removed |Added CC||dparker1324 at gmail dot ||com --- Comment #36 from brett davis 2013-04-30 12:30:06 UTC --- Now that was an amazing post about the comparison of vector and their additional features. It is a really useful post that helps to simplify the issues and also helps to clarify the doubts regarding vectors and bool. Awaiting new posts.http://www.outlookemailsetup.com/outlook-express-help/how-to-merge-your-email-account-with-outlook-express/";>outlookemailsetup.com
[Bug bootstrap/57125] New: Build not SMP safe; fails to build bconfig.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57125 Bug #: 57125 Summary: Build not SMP safe; fails to build bconfig.h Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: enrico.sch...@informatik.tu-chemnitz.de Created attachment 29983 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29983 Full build log When building gcc-4.8 (patched by OpenEmbedded) with '-j 8', the build fails from time to time because bconfig.h can not be found. A subsequent make succeeds in these cases.
[Bug fortran/56937] Unnecessarily temporary with array-vector assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56937 --- Comment #9 from Tobias Burnus 2013-04-30 12:35:49 UTC --- (In reply to comment #8) > > Currently, we do not support assigning values to variables > > and then later using the values for dependency analysis. > > ... Well, as I wrote in comment 0: For assignments of the form array(vec_idx) = array(vec_idx) + nonaliasing_expr no temporary should be generated. Namely: Both sides have the same vector_idx expression. The test case in comment 0 is based on a real world test case which exactly uses one array variable as index. I think one could walk the an array constructor, but my feeling is that a constructor is not the most common usage case in a real-world code. Thus, that has lower priority.
[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 --- Comment #5 from Kai Tietz 2013-04-30 13:34:25 UTC --- (In reply to comment #4) > libgcc_s_sjlj-1.dll export the following symbos: > > [Ordinal/Name Pointer] Table > [ 0] _Unwind_Backtrace > [ 1] _Unwind_DeleteException > [ 2] _Unwind_FindEnclosingFunction > [ 3] _Unwind_Find_FDE > [ 4] _Unwind_GetCFA > [ 5] _Unwind_GetDataRelBase > [ 6] _Unwind_GetGR > [ 7] _Unwind_GetIP > [ 8] _Unwind_GetIPInfo > [ 9] _Unwind_GetLanguageSpecificData > [ 10] _Unwind_GetRegionStart > [ 11] _Unwind_GetTextRelBase > [ 12] _Unwind_SetGR > [ 13] _Unwind_SetIP > [ 14] _Unwind_SjLj_ForcedUnwind > [ 15] _Unwind_SjLj_RaiseException > [ 16] _Unwind_SjLj_Register > [ 17] _Unwind_SjLj_Resume > [ 18] _Unwind_SjLj_Resume_or_Rethrow > [ 19] _Unwind_SjLj_Unregister > [ 20] __absvdi2 > [ 21] __absvsi2 > [ 22] __addtf3 > [ 23] __addvdi3 > [ 24] __addvsi3 > [ 25] __ashldi3 > [ 26] __ashrdi3 > [ 27] __bswapdi2 > [ 28] __bswapsi2 > [ 29] __clear_cache > [ 30] __clrsbdi2 > [ 31] __clrsbsi2 > [ 32] __clzdi2 > [ 33] __clzsi2 > [ 34] __cmpdi2 > [ 35] __ctzdi2 > [ 36] __ctzsi2 > [ 37] __deregister_frame > [ 38] __deregister_frame_info > [ 39] __deregister_frame_info_bases > [ 40] __divdc3 > [ 41] __divdi3 > [ 42] __divsc3 > [ 43] __divtc3 > [ 44] __divtf3 > [ 45] __divxc3 > [ 46] __emutls_get_address > [ 47] __emutls_register_common > [ 48] __enable_execute_stack > [ 49] __eqtf2 > [ 50] __extenddftf2 > [ 51] __extendsftf2 > [ 52] __extendxftf2 > [ 53] __ffsdi2 > [ 54] __ffssi2 > [ 55] __fixdfdi > [ 56] __fixsfdi > [ 57] __fixtfdi > [ 58] __fixtfsi > [ 59] __fixunsdfdi > [ 60] __fixunsdfsi > [ 61] __fixunssfdi > [ 62] __fixunssfsi > [ 63] __fixunstfdi > [ 64] __fixunstfsi > [ 65] __fixunsxfdi > [ 66] __fixunsxfsi > [ 67] __fixxfdi > [ 68] __floatdidf > [ 69] __floatdisf > [ 70] __floatditf > [ 71] __floatdixf > [ 72] __floatsitf > [ 73] __floatundidf > [ 74] __floatundisf > [ 75] __floatunditf > [ 76] __floatundixf > [ 77] __floatunsitf > [ 78] __gcc_personality_sj0 > [ 79] __getf2 > [ 80] __gttf2 > [ 81] __letf2 > [ 82] __lshrdi3 > [ 83] __lttf2 > [ 84] __moddi3 > [ 85] __muldc3 > [ 86] __muldi3 > [ 87] __mulsc3 > [ 88] __multc3 > [ 89] __multf3 > [ 90] __mulvdi3 > [ 91] __mulvsi3 > [ 92] __mulxc3 > [ 93] __negdi2 > [ 94] __negtf2 > [ 95] __negvdi2 > [ 96] __negvsi2 > [ 97] __netf2 > [ 98] __paritydi2 > [ 99] __paritysi2 > [ 100] __popcountdi2 > [ 101] __popcountsi2 > [ 102] __powidf2 > [ 103] __powisf2 > [ 104] __powitf2 > [ 105] __powixf2 > [ 106] __register_frame > [ 107] __register_frame_info > [ 108] __register_frame_info_bases > [ 109] __register_frame_info_table > [ 110] __register_frame_info_table_bases > [ 111] __register_frame_table > [ 112] __subtf3 > [ 113] __subvdi3 > [ 114] __subvsi3 > [ 115] __trunctfdf2 > [ 116] __trunctfsf2 > [ 117] __trunctfxf2 > [ 118] __ucmpdi2 > [ 119] __udivdi3 > [ 120] __udivmoddi4 > [ 121] __umoddi3 > [ 122] __unordtf2 > > If I use unwind-sjlj.rc (unwind-seh.rc, or unwind-dw2.rc) to make sure > libgcc_s_sjlj-1.dll only export _Unwind_* symbols, is it acceptable ? No, actual all functions about Unwind, emutls, and register (deregister) have to be part of the DLL. The math-functions here might be candidates for the pure static-version only.
[Bug fortran/57094] [Fortran-Dev] ICE: in lhd_incomplete_type_error, at langhooks.c:203
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57094 --- Comment #2 from Dominique d'Humieres 2013-04-30 13:40:27 UTC --- Reduced test for gfortran.dg/proc_decl_23.f90 module m_string type t_string procedure(string_to_char), pointer, nopass :: char3 ! segfault end type t_string contains function string_to_char (s) result(res) character, dimension(:), intent(in) :: s character(len=size(s)) :: res do i = 1, size(s) res(i:i) = s(i) end do end function string_to_char end module m_string use m_string type(t_string) :: t print *, string_to_char (["a","b","c"]) end If 'print *, string_to_char (["a","b","c"])' is commented in the original test, it compiles and passes. I also confirm that if the "contains ..." is moved from the module to the program, the tests compile and run without error for gfortran.dg/auto_char_len_3.f90 andproc_decl_23.f90.
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #12 from Kai Tietz 2013-04-30 13:49:25 UTC --- Hmm, I don't see in config.log any difference to the variant I have built on my box. Shared is actual enabled in you config.log for libstdc++-v3. So DLL should be built, if you don't have a build error. For me 32-bit and 64-bit w64 version builds OOTB without any issue. You are building multilib as I see, so do you have 32-bit and 64-bit setuped too? Could you check if there is for real no dll built by executing within your libstdc++-v3 build-directory the command 'find ./* -name "*.dll" -print'?
[Bug middle-end/57107] [4.9 Regression] tree check fail in unlink_stmt_vdef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57107 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Biener 2013-04-30 13:54:32 UTC --- Author: rguenth Date: Tue Apr 30 13:54:14 2013 New Revision: 198454 URL: http://gcc.gnu.org/viewcvs?rev=198454&root=gcc&view=rev Log: 2013-04-30 Richard Biener PR middle-end/57107 * tree-eh.c (sink_clobbers): Preserve virtual SSA form. * g++.dg/torture/pr57107.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr57107.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-eh.c
[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #13 from Dongsheng Song 2013-04-30 14:46:43 UTC --- (In reply to comment #12) > Hmm, I don't see in config.log any difference to the variant I have built on > my > box. Shared is actual enabled in you config.log for libstdc++-v3. So DLL > should be built, if you don't have a build error. > For me 32-bit and 64-bit w64 version builds OOTB without any issue. > You are building multilib as I see, so do you have 32-bit and 64-bit setuped > too? Could you check if there is for real no dll built by executing within > your libstdc++-v3 build-directory the command 'find ./* -name "*.dll" -print'? Yes, I build x86_64-w64-mingw32 with multilib, i686-w64-mingw32 without multilib (due to binutils trunk regress), both do not generate libstdc++-6.dll: ~/obj/i686-w64-mingw32/gcc$ find ./* -name "*.dll" -print ./gcc/home/cauchy/cross/i686-windows/i686-w64-mingw32/lib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/libgcc/shlib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/libssp/.libs/libssp-0.dll ./i686-w64-mingw32/libquadmath/.libs/libquadmath-0.dll ./i686-w64-mingw32/libgfortran/.libs/libgfortran-3.dll ~/obj/x86_64-w64-mingw32/gcc$ find ./* -name "*.dll" -print ./gcc/home/cauchy/cross/x86_64-windows/x86_64-w64-mingw32/lib/libgcc_s_seh-1.dll ./gcc/home/cauchy/cross/x86_64-windows/x86_64-w64-mingw32/lib32/libgcc_s_sjlj-1.dll ./x86_64-w64-mingw32/libgcc/shlib/libgcc_s_seh-1.dll ./x86_64-w64-mingw32/32/libgcc/32/shlib/libgcc_s_sjlj-1.dll ./x86_64-w64-mingw32/32/libssp/.libs/libssp-0.dll ./x86_64-w64-mingw32/32/libquadmath/.libs/libquadmath-0.dll ./x86_64-w64-mingw32/32/libgfortran/.libs/libgfortran-3.dll ./x86_64-w64-mingw32/libssp/.libs/libssp-0.dll ./x86_64-w64-mingw32/libquadmath/.libs/libquadmath-0.dll ./x86_64-w64-mingw32/libgfortran/.libs/libgfortran-3.dll
[Bug tree-optimization/57122] [4.9 Regression] ICE in verify_loop_structure, at cfgloop.c:1647 (loop n’s latch does not have an edge to its header !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57122 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Biener 2013-04-30 15:04:20 UTC --- Author: rguenth Date: Tue Apr 30 15:03:58 2013 New Revision: 198456 URL: http://gcc.gnu.org/viewcvs?rev=198456&root=gcc&view=rev Log: 2013-04-30 Richard Biener PR middle-end/57122 * cfghooks.c (split_edge): Properly check for the loop latch edge. * gcc.dg/torture/pr57122.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57122.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfghooks.c trunk/gcc/testsuite/ChangeLog
[Bug target/57091] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -mcmodel=large and indirect call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57091 Uros Bizjak changed: What|Removed |Added Keywords||ra Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-30 CC||vmakarov at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak 2013-04-30 15:11:38 UTC --- Confirmed, adding CC.
[Bug rtl-optimization/57106] [4.8/4.9 Regression] -fcompare-debug failure with -O2 -fschedule-insns -funroll-all-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57106 Uros Bizjak changed: What|Removed |Added Keywords|ice-on-valid-code | Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-30 Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak 2013-04-30 15:16:35 UTC --- Confirmed.
[Bug tree-optimization/57124] 254.gap@spec2000 got miscompare after r198413
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-30 Ever Confirmed|0 |1
[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-30 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2013-04-30 16:07:21 UTC --- Can you show the full link line? I think -lgcov is before any object files which is the problem.
[Bug fortran/57126] New: Wrongly rejects a generic call because it doesn't match the intrinsic while another specific matches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57126 Bug #: 57126 Summary: Wrongly rejects a generic call because it doesn't match the intrinsic while another specific matches Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Created attachment 29984 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29984 Test case Reported by Roger Ferrer Ibáñez at https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/y31DDXAXNAE The attached test case is accepted by NAG f95 (5.1) and by IBM XLF (12.1). But gfortran rejects it with: Y = RENAME(M=Y) 1 Error: Generic function 'size' at (1) is not consistent with a specific intrinsic interface X = RENAME(A=X) 1 Error: Generic function 'size' at (1) is not consistent with a specific intrinsic interface (Intel ifort 13.1.0 only rejects "X = RENAME(A=X)".)
[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57117 --- Comment #3 from Dominique d'Humieres 2013-04-30 16:39:38 UTC --- Reduced test for RESHAPE: implicit none type :: ti end type class(ti), allocatable :: x(:,:), z(:) allocate(z(9), source=reshape(x, (/ 9 /))) end pr57117_2.f90:8:0: internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:4902 allocate(z(9), source=reshape(x, (/ 9 /)))
[Bug fortran/57126] Matching host-associated generic vs. same-named use-associated generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57126 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Summary|Wrongly rejects a generic |Matching host-associated |call because it doesn't |generic vs. same-named |match the intrinsic while |use-associated generic |another specific matches| --- Comment #1 from Tobias Burnus 2013-04-30 16:44:36 UTC --- For clarification: - ABS and SIZE are both generic names, either having an intrinsic and a user specific procedure. - In "sub", the specific functions of "SIZE" do not match the rejected calls. - The specific functions of "ABS" do match - and both have the same generic name See: USE MOO, ONLY: RENAME => ABS CONTAINS SUBROUTINE SUB USE MOO, ONLY: RENAME => SIZE, T Thus, the question is whether the generic "rename" are merged or whether the inner "rename" overrides the host-associated "rename". If they are merged, the question is how ambiguity is handled.
[Bug fortran/57126] Matching host-associated generic vs. same-named use-associated generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57126 --- Comment #2 from Tobias Burnus 2013-04-30 16:51:05 UTC --- Fortran 2008, "16.5.1.4 Host association" has: "If an entity that is accessed by use association has the same nongeneric name as a host entity, the host entity is inaccessible by that name." Thus, the generic name has to be pulled be merged - and also be honoured for ambiguity resolution.
[Bug fortran/57127] New: gfortran gives unintended warning on uninitialized optional dummy array of undetermined size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57127 Bug #: 57127 Summary: gfortran gives unintended warning on uninitialized optional dummy array of undetermined size Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: astrofl...@gmail.com Created attachment 29985 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29985 Source file example.f90 used in the example in the bug report gfortran-4.7.2 -O1 -Wall gives unintended warning about uninitialized array elements when a routine is called with an optional dummy array of undetermined size (example.f90 is attached below): $ gfortran -O1 -Wall example.f90 -o example && ./example example.f90: In function ‘example_routine’: example.f90:8:0: warning: ‘array.0’ may be used uninitialized in this function [-Wmaybe-uninitialized] Expected behaviour: no warning message. The warning goes away when: * -O0 is used rather than -O1 or higher * -Wall is replaced by -Wmaybe-uninitialized * the line write(op,'(A)') 'foo' is commented out
[Bug fortran/57127] gfortran gives unintended warning on uninitialized optional dummy array of undetermined size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57127 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-30 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2013-04-30 17:51:49 UTC --- The warning is present for 4.6, 4.7, 4.8, and trunk.
[Bug c++/57111] Core dump - invalid pointer detected after std::unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 --- Comment #4 from Marc Glisse 2013-04-30 18:37:41 UTC --- gcc has -Wfree-nonheap-object, which works for free but not for delete or delete[]. Extending it to these functions seems like a reasonable RFE.
[Bug tree-optimization/57124] 254.gap@spec2000 got miscompare after r198413
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124 --- Comment #1 from Jeffrey A. Law 2013-04-30 19:20:19 UTC --- It looks like range_fits_type_p may not be handling overflows correctly. Investigating.
[Bug ada/57128] New: gcc-gnat problem halts gcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57128 Bug #: 57128 Summary: gcc-gnat problem halts gcc build Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@worldlinc.net Attempted build: GCC-4.6.4 with all components System: i686-pc-linux-gnu Additional system info: gcc-4.4.7, g++-4.4.7, binutils 2.19.5-something, glibc-2.10.1, no gcc-java installed as it's been buggy. But if it's required to build gcc-gnat, the configure script should have tested for it or compiled a new gcc-java before any ada files. Options for configure: /usr/local/gcc-4.6.4/configure --prefix=/usr --enable-build-with-cxx --enable-languages=ada,c,c++,fortran,go,java,lto,objc Commandline that triggered the bug (it's big): gcc -static-libgcc -o gnat1 ada/b_gnat1.o ada/adadecode.o ada/adaint.o ada/cstreams.o ada/cio.o ada/targtyps.o ada/decl.o ada/misc.o ada/utils.o ada/utils2.o ada/trans.o ada/cuintp.o ada/argv.o ada/raise.o ada/init.o ada/tracebak.o ada/initialize.o ada/env.o ada/a-charac.o ada/a-chlat1.o ada/a-elchha.o ada/a-except.o ada/a-ioexce.o ada/ada.o ada/ali.o ada/alloc.o ada/aspects.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o ada/elists.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/eval_fat.o ada/exp_aggr.o ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o ada/exp_ch11.o ada/exp_ch12.o ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o ada/exp_ch5.o ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o ada/exp_code.o ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o ada/exp_imgv.o ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o ada/exp_smem.o ada/exp_strm.o ada/exp_tss.o ada/exp_util.o ada/exp_vfpt.o ada/expander.o ada/fmap.o ada/fname-uf.o ada/fname.o ada/freeze.o ada/frontend.o ada/g-byorma.o ada/g-hesora.o ada/g-htable.o ada/g-spchge.o ada/g-speche.o ada/g-u3spch.o ada/get_scos.o ada/get_targ.o ada/gnat.o ada/gnatvsn.o ada/hlo.o ada/hostparm.o ada/impunit.o ada/inline.o ada/interfac.o ada/itypes.o ada/krunch.o ada/layout.o ada/lib-load.o ada/lib-util.o ada/lib-writ.o ada/lib-xref.o ada/lib.o ada/live.o ada/namet-sp.o ada/namet.o ada/nlists.o ada/nmake.o ada/opt.o ada/osint-c.o ada/osint.o ada/output.o ada/par.o ada/par_sco.o ada/prep.o ada/prepcomp.o ada/put_scos.o ada/repinfo.o ada/restrict.o ada/rident.o ada/rtsfind.o ada/s-addope.o ada/s-assert.o ada/s-bitops.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o ada/s-conca3.o ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o ada/s-conca8.o ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o ada/s-mastop.o ada/s-memory.o ada/s-os_lib.o ada/s-parame.o ada/s-purexc.o ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o ada/s-strcom.o ada/s-strhas.o ada/s-string.o ada/s-strops.o ada/s-traceb.o ada/s-traent.o ada/s-unstyp.o ada/s-utf_32.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scans.o ada/scil_ll.o ada/scn.o ada/scng.o ada/scos.o ada/sdefault.o ada/seh_init.o ada/sem.o ada/sem_aggr.o ada/sem_attr.o ada/sem_aux.o ada/sem_case.o ada/sem_cat.o ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o ada/sem_ch13.o ada/sem_ch2.o ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o ada/sem_ch6.o ada/sem_ch7.o ada/sem_ch8.o ada/sem_ch9.o ada/sem_disp.o ada/sem_dist.o ada/sem_elab.o ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o ada/sem_mech.o ada/sem_prag.o ada/sem_res.o ada/sem_scil.o ada/sem_smem.o ada/sem_type.o ada/sem_util.o ada/sem_vfpt.o ada/sem_warn.o ada/sinfo-cn.o ada/sinfo.o ada/sinput-d.o ada/sinput-l.o ada/sinput.o ada/snames.o ada/sprint.o ada/stand.o ada/stringt.o ada/style.o ada/styleg.o ada/stylesw.o ada/switch-c.o ada/switch.o ada/system.o ada/table.o ada/targext.o ada/targparm.o ada/tbuild.o ada/tree_gen.o ada/tree_in.o ada/tree_io.o ada/treepr.o ada/treeprs.o ada/ttypes.o ada/types.o ada/uintp.o ada/uname.o ada/urealp.o ada/usage.o ada/validsw.o ada/widechar.o ada/back_end.o ada/gnat1drv.o prefix.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a attribs.o ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lpwl -lgmpxx -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz -g The compiler output (head and tail, total=21 full console pages: ada/b_gnat1.o: In function `adafinal()': /home/dilbert/bld464/gcc/ada/b_gnat1.c:97: undefined reference to `system__standard_library__adafinal()' ada/b_gnat1.o: In function `adainit()': /home/dilbert/bld464/gcc/ada/b_gnat1.c:302: undefined reference to `system__soft_links___elabb()' /home/dil
[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-30 CC||dje at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from David Edelsohn 2013-04-30 20:45:54 UTC --- Confirmed.
[Bug fortran/57127] gfortran gives unintended warning on uninitialized optional dummy array of undetermined size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57127 --- Comment #2 from AstroFloyd 2013-04-30 20:57:55 UTC --- Hmmm, this looks very strongly like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370 but is not identical(?)
[Bug fortran/57096] Allocatable variable is not behaved as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096 --- Comment #4 from janus at gcc dot gnu.org 2013-04-30 21:10:51 UTC --- (In reply to comment #3) > Removing the -std=f2003 or putting the module into the same file as the > subroutine makes the auto-deallocation (and nullification) go away. Puzzling. I think the reason why it works with -std=f2008 is that module variables implicitly get the SAVE attribute in F08.
[Bug ada/57128] gcc-gnat problem halts gcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57128 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||INVALID --- Comment #1 from Eric Botcazou 2013-04-30 21:14:48 UTC --- Do not configure with --enable-build-with-cxx.
[Bug rtl-optimization/57106] [4.8/4.9 Regression] -fcompare-debug failure with -O2 -fschedule-insns -funroll-all-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57106 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2013-04-30 21:25:07 UTC --- Started with http://gcc.gnu.org/r196118 , but that just likely made some latent scheduler bug no longer latent.
[Bug fortran/57094] [Fortran-Dev] ICE: in lhd_incomplete_type_error, at langhooks.c:203
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57094 --- Comment #3 from Tobias Burnus 2013-04-30 21:44:37 UTC --- I thought the following would work. While it does so for the test cases, it causes new failures. In principle, not elem_len but "dim[0].sm" is the correct value - assuming, it is set. --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans-array.c @@ -424,3 +424,2 @@ gfc_conv_descriptor_stride_get (tree desc, tree dim) - tmp = gfc_get_element_type (type); - size = size_in_bytes (tmp); - size = fold_convert (gfc_array_index_type, size); + size = fold_convert (gfc_array_index_type, + gfc_conv_descriptor_elem_len_get (desc)); @@ -442,2 +441,2 @@ gfc_conv_descriptor_stride_set (stmtblock_t *block, tree desc, - tmp = gfc_get_element_type (TREE_TYPE (desc)); - tmp = size_in_bytes (tmp); + tmp = fold_convert (gfc_array_index_type, + gfc_conv_descriptor_elem_len_get (desc));
[Bug fortran/57071] Optimize (-1)**k to 1 - 2 * mod(K, 2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57071 --- Comment #10 from Thomas Koenig 2013-04-30 21:46:11 UTC --- Author: tkoenig Date: Tue Apr 30 21:45:13 2013 New Revision: 198476 URL: http://gcc.gnu.org/viewcvs?rev=198476&root=gcc&view=rev Log: 2013-04-30 Thomas Koenig PR fortran/57071 * frontend-passes.c (optimize_power): Simplify 1**k to 1. 2013-04-30 Thomas Koenig PR fortran/57071 * gfortran.dg/power_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/power_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/34004] Accepts invalid: Ambigiuous interface with subroutine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34004 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||FIXED --- Comment #10 from Thomas Koenig 2013-04-30 21:48:03 UTC --- Fixed. closing.
[Bug fortran/34004] Accepts invalid: Ambigiuous interface with subroutine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34004 Thomas Koenig changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED | --- Comment #11 from Thomas Koenig 2013-04-30 21:48:28 UTC --- Oopw, wrong PR.
[Bug fortran/57071] Optimize (-1)**k to 1 - 2 * mod(K, 2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57071 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Thomas Koenig 2013-04-30 21:49:14 UTC --- Fixed, closing; this time the right PR.
[Bug fortran/57129] New: ICE (segfault) in check_extended_derived_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129 Bug #: 57129 Summary: ICE (segfault) in check_extended_derived_type Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following invalid code causes a segfault in check_extended_derived_type subroutine t() type t end type t type, extends(t) :: t2 end type t2 end It first correctly diagnoses: type t 1 Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 't' at (1)
[Bug c++/57111] Core dump - invalid pointer detected after std::unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111
--- Comment #5 from jb 2013-04-30 21:57:00 UTC
---
(In reply to comment #4)
> gcc has -Wfree-nonheap-object, which works for free but not for delete or
> delete[]. Extending it to these functions seems like a reasonable RFE.
I agree with your suggestion.
gcc(1)
-Wno-free-nonheap-object
Do not warn when attempting to free an object that was not
allocated on the heap.
The above is a non-default option.
$ cat free-test.c
#include
int main () {
int arr[] = {1,2};
int * p = arr;
free(p);
return 0;
}
$ gcc -Wall -o free-test free-test.c
$ ./free-test
Segmentation fault (core dumped)
$ gcc -Wall -Wfree-nonheap-object -o free-test free-test.c
$ ./free-test
Segmentation fault (core dumped)
$ gcc -Wall -Wno-free-nonheap-object -o free-test free-test.c
$ ./free-test
Segmentation fault (core dumped)
$
It seems to me that the option "free-nonheap-object" does not work in gcc.
[Bug fortran/56800] [fortran-dev Regression] move_alloc_13.f90 failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56800 --- Comment #5 from Tobias Burnus 2013-04-30 21:57:28 UTC --- For the test case in comment 0: __builtin_memset (y._data.base_addr, 0, 4); y._data.rank = 1; y._data.type = -1; y._data.dim[0].lower_bound = 1; y._data.dim[0].extent = 2 - y._data.dim[0].lower_bound; y._data.dim[0].sm = (integer(kind=8)) y._data.elem_len; Here a line like: y._data.elem_len = 4; is missing. elem_len needs always to be updated for BT_CLASS.
[Bug c++/57111] Core dump - invalid pointer detected after std::unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 --- Comment #6 from Marc Glisse 2013-04-30 22:07:02 UTC --- (In reply to comment #5) > It seems to me that the option "free-nonheap-object" does not work in gcc. You need to add -O2 (maybe -O1 is enough, sometimes you need -O3), otherwise gcc does not propagate the information of what p is all the way to free.
[Bug c++/57111] Core dump - invalid pointer detected after std::unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 --- Comment #7 from jb 2013-04-30 22:22:44 UTC --- (In reply to comment #6) > (In reply to comment #5) > > It seems to me that the option "free-nonheap-object" does not work in gcc. > > You need to add -O2 (maybe -O1 is enough, sometimes you need -O3), otherwise > gcc does not propagate the information of what p is all the way to free. OK, that worked. $ gcc -O1 -Wall -o free-test free-test.c free-test.c: In function ‘main’: free-test.c:6:7: warning: attempt to free a non-heap object ‘arr’ [-Wfree-nonheap-object]
[Bug c++/57111] Core dump - invalid pointer detected after std::unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 jb changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #8 from jb 2013-04-30 22:50:12 UTC --- Please reopen this bug report. The RFE will make this feature consistent across gcc and g++.
[Bug c++/57111] Generalize -Wfree-nonheap-object to delete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 Marc Glisse changed: What|Removed |Added Keywords||diagnostic Status|VERIFIED|UNCONFIRMED Resolution|INVALID | Summary|Core dump - invalid pointer |Generalize |detected after |-Wfree-nonheap-object to |std::unique_ptr |delete Severity|normal |enhancement --- Comment #9 from Marc Glisse 2013-04-30 22:58:53 UTC --- "verified" isn't the right status, you are hoping for someone to set it to NEW, and leaving it at unconfirmed is the way to say that.
[Bug c++/57111] Generalize -Wfree-nonheap-object to delete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-30 Ever Confirmed|0 |1 --- Comment #10 from Jonathan Wakely 2013-04-30 23:01:11 UTC --- OK, confirmed as a diagnostic enhancement
[Bug rtl-optimization/57130] New: Incorrect "and --> extract" conversion in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57130
Bug #: 57130
Summary: Incorrect "and --> extract" conversion in combine
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w...@google.com
Created attachment 29986
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29986
Testcase
For the smallcase 1.ii attached.
~/workarea/gcc-r198433/build/install/bin/g++ 1.ii -o a1.out
./a1.out --> correct output:
1
3
~/workarea/gcc-r198433/build/install/bin/g++ -fno-inline
-fno-omit-frame-pointer -O2 1.ii -o a2.out
./a2.out --> incorrect output:
1
-1
In 1.ii.196r.ud_dce:
(insn 7 2 84 2 (set (reg:DI 64)
(const_int -4294967296 [0x])) 1.ii:26 84
{*movdi_internal}
(nil))
...
(insn 40 36 44 2 (parallel [
(set (reg:DI 88)
(and:DI (reg:DI 80)
(reg:DI 64)))
(clobber (reg:CC 17 flags))
]) 1.ii:32 386 {*anddi_1}
(expr_list:REG_DEAD (reg:DI 80)
(expr_list:REG_DEAD (reg:DI 64)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (and:DI (reg:DI 80)
(const_int -4294967296 [0x]))
(nil))
(insn 44 40 45 2 (set (reg:DI 92 [ mini_rect ])
(zero_extend:DI (subreg:SI (reg:DI 88) 0))) 1.ii:33 127
{*zero_extendsidi2}
(expr_list:REG_DEAD (reg:DI 88)
(nil)))
The value of r92 here should always be 0.
After try_combine with params (i3==insn44, i2==insn40, i1==insn7), insn44 is
transformed to:
(insn 44 40 45 2 (parallel [
(set (reg:DI 92 [ mini_rect ])
(ashiftrt:DI (reg:DI 88)
(const_int 63 [0x3f])))
(clobber (reg:CC 17 flags))
]) 1.ii:33 528 {ashrdi3_cvt}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:DI 88)
(nil
The value of r92 now equals either 0 or -1 which depends on the highest bit of
r88.
Try to understand what happen in try_combine:
In try_combine, after subst(PATTERN (i3), i2dest, i2src, ...), insn 44 is
transformed to the following form. This step is correct.
(insn 44 40 45 2 (set (reg:DI 92 [ mini_rect ])
(neg:DI (ne:DI (subreg:SI (and:DI (reg:DI 80)
(reg:DI 64)) 0)
(const_int 0 [0] 1.ii:33 127 {*zero_extendsidi2}
(expr_list:REG_DEAD (reg:DI 88)
(nil)))
In subst(PATTERN (i3), i1dest, i1src, ...), insn 44 is firstly transformed to
the following in simplify_logical, which is correct:
(insn 44 40 45 2 (set (reg:DI 92 [ mini_rect ])
(neg:DI (ne:DI (subreg:SI ((and:DI (reg:DI 80)
(const_int 34359738368 [0x8]))) 0)
(const_int 0 [0] 1.ii:33 127 {*zero_extendsidi2}
(expr_list:REG_DEAD (reg:DI 88)
(nil)))
then it is transformed to the following in make_compound_operation, which is
incorrect:
(insn 44 40 45 2 (set (reg:DI 92 [ mini_rect ])
(sign_extract:DI (reg:DI 80)
(const_int 1 [0x1])
(const_int 35 [0x23]))) 1.ii:33 127 {*zero_extendsidi2}
(expr_list:REG_DEAD (reg:DI 88)
(nil)))
make_compound_operation transforms
(and:DI (reg:DI 80)
(const_int 34359738368 [0x8]))
to
(zero_extract:DI (reg:DI 80)
(const_int 1 [0x1])
(const_int 35 [0x23]))
because it thinks the "and expr" here is in a compare. But actually the "and
expr" is firstly the kid in a subreg:
subreg:SI ((and:DI (reg:DI 80)
(const_int 34359738368 [0x8])) ==> always 0
is not identical with
subreg:SI ((zero_extract:DI (reg:DI 80)
(const_int 1 [0x1])
(const_int 35 [0x23])) ==> 0 or 1
So it is the cause of the problem. The second actual of make_compound_operation
(combine.c:7701, r198433) should not be in_code.
[Bug tree-optimization/57124] 254.gap@spec2000 got miscompare after r198413
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
--- Comment #2 from Jeffrey A. Law 2013-05-01 05:13:38
UTC ---
__attribute__ ((noinline))
foo(short unsigned int *p1, short unsigned int *p2)
{
short unsigned int x1, x4;
int x2, x3, x5, x6;
unsigned int x7;
x1 = *p1;
x2 = (int) x1;
x3 = x2 * 65536;
x4 = *p2;
x5 = (int) x4;
x6 = x3 + x4;
x7 = (unsigned int) x6;
if (x7 <= 268435455U)
abort ();
exit (0);
}
main()
{
short unsigned int x, y;
x = -5;
y = -10;
foo (&x, &y);
}
Is a much reduced testcase. Ultimately we have a range for x6 that's [0,
+INF(OVF)] at which point it's not safe to replace x7 with x6 in the
conditional.
[Bug rtl-optimization/57131] New: Wong register assignment?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57131
Bug #: 57131
Summary: Wong register assignment?
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ishiura-compi...@ml.kwansei.ac.jp
This miscompile occurs only on 32bit x86 (i686) target of GCC 4.8.1
(prerelease).
(There is no problem with x86_64 target or GCC 4.7.3.)
A dubious option is "-foptimize-register-move."
$ cat error.c
int main (void)
{
volatile int x1 = 0;
volatile long long x2 = 0;
volatile int x3 = 0;
volatile int x4 = 1;
volatile int x5 = 1;
volatile long long x6 = 1;
long long t = ( ( x1 * ( x2 << x3 ) ) / (x4 * x5) ) + x6 ;
return (t == 1);
}
$ i686-pc-linux-gnu-gcc-4.8.1 error.c -O1 -fexpensive-optimizations
-foptimize-register-move
$ ./a.out
Floating point exception (core dumped)
-
$ i686-pc-linux-gnu-gcc-4.8.1 -v
Using built-in specs.
COLLECT_GCC=i686-pc-linux-gnu-gcc-4.8.1
COLLECT_LTO_WRAPPER=/usr/local/i686-tools/gcc-4.8.1/libexec/gcc/i686-pc-linux-gnu/4.8.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /home/hassy-i686-linux/gcc/configure
--prefix=/usr/local/i686-tools/gcc-4.8.1/
--with-gmp=/usr/local/gmp-5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/
--with-mpc=/usr/local/mpc-1.0.1/ --disable-multilib --disable-nls
--enable-languages=c
Thread model: posix
gcc version 4.8.1 20130428 (prerelease) (GCC)
[Bug rtl-optimization/57130] [4.8/4.9 Regression] Incorrect "and --> extract" conversion in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57130 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-01 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.1 Summary|Incorrect "and --> extract" |[4.8/4.9 Regression] |conversion in combine |Incorrect "and --> extract" ||conversion in combine Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2013-05-01 06:41:55 UTC --- Started with http://gcc.gnu.org/r190492
[Bug rtl-optimization/57131] [4.8/4.9 Regression] Wrong register assignment?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57131 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-01 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.1 Summary|Wong register assignment? |[4.8/4.9 Regression] Wrong ||register assignment? Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2013-05-01 06:44:04 UTC --- Started with http://gcc.gnu.org/PR196090
