[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Not even with r202421. Content of main with that revision for x86_64 -Os is: .cfi_startproc pushq%rcx .cfi_def_cfa_offset 16 movla(%rip), %esi testl%esi, %esi je.L4 negl%esi testl%esi, %esi jg.L3 jmp.L2 .L4: xorl%esi, %esi .L2: movl$.LC0, %edi xorl%eax, %eax callprintf .L3: xorl%eax, %eax popq%rdx .cfi_def_cfa_offset 8 ret
[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #4 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Jakub Jelinek from comment #3) Not even with r202421. Content of main with that revision for x86_64 -Os is: .cfi_startproc pushq %rcx .cfi_def_cfa_offset 16 movla(%rip), %esi testl %esi, %esi je .L4 negl%esi testl %esi, %esi jg .L3 jmp .L2 .L4: xorl%esi, %esi .L2: movl$.LC0, %edi xorl%eax, %eax callprintf .L3: xorl%eax, %eax popq%rdx .cfi_def_cfa_offset 8 ret Here is what I have for x86_64 -Os: .cfi_startproc pushq%rax .cfi_def_cfa_offset 16 xorl%esi, %esi movl$.LC0, %edi xorl%eax, %eax callprintf xorl%eax, %eax popq%rdx .cfi_def_cfa_offset 8 ret .cfi_endproc Below is what I have for x86_64 -O1: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 movla(%rip), %eax testl%eax, %eax je.L2 negl%eax testl%eax, %eax jg.L3 .L2: movl$0, %esi movl$.LC0, %edi movl$0, %eax callprintf .L3: movl$0, %eax addq$8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc
[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Cannot reproduce either. Maybe you got hit by Jeffs bus introducing random bits into your bootstrap? So I wonder if it reproduces for you if you rebuild GCC ;)
[Bug ipa/58371] [4.9 Regression] internal compiler error: in ipcp_verify_propagated_values, at ipa-cp.c:892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58371 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- This ought to be fixed by yesterday Martin's commit 2013-09-10 Martin Jambor mjam...@suse.cz * ipa-cp.c (propagate_constants_topo): Do not ignore SCC represented by a thunk. Martin, perhaps adding the testcase is a good idea.
[Bug rtl-optimization/58384] [4.9 regression] Runfail on spec2000/253.perlbmk if lto and pre-reload scheduler is used on x86 after r200133.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58384 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Target Milestone|--- |4.9.0
[Bug target/55543] diamond shaped inheritance involving strings leads to crashing executables (MinGW, 32 bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55543 --- Comment #7 from Martin Gieseking martin.gieseking at uos dot de --- I can confirm that the issue seems to be gone in 4.8, and I can't reproduce it with 4.7.3 either. So it's probably fixed in the recent releases.
[Bug target/55543] diamond shaped inheritance involving strings leads to crashing executables (MinGW, 32 bit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55543 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org --- Ok, so it is fixed for all maintained version. I close this bug.
[Bug c++/58377] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to davidxl from comment #10) When an incoming edge to a phi is a critical edge, the 'use BB' for the phi arg should be in the split BB of the edge. Pushing the use into either the Source BB or the dest BB will result in extending the 'use' falsely in more BBs. In this case, simply use the PHI's BB won't solve the problem, as there is an incoming path introduced not guarded by if (iftmp.1_3 != 0) I don't see a good way to fix it unless splitting the edge. I wondered if we can make is_use_properly_guarded take the case of a use on an edge into account by simply injecting the predicate at the end of the predecessor into the list of predicates found by find_predicates. Hmm, but I see it's not a simple list of predicates ... I wonder what effect splitting critical edges somewhere before late uninit has on following optimization passes and RTL expansion and its out-of-SSA process (though the next cfgcleanup pass will unsplit the edges again, which is at latest pass_cleanup_cfg_post_optimizing) But I can confirm that the testcase is fixed with Index: gcc/passes.c === --- gcc/passes.c(revision 202445) +++ gcc/passes.c(working copy) @@ -1543,6 +1543,7 @@ init_optimization_passes (void) /* ??? We do want some kind of loop invariant motion, but we possibly need to adjust LIM to be more friendly towards preserving accurate debug information here. */ + NEXT_PASS (pass_split_crit_edges); NEXT_PASS (pass_late_warn_uninitialized); NEXT_PASS (pass_uncprop); NEXT_PASS (pass_local_pure_const); which does this just for -Og. I'm seriously considering this, splitting critical edges is cheap.
[Bug c++/57504] invalid this pointer passed in call to virtual function that returns a struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57504 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- So 4.7.3, 4.8, and 4.9 are ok. That means this bug was fixed by side-effect. No need to keep it open any longer. So I close it as fixed.
[Bug target/18649] terminate called after throwing - IOT/Abort trap (core dumped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18649 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- (In reply to Richard Biener from comment #7) Still an issue? gcc 4.8 and upward still have this issue.
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- gcc requires c++ for building and bootstrap. Therefore libstdc++ isn't disable and has to be built for stage 1 and stage 2.
[Bug bootstrap/58388] New: LTO profiledbootstrap fails in stage feedback for tree-ssa-structalias.c with internal compiler error: in try_make_edge_direct_simple_call, at ipa-prop.c:2606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58388 Bug ID: 58388 Summary: LTO profiledbootstrap fails in stage feedback for tree-ssa-structalias.c with internal compiler error: in try_make_edge_direct_simple_call, at ipa-prop.c:2606 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com CC: hubicka at gcc dot gnu.org LTO profiled bootstrap of gcc, configured --with-build-config=bootstrap-lto --enable-languages=c,c++,fortran fails [1] with: ../../gcc-svn/trunk/gcc/tree-ssa-structalias.c:7433:1: internal compiler error: in try_make_edge_direct_simple_call, at ipa-prop.c:2606 } ^ 0xcd3f85 try_make_edge_direct_simple_call ../../gcc-svn/trunk/gcc/ipa-prop.c:2603 0xcd3f85 update_indirect_edges_after_inlining ../../gcc-svn/trunk/gcc/ipa-prop.c:2704 0xcd3f85 propagate_info_to_inlined_callees ../../gcc-svn/trunk/gcc/ipa-prop.c:2771 0xcd4a0b ipa_propagate_indirect_call_infos(cgraph_edge*, veccgraph_edge*, va_heap, vl_ptr*) ../../gcc-svn/trunk/gcc/ipa-prop.c:2933 0x16def84 inline_call(cgraph_edge*, bool, veccgraph_edge*, va_heap, vl_ptr*, int*, bool) ../../gcc-svn/trunk/gcc/ipa-inline-transform.c:271 0x16dc620 inline_small_functions ../../gcc-svn/trunk/gcc/ipa-inline.c:1769 0x16dcd5f ipa_inline ../../gcc-svn/trunk/gcc/ipa-inline.c:2010 0x16dcd5f execute ../../gcc-svn/trunk/gcc/ipa-inline.c:2380 [1] http://gcc.gnu.org/ml/gcc-regression/2013-09/msg00344.html
[Bug c++/58389] New: g++ ICE in ipa_find_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58389 Bug ID: 58389 Summary: g++ ICE in ipa_find_reference Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marc.mutz at kdab dot com Created attachment 30796 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30796action=edit Preprocessed source (compressed to fit into file size limit) Compiling master Qt with the trunk version of g++: Command: g++ -std=c++11 -o out.o -c -include .pch/release-shared/Qt5Widgets -pipe -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -O2 -fvisibility=hidden -fvisibility-inlines-hidden -std=c++0x -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_XKB -DQT_NO_USING_NAMESPACE -DQT_BUILD_WIDGETS_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_ANDROID -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I/home/marc/qtbase/mkspecs/linux-g++ -I/home/marc/qtbase/src/widgets -I../../include -I../../include/QtWidgets -I../../include/QtWidgets/5.2.0 -I../../include/QtWidgets/5.2.0/QtWidgets -I/home/marc/qtbase/src/widgets/dialogs -I.uic/release-shared -I../../include/QtGui -I../../include/QtGui/5.2.0 -I../../include/QtGui/5.2.0/QtGui -I../../include/QtCore -I../../include/QtCore/5.2.0 -I../../include/QtCore/5.2.0/QtCore -I.moc/release-shared -I. /home/marc/qtbase/src/widgets/graphicsview/qgraphicsitem.cpp -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations In file included from ../../include/QtWidgets/5.2.0/QtWidgets/private/qpixmapfilter_p.h:1:0, from ../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/effects/qgraphicseffect_p.h:61, from ../../include/QtWidgets/5.2.0/QtWidgets/private/qgraphicseffect_p.h:1, from ../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/kernel/qwidget_p.h:66, from ../../include/QtWidgets/5.2.0/QtWidgets/private/qwidget_p.h:1, from ../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/widgets/qframe_p.h:56, from ../../include/QtWidgets/5.2.0/QtWidgets/private/qframe_p.h:1, from ../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/widgets/qabstractscrollarea_p.h:56, from ../../include/QtWidgets/5.2.0/QtWidgets/private/qabstractscrollarea_p.h:1, from /home/marc/qtbase/src/widgets/graphicsview/qgraphicsview_p.h:64, from /home/marc/qtbase/src/widgets/graphicsview/qgraphicsscene_p.h:62, from /home/marc/qtbase/src/widgets/graphicsview/qgraphicsitem.cpp:725: ../../include/QtWidgets/5.2.0/QtWidgets/private/../../../../../../qtbase/src/widgets/effects/qpixmapfilter_p.h:146:24: internal compiler error: Segmentation fault class Q_WIDGETS_EXPORT QPixmapColorizeFilter : public QPixmapFilter ^ 0xacbd0f crash_signal ../../gcc/gcc/toplev.c:335 0x98af50 ipa_find_reference(symtab_node_def*, symtab_node_def*, gimple_statement_d*, unsigned int) ../../gcc/gcc/ipa-ref.c:277 0x97ccde remove_described_reference ../../gcc/gcc/ipa-prop.c:2510 0x981064 ipa_edge_removal_hook ../../gcc/gcc/ipa-prop.c:3022 0x7d9068 cgraph_call_edge_removal_hooks ../../gcc/gcc/cgraph.c:314 0x7d9068 cgraph_node_remove_callees(cgraph_node*) ../../gcc/gcc/cgraph.c:1563 0x7d9524 cgraph_remove_node(cgraph_node*) ../../gcc/gcc/cgraph.c:1680 0x98e154 symtab_remove_unreachable_nodes(bool, _IO_FILE*) ../../gcc/gcc/ipa.c:453 0xf2bdb0 ipa_inline ../../gcc/gcc/ipa-inline.c:2014 0xf2bdb0 execute ../../gcc/gcc/ipa-inline.c:2380 Please submit a full bug report, with preprocessed source if appropriate. GCC version: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/opt/gcc/4.9-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/opt/gcc/4.9-trunk --enable-languages=c++ Thread model: posix gcc version 4.9.0 20130911 (experimental) (GCC)
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org --- Does the following patch helps to you? Index: c/c-decl.c === --- c/c-decl.c (Revision 202491) +++ c/c-decl.c (Arbeitskopie) @@ -3604,7 +3604,7 @@ c_builtin_function (tree decl) C_DECL_BUILTIN_PROTOTYPE (decl) = prototype_p (type); /* Should never be called on a symbol with a preexisting meaning. */ - gcc_assert (!I_SYMBOL_BINDING (id)); + gcc_assert (TREE_CODE (decl) == CONST_DECL || !I_SYMBOL_BINDING (id)); bind (id, decl, external_scope, /*invisible=*/true, /*nested=*/false, UNKNOWN_LOCATION); @@ -3629,9 +3629,6 @@ c_builtin_function_ext_scope (tree decl) const char *name = IDENTIFIER_POINTER (id); C_DECL_BUILTIN_PROTOTYPE (decl) = prototype_p (type); - /* Should never be called on a symbol with a preexisting meaning. */ - gcc_assert (!I_SYMBOL_BINDING (id)); - bind (id, decl, external_scope, /*invisible=*/false, /*nested=*/false, UNKNOWN_LOCATION);
[Bug tree-optimization/58389] [4.9 Regression] g++ ICE in ipa_find_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58389 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-11 CC||mpolacek at gcc dot gnu.org Component|c++ |tree-optimization Target Milestone|--- |4.9.0 Summary|g++ ICE in |[4.9 Regression] g++ ICE in |ipa_find_reference |ipa_find_reference Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug middle-end/58385] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58385 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Sep 11 11:35:51 2013 New Revision: 202494 URL: http://gcc.gnu.org/viewcvs?rev=202494root=gccview=rev Log: PR tree-optimization/58385 * fold-const.c (build_range_check): If both low and high are NULL, use omit_one_operand_loc to preserve exp side-effects. * gcc.c-torture/execute/pr58385.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr58385.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- See http://sourceware.org/bugzilla/show_bug.cgi?id=15930 for the as bugreport.
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 Earnie earnie at users dot sourceforge.net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from Earnie earnie at users dot sourceforge.net --- Kai, Your statement doesn't resolve anything at all. It is fine for gcc to require c++ but it is not fine for configure to continue if I only specify c and c++ is also built without an error being issued by configure stating that c++ is required. Previous versions of GCC I was able to build only c and c++ wasn't considered. Secondly, what is wrong with the process using an already installed c++ version to build gcc when only c is requested to be built? I should be able to expect to build only the language compiler requested without another language compiler being built along with it. Earnie
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Earnie from comment #4) Your statement doesn't resolve anything at all. It is fine for gcc to require c++ but it is not fine for configure to continue if I only specify c and c++ is also built without an error being issued by configure stating that c++ is required. Previous versions of GCC I was able to build only c and c++ wasn't considered. Secondly, what is wrong with the process using an already installed c++ version to build gcc when only c is requested to be built? I should be able to expect to build only the language compiler requested without another language compiler being built along with it. Use --disable-bootstrap for a native compiler if you want only C.
[Bug bootstrap/58388] LTO profiledbootstrap fails in stage feedback for tree-ssa-structalias.c with internal compiler error: in try_make_edge_direct_simple_call, at ipa-prop.c:2606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58388 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- Martin, this looks bit more like yours at first glance. I will try to reproduce it.
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- It doesn't resolve anything. It just describes a fact that a bootstrap of gcc without c++ beginning with 4.8+ isn't possible. So for stage1 and stage2 there has to be built a c++ compiler plus library due otherwise no bootstrap can be done. If you want to build only c then you have to use --disable-bootstrap for a native compiler if you want only C.
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 --- Comment #7 from Earnie earnie at users dot sourceforge.net --- --disable-bootstrap is an answer I can live with as resolving this issue. Use of --disable-build-poststage1-with-cxx should become an error in configure with the suggestion to use --disable-bootstrap instead.
[Bug tree-optimization/58389] [4.9 Regression] g++ ICE in ipa_find_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58389
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot de
--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de ---
Reduced:
template typename _RandomAccessIterator, typename _Compare
void __insertion_sort(_RandomAccessIterator, _Compare);
template typename _RandomAccessIterator, typename _Compare
void __final_insertion_sort(_RandomAccessIterator p1, _Compare p2) {
_RandomAccessIterator a;
if (p1 - a)
;
else
std:
__insertion_sort(0, p2);
}
template typename _RandomAccessIterator, typename _Size, typename _Compare
void __introsort_loop(_RandomAccessIterator, _Size, _Compare);
template typename _RandomAccessIterator, typename _Compare
void sort(_RandomAccessIterator, _RandomAccessIterator p2, _Compare p3) {
std:
__introsort_loop(0, 0, p3);
__final_insertion_sort(p2, p3);
}
class A {
public:
int m_fn1();
void __lg();
class B {
public:
int i;
int operator-(B);
};
};
class C;
class D {
public:
C *operator-();
};
class F {
A m_fn1() const;
D d_ptr;
};
class C {
friend F;
void m_fn1();
A children;
};
void qt_notclosestLeaf();
inline void C::m_fn1() {
A::B b, c;
if (children.m_fn1()) {
sort(c, b, qt_notclosestLeaf);
}
}
A F::m_fn1() const { const_castF *(this)-d_ptr-m_fn1(); }
[Bug ipa/58371] [4.9 Regression] internal compiler error: in ipcp_verify_propagated_values, at ipa-cp.c:892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58371 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #3) This ought to be fixed by yesterday Martin's commit 2013-09-10 Martin Jambor mjam...@suse.cz * ipa-cp.c (propagate_constants_topo): Do not ignore SCC represented by a thunk. Indeed, this patch which I have committed yesterday fixes the ICE. Martin, perhaps adding the testcase is a good idea. I will, I just had to make the first parameter of logging::LogMessage constructor const to get rid off a warning.
[Bug middle-end/58385] [4.7/4.8/4.9 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58385 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Sep 11 12:17:47 2013 New Revision: 202495 URL: http://gcc.gnu.org/viewcvs?rev=202495root=gccview=rev Log: PR tree-optimization/58385 * fold-const.c (build_range_check): If both low and high are NULL, use omit_one_operand_loc to preserve exp side-effects. * gcc.c-torture/execute/pr58385.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr58385.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/fold-const.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/58385] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58385 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] likely |likely wrong code bug |wrong code bug --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 4.8.2+ so far.
[Bug c++/58377] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Sep 11 12:20:07 2013 New Revision: 202496 URL: http://gcc.gnu.org/viewcvs?rev=202496root=gccview=rev Log: 2013-09-11 Richard Biener rguent...@suse.de PR middle-end/58377 * passes.def: Split critical edges before late uninit warning passes. * tree-cfg.c (pass_split_crit_edges): Implement clone method. * g++.dg/uninit-pred-4.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/uninit-pred-4.C Modified: trunk/gcc/ChangeLog trunk/gcc/passes.def trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug tree-optimization/58389] [4.9 Regression] g++ ICE in ipa_find_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58389 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- This also seems like I should have a look.
[Bug tree-optimization/58389] [4.9 Regression] g++ ICE in ipa_find_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58389 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r202281.
[Bug c++/58377] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Sep 11 12:23:15 2013 New Revision: 202498 URL: http://gcc.gnu.org/viewcvs?rev=202498root=gccview=rev Log: 2013-09-11 Richard Biener rguent...@suse.de PR middle-end/58377 * passes.c (init_optimization_passes): Split critical edges before late uninit warning pass in the -Og pipeline. * g++.dg/uninit-pred-4.C: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/uninit-pred-4.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/passes.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/58377] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.2 Known to fail||4.8.1 --- Comment #14 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org --- please note that bugzilla isn't the proper place to get end-user support about how to use options. To cite your favorite sentence please read first the mail-archive. Actually you weren't the first person having this question. Such questions are better placed at gcc-help.
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #13 from Jacek Caban jacek at codeweavers dot com --- Yes, it helps. Thanks.
[Bug c++/35878] Useless NULL pointer check when constructing object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||glisse at gcc dot gnu.org, ||redi at gcc dot gnu.org Resolution|DUPLICATE |--- --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- I am separating this PR from PR 19476 because it really isn't the same at all. Copying Ian's later comment so it isn't lost: Note that bug 35878, which was closed as a duplicate of this one, was a case of placement new. For placement new the check for a NULL pointer is particularly useless, as the language standard says that placement new is required to return the pointer which was passed in. The check for a null pointer after a call to placement new is sadly required by the standard (if anyone cares to try and get that changed, please go ahead). See this link for instance for an analysis: http://stackoverflow.com/questions/17571103/passing-null-pointer-to-placement-new p=new(nullptr)int(42); is an absurd but valid way of saying p=0;. For the compiler to know that the pointer is non-zero, it would need to see where the pointer is coming from, which is not the case in this testcase. The only place I can think of where we could tell the compiler to skip this check is in the library. I don't know if we should add if(p==0)__builtin_unreachable(); somewhere, or create a new attribute((neverzero)) for the pointer in the vector, or something else, but the knowledge that the pointer is not zero belongs in the library. (leaving as unconfirmed and not setting the component to libstdc++ because I'd like someone else to confirm this)
[Bug c++/19476] Missed null checking elimination with new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476 --- Comment #15 from Marc Glisse glisse at gcc dot gnu.org --- I posted a patch: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00676.html However, note that it only optimizes the testcase from this PR if we add #include new at the beginning, otherwise the implicit declaration of operator new doesn't have its operator_new_flag set...
[Bug target/58390] New: avr-gcc produces unusable code when label address is placed in register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58390
Bug ID: 58390
Summary: avr-gcc produces unusable code when label address is
placed in register
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: semicontinuity at yandex dot ru
Trying to speed up the following code, I've placed 'address' variable to the
r2:r3 (and added -ffixed-r2 -ffixed-r3):
// -
//void* address; // placed in memory (OK)
//register void* address asm(r30); // placed in r30:r31 (OK)
register void* address asm(r2); // placed in r2:r3 or any other register
(NOT OK)
void test(void) {
char flag = 1;
goto *address; // address is computed properly beforehand
for(;;) {
asm volatile(nop\t\n);
flag = 0;
L1: (void)L1;
if (flag==0) { address = L1; return; }
asm volatile(nop\t\n);
flag = 0;
L2: (void)L2;
if (flag==0) { address = L2; return; }
}
}
int main(void) {
for(;;) {
test();
}
return 0;
}
// -
If 'address' variable is placed in memory or in r30:r31, the generated code is
OK:
// -
003c test:
register void* address asm(r30);
void test(void) {
3c:09 94 ijmp
goto *address; // address is computed properly
for(;;) {
asm volatile(nop\t\n);
3e:00 00 nop
// -
ijmp is generated for computed goto, address is already in r30:r31 for ijmp.
If 'address' variable is placed in memory or in r2:r3, the generated code is
NOT OK:
// -
003c test:
register void* address asm(r2);
void test(void) {
3c:2f 92 pushr2
3e:3f 92 pushr3
40:08 95 ret
goto *address; // address is computed properly
for(;;) {
asm volatile(nop\t\n);
42:00 00 nop
// -
No ijmp is generated. Instead, push r2, push r3 and ret. No pops are generated.
The expected output should ideally be
// -
003c test:
register void* address asm(r2);
void test(void) {
3c:? ? movwr30, r2
3e:09 94 ijmp
goto *address; // address is computed properly
for(;;) {
asm volatile(nop\t\n);
40:00 00 nop
// -
=
avr-gcc -c -mmcu=atmega8535 -I. -gdwarf-2 -I../../bsp -I../../../.. -O3
-save-temps -v -ffixed-r2 -ffixed-r3 -funsigned-char -funsigned-bitfields
-fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef
-Wa,-adhlns=.obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c
-o .obj/main.o
Using built-in specs.
COLLECT_GCC=avr-gcc
Target: avr
Configured with: ../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7-mingw32 --host=i386-mingw32
--build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared
--with-dwarf2 --with-avrlibc=yes
Thread model: single
gcc version 4.7.2 (GCC)
[Bug target/58391] New: avr-gcc: Certain functions with computed goto could be inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58391
Bug ID: 58391
Summary: avr-gcc: Certain functions with computed goto could be
inlined
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: semicontinuity at yandex dot ru
Certain functions with computed goto could be inlined.
Currently, if a function contains computed goto it is not inlined.
Here, the function and the address variable are static and function is called
from one place only, so the compiler could have inlined the function, just like
functions without computed goto.
// -
static void* address;
static void test(void) {
char flag = 1;
goto *address; // address is computed properly beforehand (left out for
brevity)
for(;;) {
asm volatile(nop\t\n);
flag = 0;
L1: (void)L1;
if (flag==0) { address = L1; return; }
asm volatile(nop\t\n);
flag = 0;
L2: (void)L2;
if (flag==0) { address = L2; return; }
}
}
int main(void) {
for(;;) {
test();
}
return 0;
}
// -
Compiling C: main.c
avr-gcc -c -mmcu=atmega8535 -I. -gdwarf-2 -I../../bsp -I../../../.. -O3
-save-temps -v -ffixed-r2 -ffixed-r3 -funsigned-char -funsigned-bitfields
-fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef
-Wa,-adhlns=.obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c
-o .obj/main.o
Using built-in specs.
COLLECT_GCC=avr-gcc
Target: avr
Configured with: ../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7-mingw32 --host=i386-mingw32
--build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared
--with-dwarf2 --with-avrlibc=yes
Thread model: single
gcc version 4.7.2 (GCC)
[Bug c++/35878] Useless NULL pointer check when constructing object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Marc Glisse from comment #2) The only place I can think of where we could tell the compiler to skip this check is in the library. I don't know if we should add if(p==0)__builtin_unreachable(); somewhere, or create a new attribute((neverzero)) for the pointer in the vector, or something else, but the knowledge that the pointer is not zero belongs in the library. Yes, I'm inclined to agree.
[Bug c++/19476] Missed null checking elimination with new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476 --- Comment #16 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Marc Glisse from comment #15) However, note that it only optimizes the testcase from this PR if we add #include new at the beginning, otherwise the implicit declaration of operator new doesn't have its operator_new_flag set... That can (and probably should, since this flag is also used in alias analysis) be fixed with something like: --- /data/repos/gcc/newnonzero/gcc/cp/decl.c(revision 202499) +++ /data/repos/gcc/newnonzero/gcc/cp/decl.c(working copy) @@ -3799,8 +3799,8 @@ cxx_init_decl_processing (void) newtype = build_exception_variant (newtype, new_eh_spec); deltype = cp_build_type_attribute_variant (void_ftype_ptr, extvisattr); deltype = build_exception_variant (deltype, empty_except_spec); -push_cp_library_fn (NEW_EXPR, newtype, 0); -push_cp_library_fn (VEC_NEW_EXPR, newtype, 0); +DECL_IS_OPERATOR_NEW (push_cp_library_fn (NEW_EXPR, newtype, 0)) = 1; +DECL_IS_OPERATOR_NEW (push_cp_library_fn (VEC_NEW_EXPR, newtype, 0)) = 1; global_delete_fndecl = push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW); push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
[Bug c++/58337] Mangling of nullptr_t values do not follow ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58337 Hubert Tong hstong at ca dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hubert Tong hstong at ca dot ibm.com --- There are indications that the ABI will be updated to clarify this case. A resolved template argument value will use LDn0E while a nullptr literal in other contexts will use LDnE.
[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #6 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Richard Biener from comment #5) Cannot reproduce either. Maybe you got hit by Jeffs bus introducing random bits into your bootstrap? So I wonder if it reproduces for you if you rebuild GCC ;) Hi guys, I rebuilt GCC, but it still reproduces for me (see below). Did you configure with --enable-checking=release? $ 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 --enable-languages=c,c++,objc,obj-c++,fortran,lto --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 4.9.0 20130911 (experimental) [trunk revision 202489] (GCC) $ gcc-trunk -Os small.c $ a.out 0 $ gcc-trunk -O1 small.c $ a.out $
[Bug libgomp/58392] internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 --- Comment #1 from tprince at computer dot org --- Created attachment 30798 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30798action=edit pre-processed source
[Bug libgomp/58392] internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 --- Comment #2 from tprince at computer dot org --- Created attachment 30799 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30799action=edit C source
[Bug libgomp/58392] New: internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 Bug ID: 58392 Summary: internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org CC: jakub at gcc dot gnu.org Created attachment 30797 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30797action=edit log file describe above gomp_4.0-branch up to date gcc -O2 -ftree-vectorize -fopenmp -std=c99 -funroll-loops --param max-unroll-times=4 -ffast-math -march=native -c -x c -v s3110.i build.log 2 1 default backtrace in attached build.log. Unable to find compatible glib-debuginfo rpm for current installation.
[Bug libstdc++/58393] Please relax feature check for std::to_string and std::sto* for uClibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- In any case, please send patches to the mailing list, attached to bug report will be easily overlooked. More specifically, if we are going to be more fine grained about C99 support, other headers have to be consistently updated.
[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 Rich Townsend townsend at astro dot wisc.edu changed: What|Removed |Added CC||townsend at astro dot wisc.edu --- Comment #9 from Rich Townsend townsend at astro dot wisc.edu --- (In reply to Mikael Morin from comment #8) Created attachment 30656 [details] tentative hack For some reason this patch fixes the internal error on comment #6, but not on comment #4. I can conform that this patch works to fix the bug on trunk (rev. 202487) running on OS X 10.7. Without the patch, the test case in #6 fails with the usual unresolved fixup issue. However, *with* Mikael's patch I'm no longer able to build the HDF5 libraries (1.8.10-patch1). During compilation of the Fortran API, I get the following: tH5L_F03.f90:125.6: USE liter_cb_mod 1 Internal Error at (1): free_pi_tree(): Unresolved fixup make[2]: *** [tH5L_F03.o] Error 1 I configured thusly: ./configure --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/mesasdk --enable-fortran --enable-fortran2003 This has become a showstopper for me: I need Mikael's patch to fix unresolved fixup issues with my own codes (with a similar trigger to the examples given above), but I also need the HDF5 libraries for the codes. Unresolved fixups are the #1 bug I've encountered with gfortran over the past year, yet due to their very temperamental nature they're difficult to report and thus difficult to make the gfortran developers sit up and take notice of. So, I'd like to make a earnest plea to the devs: please get to the bottom of this! I'm happy to work closely with you in coming up with test cases that trigger the bug. But this really needs to be fixed; it basically kills gfortran as a viable compiler.
[Bug libstdc++/35878] Useless NULL pointer check when constructing object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-11 Component|c++ |libstdc++ Ever confirmed|0 |1 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- Confirming then. Jonathan, you didn't send a mail to the reflectors after your post on SO, did you? Unless you want to do it, I think I'll send one, just to make sure there is no hope of removing that check at the core level.
[Bug tree-optimization/58391] avr-gcc: Certain functions with computed goto could be inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58391 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords|wrong-code | Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Component|target |tree-optimization Resolution|--- |INVALID --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- This is not a bug, it's a feature. For reasoning see tree-inline.c: http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_7-branch/gcc/tree-inline.c?view=markup#l3170
[Bug libstdc++/58395] New: Undefined behavior vs. exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58395 Bug ID: 58395 Summary: Undefined behavior vs. exception Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: frankhb1989 at gmail dot com Several operations are undefined because they failed to meet required behavior(ISO C++11 [defns.required.behavior]) at runtime. Currently libstdc++ throw exceptions for them. For example, when object of type std::string being initialized using a null pointer value, an exception of type std::logic_error is thrown by basic_stringchar::_S_construct. That's nothing wrong for libstdc++ on conformance, because an implementation is free to do anything when the behavior is undefined. However, this behavior is somewhat confusing for users not so familiar with the standard. I suggest 2 options for future releases of libstdc++: 1. Make the type of exceptions specific(i.e. as a documented feature), distinguishable with other exceptions required to be thrown by the standard. It can be a type derived from std::logic_error, as an extension. 2. Make the implementation-defined result of what() specific and distinguishable, e.g. some prefix to indicate the exception is not mandated. This is not only good for manually distinguishing UB, but also beneficial for tests on conformance/portability of user programs.
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 --- Comment #36 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Jakub Jelinek from comment #35) The #c34 testcase seems to fail starting r199048 till current HEAD. Besides John's new testcase from #c34, I've also encountered quite a number of different testcases causing this same ICE (either at -O2 or -O3, with and without -g), but the proposed patch by Easwaran from #c30 appears to fix everything so far (tested with revision 202121).
[Bug libstdc++/35878] Useless NULL pointer check when constructing object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- No, I never got round to sending it to the reflector, but I'd be interested to hear the committee's views on a change.
[Bug tree-optimization/58396] New: [4.9 Regression] heap-use-after-free at gcc/tree-loop-distribution.c:1959
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58396 Bug ID: 58396 Summary: [4.9 Regression] heap-use-after-free at gcc/tree-loop-distribution.c:1959 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: markus at trippelsdorf dot de bootstrap-asan with -O3 gives: /var/tmp/gcc_build_dir/./gcc/xgcc -shared-libgcc -B/var/tmp/gcc_build_dir/./gcc -nostdinc++ -L/var/tmp/gcc_build_dir/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/var/tmp/gcc_build_dir/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/gcc_build_dir/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -I/var/tmp/gcc/libstdc++-v3/../libgcc -I/var/tmp/gcc_build_dir/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/var/tmp/gcc_build_dir/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/var/tmp/gcc/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=bitmap_allocator.lo -march=native -O3 -g -pipe -c ../../../../../gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o bitmap_allocator.o 21 | asan_symbolize.py | c++filt = ==20268== ERROR: AddressSanitizer: heap-use-after-free on address 0x6006001646e4 at pc 0x15abf35 bp 0x7fffc85df980 sp 0x7fffc85df978 READ of size 4 at 0x6006001646e4 thread T0 #0 0x15abf34 in build_rdg /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/vec.h:1238 #1 0x15ad344 in distribute_loop /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/tree-loop-distribution.c:1959 #2 0x11f91cf in execute_one_pass(opt_pass*) /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/passes.c:2201 #3 0x11fa99b in execute_pass_list /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/passes.c:2253 #4 0xb3336b in expand_function /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/cgraphunit.c:1723 #5 0xb370a1 in expand_all_functions /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/cgraphunit.c:1828 #6 0xb37f44 in compile /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/cgraphunit.c:2065 #7 0x6d7569 in cp_write_global_declarations() /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/cp/decl2.c:4364 #8 0x14726da in compile_file /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/toplev.c:560 #9 0x1476537 in do_compile /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/toplev.c:1891 #10 0x7f76ffe3aa74 in __libc_start_main /home/markus/glibc/csu/libc-start.c:269 #11 0x5439e0 in _start /home/markus/glibc/csu/../sysdeps/x86_64/start.S:122 0x6006001646e4 is located 4 bytes inside of 32-byte region [0x6006001646e0,0x600600164700) freed by thread T0 here: #0 0x557e4a in __interceptor_free _asan_rtl_ #1 0x15aa68b in releaseloop* /var/tmp/gcc_build_dir/gcc/../../gcc/gcc/vec.h:319 previously allocated by thread T0 here: #0 0x557f4a in __interceptor_malloc _asan_rtl_ #1 0x24cfa74 in xrealloc /var/tmp/gcc_build_dir/libiberty/../../gcc/libiberty/xmalloc.c:177 Shadow bytes around the buggy address: 0x0c0140024880: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd 0x0c0140024890: fd fa fa fa fd fd fd fa fa fa 00 00 00 00 fa fa 0x0c01400248a0: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa 0x0c01400248b0: fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 0x0c01400248c0: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa =0x0c01400248d0: 00 00 00 fa fa fa 00 00 00 fa fa fa[fd]fd fd fd 0x0c01400248e0: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd 0x0c01400248f0: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa 0x0c0140024900: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa 0x0c0140024910: fa fa fd fd fd fa fa fa fd fd fd fd fa fa fd fd 0x0c0140024920: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap righ redzone: fb Freed Heap region: fd Stack left redzone:f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return:f5 Stack use after scope: f8 Global redzone:f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==20268== ABORTING I guess r202431 is to blame.
[Bug libgomp/58392] internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 --- Comment #3 from tprince at computer dot org --- Created attachment 30801 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30801action=edit include file needed for compilation from C source
[Bug target/58390] avr-gcc produces unusable code when label address is placed in register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58390
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||gjl at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org ---
(In reply to semicontinuity from comment #0)
Trying to speed up the following code, I've placed 'address' variable to the
r2:r3 (and added -ffixed-r2 -ffixed-r3):
// -
//void* address; // placed in memory (OK)
//register void* address asm(r30); // placed in r30:r31 (OK)
register void* address asm(r2); // placed in r2:r3 or any other register
(NOT OK)
void test(void) {
char flag = 1;
goto *address; // address is computed properly beforehand
for(;;) {
asm volatile(nop\t\n);
flag = 0;
L1: (void)L1;
if (flag==0) { address = L1; return; }
asm volatile(nop\t\n);
flag = 0;
L2: (void)L2;
if (flag==0) { address = L2; return; }
}
}
int main(void) {
for(;;) {
test();
}
return 0;
}
// -
If 'address' variable is placed in memory or in r30:r31, the generated code
is OK:
// -
003c test:
register void* address asm(r30);
void test(void) {
3c: 09 94 ijmp
goto *address; // address is computed properly
for(;;) {
asm volatile(nop\t\n);
3e: 00 00 nop
// -
ijmp is generated for computed goto, address is already in r30:r31 for ijmp.
If 'address' variable is placed in memory or in r2:r3, the generated code is
NOT OK:
// -
003c test:
register void* address asm(r2);
void test(void) {
3c: 2f 92 pushr2
3e: 3f 92 pushr3
40: 08 95 ret
goto *address; // address is computed properly
for(;;) {
asm volatile(nop\t\n);
42: 00 00 nop
// -
No ijmp is generated. Instead, push r2, push r3 and ret. No pops are
generated.
This PUSH/PUSH/RET sequence is in order because is acts exactly like an IJMP
for targets with 16-bit PC. This is the case for ATmega8535 as of
-mmcu=atmega8535.
FYI, reserving r30/r31 (Z-reg) might break code because there are situations
where the compiler cannot generate code without using Z, e.g. when reading from
flash by means of LPM. Or indirect addressing when a frame pointer is needed
and Y cannot be used for addressing.
[Bug ipa/58398] [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Added CC.
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-11 Target Milestone|--- |4.9.0 Summary|wrong code at -Os and above |[4.9 Regression] wrong code |on x86_64-linux-gnu (both |at -Os and above on |32-bit and 64-bit modes)|x86_64-linux-gnu (both ||32-bit and 64-bit modes) Ever confirmed|0 |1 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- stage2 and stage3 are miscompiled. stage1 is OK.
[Bug ipa/58398] New: [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398 Bug ID: 58398 Summary: [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Somewhere between r202108 [1] and r202113 [2] a testsuite regression was introduced: FAIL: gcc.dg/attr-ifunc-4.c execution test r202111 is the most probable change that introduced this regression: Author: hubicka Date: Fri Aug 30 15:41:26 2013 New Revision: 202111 URL: http://gcc.gnu.org/viewcvs?rev=202111root=gccview=rev Log: * cgraph.c (cgraph_function_body_availability): Handle weakref correctly. * passes.def: Remove pass_fixup_cfg. * ipa-inline.c (ipa_inline): When not optimizing, do not inline; track when we need to remove functions. (gate_ipa_inline): Execute inlining always; add comment why. (pass_data_ipa_inline): Remove TODO_remove_functions. * ipa-inline-analysis.c (inline_generate_summary): When not optimizing do not produce summaries. * symtab.c (change_decl_assembler_name): Handle renaming of weakrefs. (symtab_nonoverwritable_alias): Assert we are not called on weakref. * varpool.c (cgraph_variable_initializer_availability): Fix weakrefs, constant pool and vtable. [1] http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg02931.html [2] http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg02937.html
[Bug libstdc++/58393] New: Please relax feature check for std::to_string and std::sto* for uClibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393 Bug ID: 58393 Summary: Please relax feature check for std::to_string and std::sto* for uClibc Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: nicolas.cavallari at lri dot fr Created attachment 30800 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30800action=edit Relax constraints on std::to_w?string and std:sto* The GCC build system's feature check that must be passed to enable support for std::to_w?string and std::sto.* asks for the underlying C library to support a large set of C99 functions, including C99 real and complex math. uClibc does not implement complex math function and the C99 real math functions are optional. The implementation of std::to_w?string and std::sto.* do not use complex math functions and probably never will, so it is a bit sad that a libstdc++ built against uClibc does not provide std::to_w?string and std::sto.* The feature check should be relaxed to only requires the functions that are actually used to implement std::to_w?string and std::sto.* The attached patch is an example of how it could be done.
[Bug ipa/58371] [4.9 Regression] internal compiler error: in ipcp_verify_propagated_values, at ipa-cp.c:892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58371 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-09/msg00840.htm ||l Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- I have posted the patch to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00840.html
[Bug target/58394] New: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58394 Bug ID: 58394 Summary: unrecognizable insn Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xperience at interia dot pl When I try to compile firefox under gentoo I have following error: /var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/celt/rate.c: In function 'compute_allocation': /var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/celt/rate.c:642:1: error: unrecognizable insn: } ^ (insn 1411 1410 1412 195 (set (reg:V4SI 1247) (unspec:V4SI [ (const_vector:V4SI [ (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) ]) (reg:V4SI 1243 [ vect_var_.67 ]) (const_int 1 [0x1]) ] UNSPEC_VCGE)) /var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/celt/rate.c:525 -1 (nil)) /var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/celt/rate.c:642:1: internal compiler error: in extract_insn, at recog.c:2150 full command line: armv7a-hardfloat-linux-gnueabi-gcc -o rate.o -c -fvisibility=hidden -DOPUS_BUILD -DOPUS_VERSION='draft-11-mozilla' -DUSE_ALLOCA -Drestrict= -DHAVE_LRINTF -DMOZ_GLUE_IN_PROGRAM -I/var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/include -I/var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/celt -I/var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/silk -I/var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/src -I/var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/silk/float -I/var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus -I. -I../../dist/include -I/usr/include/nspr -I/usr/include/nss -fPIC -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wno-unused -Wno-overlength-strings -pipe -fomit-frame-pointer -mtune=native -mcpu=native -mfpu=neon-vfpv4 -mfloat-abi=hard -fPIC -fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -O3 -fomit-frame-pointer -include ../../mozilla-config.h -DMOZILLA_CLIENT -MD -MF .deps/rate.o.pp /var/tmp/portage/www-client/firefox-17.0.8/work/mozilla-esr17/media/libopus/celt/rate.c It happends only when -O3 is used
[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397 --- Comment #1 from Martin Husemann martin at netbsd dot org --- Created attachment 30803 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30803action=edit host hooks for NetBSD
[Bug preprocessor/58397] New: Please add host_hooks for NetBSD to make precompiled headers work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397 Bug ID: 58397 Summary: Please add host_hooks for NetBSD to make precompiled headers work Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Created attachment 30802 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30802action=edit build glue changes As discussed in #58370 and #58379, precompiled headers do not work on NetBSD hosts. To fix this, a new gcc/config/host-netbsd.c file and the needed build glue is attached. This is mostly a copy of the openbsd stuff with a few minor changes (like adding MAP_FIXED, which is needed on NetBSD) and adding a different address for sparc64 machines.
[Bug middle-end/44848] Bogus array subscript is below array bounds with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44848 --- Comment #4 from Eero Tamminen eerott at gmail dot com --- (In reply to Richard Biener from comment #1) This is the same as PR43270 (and the fix for it cures it). *** This bug has been marked as a duplicate of 43270 *** Current status is still NEW, but there's no comment why duplicate status was changed back to NEW. Did the fix to (already verified) bug 43270 fix also this bug (i.e. should this also be verified) or not?
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #24 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Sep 11 22:24:50 2013 New Revision: 202510 URL: http://gcc.gnu.org/viewcvs?rev=202510root=gccview=rev Log: 2013-09-11 Mitsuru Kariya kariya_mits...@hotmail.com Chris Jefferson ch...@bubblescope.net PR libstdc++/58358 * include/bits/stl_algo.h (search_n): Fix to guarantee a number of comparisons = number of elements in the range. * testsuite/25_algorithms/search_n/58358.cc: New. * testsuite/25_algorithms/search_n/iterator.cc: Extend. Added: trunk/libstdc++-v3/testsuite/25_algorithms/search_n/58358.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/testsuite/25_algorithms/search_n/iterator.cc
[Bug libstdc++/58358] [4.7/4.8 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] |search_n has a Complexity |search_n has a Complexity |violation for random access |violation for random access |iterator|iterator --- Comment #25 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed in mainline so far.
[Bug ipa/58389] [4.9 Regression] g++ ICE in ipa_find_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58389 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Component|tree-optimization |ipa Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Mine. I'm testing a fix.
[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369
--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se ---
(All source references here are for vanilla gcc-4.8.1.)
The problem appears to start in choose_reload_regs, in the if (inheritance)
block at lines 6497 to 6679. It finds (reg:DF 0 %d0 [orig:109 D.2384 ] [109])
in rld[r].in. The if (regno = 0 ...) test at line 6543 passes so that block
is entered. last_reg is (reg:XF 17 %fp1) and byte is still 0, so it calls
subreg_regno_offset (17, XFmode, 0, DFmode) at line 6560.
subreg_regno_offset in turn just calls subreg_get_info.
In subreg_get_info xmode is XFmode with size 12 and precision 80, while ymode
is DFmode with size 8 and precision 64.
The first if (HARD_REGNO_NREGS_HAS_PADDING ...) is false so that block is
skipped. nregs_xmode and nregs_ymode are computed, both are 1.
The second if for paradoxical subregs is false, so that block is skipped.
The third if If registers store different numbers of bits in the different
modes, we cannot generally form this subreg at line 3345 is true, so that
block is entered. regsize_xmode and regsize_ymode are computed, they are 12
and 8 respectively. None of the inner if:s there are true, because nregs_xmode
and nregs_ymode are both 1, which isn't 1, so we don't return.
The fourth if for lowpart subregs at line 3371 is false, because the input
offset is 0 (byte from choose_reload_regs), but subreg_lowpart_offset
(DFmode, XFmode) returns 4, and 0 != 4. So that block is skipped.
Next we reach the gcc_assert ((GET_MODE_SIZE (xmode) % GET_MODE_SIZE (ymode))
== 0); at line 3387. However, this evaluates as (12 % 8) == 0, which is
false, so the assertion fails and we ICE.
So the problem as I understand it is that choose_reload_regs forms a virtual
subreg with differently-sized modes and offset 0, while on big-endian machines
the offset must be 0 (see subreg_lowpart_offset in emit-rtl.c), so the virtual
subreg is not recognized as a normal lowpart subreg.
I *think* other machines don't see this problem because:
a) offset 0 is correct for little-endian like x86 and most ARMs,
b) many big-endian machines define CANNOT_CHANGE_MODE_CLASS to reject
differently-sized modes in floating-point registers, which can prevent the
bogus subreg_regno_offset call,
c) their larger modes are whole multiples of their smaller modes, so the
assertion doesn't fail.
However, m68k:
d) is big-endian,
e) doesn't define CANNOT_CHANGE_MODE_CLASS,
f) has an XFmode which is 1.5 times as large as its DFmode.
If I add a suitable definition of CANNOT_CHANGE_MODE_CLASS, e.g.
--- gcc-4.8.1/gcc/config/m68k/m68k.h.~1~2013-01-10 21:38:27.0
+0100
+++ gcc-4.8.1/gcc/config/m68k/m68k.h2013-09-11 18:28:58.160242077 +0200
@@ -409,6 +409,11 @@ along with GCC; see the file COPYING3.
#define HARD_REGNO_MODE_OK(REGNO, MODE) \
m68k_regno_mode_ok ((REGNO), (MODE))
+#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
+ (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \
+ ? reg_classes_intersect_p (FP_REGS, CLASS) \
+ : 0)
+
#define SECONDARY_RELOAD_CLASS(CLASS, MODE, X) \
m68k_secondary_reload_class (CLASS, MODE, X)
then the ICE disappears. However, reading the m68k backend I think this is
against its intentions, and I suspect it is stricter than necessary.
Other calls to subreg_regno_offset either take the parameters from an existing
real subreg, or compute a correct lowpart offset (regcprop.c:maybe_mode_change,
var-tracking.c:var_lowpart). So I'm starting to think that the bug is in
choose_reload_regs: it should pass a proper lowpart offset in byte, not the
constant 0 (byte is only set for input subregs that are pseudos). The
following patch:
--- gcc-4.8.1/gcc/reload1.c.~1~ 2013-01-21 15:55:05.0 +0100
+++ gcc-4.8.1/gcc/reload1.c 2013-09-11 19:58:37.979482251 +0200
@@ -6497,6 +6497,7 @@ choose_reload_regs (struct insn_chain *c
if (inheritance)
{
int byte = 0;
+ bool byte_is_fixed = false;
int regno = -1;
enum machine_mode mode = VOIDmode;
@@ -6519,7 +6520,10 @@ choose_reload_regs (struct insn_chain *c
if (regno FIRST_PSEUDO_REGISTER)
regno = subreg_regno (rld[r].in_reg);
else
- byte = SUBREG_BYTE (rld[r].in_reg);
+ {
+ byte = SUBREG_BYTE (rld[r].in_reg);
+ byte_is_fixed = true;
+ }
mode = GET_MODE (rld[r].in_reg);
}
#ifdef AUTO_INC_DEC
@@ -6557,6 +6561,8 @@ choose_reload_regs (struct insn_chain *c
rtx last_reg = reg_last_reload_reg[regno];
i = REGNO (last_reg);
+ if (! byte_is_fixed)
+ byte = subreg_lowpart_offset (mode, GET_MODE (last_reg));
i += subreg_regno_offset (i, GET_MODE (last_reg), byte,
mode);
last_class
[Bug c++/58399] New: explicit constructor called implicitly with empty init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58399
Bug ID: 58399
Summary: explicit constructor called implicitly with empty
init-list
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
I think the following test should not compile, where an a object is implicitly
constructed when calling foo() using its explicit constructor.
struct a
{
explicit a () { }
};
void foo (a)
{
}
int main ()
{
foo ({ });
}
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #1 from Chen Gang gang.chen at asianux dot com --- It is for Linux kernel next-20130828 version. and for the latest Linux kernel, h8/300 has been removed.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #2 from Chen Gang gang.chen at asianux dot com --- it is not found in gcc-4.8.0.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #3 from Chen Gang gang.chen at asianux dot com --- The related command line: /usr/local/bin/h8300-gchen-elf-gcc -Wp,-MD,fs/.namei.o.d -nostdinc -isystem /usr/local/lib/gcc/h8300-gchen-elf/4.9.0/include -I/root/linux-next/arch/h8300/include -Iarch/h8300/include/generated -Iinclude -I/root/linux-next/arch/h8300/include/uapi -Iarch/h8300/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized -mh -mint32 -fno-builtin -g -D__linux__ -DUTS_SYSNAME=\uClinux\ -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -femit-struct-debug-baseonly -fno-var-tracking -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(namei) -DKBUILD_MODNAME=KBUILD_STR(namei) -c -o fs/.tmp_namei.o fs/namei.c
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 Chen Gang gang.chen at asianux dot com changed: What|Removed |Added CC||gang.chen at asianux dot com --- Comment #4 from Chen Gang gang.chen at asianux dot com --- (In reply to Chen Gang from comment #2) it is not found in gcc-4.8.0. That means: gcc-4.8.0 has no this issue, only 4.9.0 has (and in my memory, gcc-4.7.4 may also has this issue, but I am not quite sure).
[Bug c/58400] New: gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
Bug ID: 58400
Summary: gcc for h8300 internal compiler error: insn does not
satisfy its constraints at fs/ext4/mballoc.c: In
function 'mb_free_blocks':
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen at asianux dot com
For Linux kernel next-20130828 version:
The command line:
/usr/local/bin/h8300-gchen-elf-gcc -Wp,-MD,fs/ext4/.mballoc.o.d -nostdinc
-isystem /usr/local/lib/gcc/h8300-gchen-elf/4.9.0/include
-I/root/linux-next/arch/h8300/include -Iarch/h8300/include/generated -Iinclude
-I/root/linux-next/arch/h8300/include/uapi -Iarch/h8300/include/generated/uapi
-I/root/linux-next/include/uapi -Iinclude/generated/uapi -include
/root/linux-next/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized -mh -mint32
-fno-builtin -g -D__linux__ -DUTS_SYSNAME=\uClinux\ -fno-reorder-blocks
-fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g
-femit-struct-debug-baseonly -fno-var-tracking
-fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -DMODULE -DKBUILD_STR(s)=#s
-DKBUILD_BASENAME=KBUILD_STR(mballoc) -DKBUILD_MODNAME=KBUILD_STR(ext4) -c
-o fs/ext4/.tmp_mballoc.o fs/ext4/mballoc.c
The issue:
fs/ext4/mballoc.c: In function 'mb_free_blocks':
fs/ext4/mballoc.c:1459:1: error: insn does not satisfy its constraints:
}
^
(insn 453 831 454 59 (parallel [
(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (mem/c:QI (plus:SI
(reg/f:SI 7 sp)
(const_int 32 [0x20])) [0 %sfp+-20 S1
A32]))
(const_int 1 [0x1])
(and:SI (reg:SI 5 r5)
(const_int 7 [0x7])))
(const_int 0 [0])))
(clobber (scratch:QI))
]) fs/ext4/mballoc.c:1322 113 {*tstsi_variable_bit_qi}
(nil))
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #1 from Chen Gang gang.chen at asianux dot com --- fs/ext4/mballoc.c:1459:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:411 0x8e0a95 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc-4.9.0/gcc/rtl-error.c:109 0x8e0abf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc-4.9.0/gcc/rtl-error.c:120 0x89be7b reload_cse_simplify_operands ../../gcc-4.9.0/gcc/postreload.c:411 0x89da9c reload_cse_simplify ../../gcc-4.9.0/gcc/postreload.c:181 0x89da9c reload_cse_regs_1 ../../gcc-4.9.0/gcc/postreload.c:220 0x89deab reload_cse_regs ../../gcc-4.9.0/gcc/postreload.c:68 0x89deab rest_of_handle_postreload ../../gcc-4.9.0/gcc/postreload.c:2332 0x89deab execute ../../gcc-4.9.0/gcc/postreload.c:2368 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. make[2]: *** [fs/ext4/mballoc.o] Error 1 make[1]: *** [fs/ext4] Error 2 make: *** [fs] Error 2 The gcc information: [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.9.0/lto-wrapper Target: h8300-gchen-elf Configured with: ../gcc-4.9.0/configure --without-header --disable-nls --enable-language=c,c++ --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=h8300-gchen-elf Thread model: single gcc version 4.9.0 20130910 (experimental) (GCC)
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #2 from Chen Gang gang.chen at asianux dot com --- For gcc-4.8.0 and gcc-4.7.4, it has this issue too.
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #3 from Chen Gang gang.chen at asianux dot com --- If no opitimization (without -Os), it will be OK.
[Bug c/58401] New: gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401
Bug ID: 58401
Summary: gcc for h8300 internal compiler error: insn does not
satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c:
In function 'dlm_query_join_handler'
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen at asianux dot com
For Linux kernel next-20130828 version
The related command:
/usr/local/bin/h8300-gchen-elf-gcc -Wp,-MD,fs/ocfs2/dlm/.dlmdomain.o.d
-nostdinc -isystem /usr/local/lib/gcc/h8300-gchen-elf/4.9.0/include
-I/root/linux-next/arch/h8300/include -Iarch/h8300/include/generated -Iinclude
-I/root/linux-next/arch/h8300/include/uapi -Iarch/h8300/include/generated/uapi
-I/root/linux-next/include/uapi -Iinclude/generated/uapi -include
/root/linux-next/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized -mh -mint32
-fno-builtin -g -D__linux__ -DUTS_SYSNAME=\uClinux\ -fno-reorder-blocks
-fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g
-femit-struct-debug-baseonly -fno-var-tracking
-fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -Ifs/ocfs2 -DMODULE
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(dlmdomain)
-DKBUILD_MODNAME=KBUILD_STR(ocfs2_dlm) -c -o fs/ocfs2/dlm/.tmp_dlmdomain.o
fs/ocfs2/dlm/dlmdomain.c
The related issue:
fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler':
fs/ocfs2/dlm/dlmdomain.c:941:1: error: insn does not satisfy its constraints:
}
^
(insn 334 716 335 29 (parallel [
(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (mem/c:QI (plus:SI
(reg/f:SI 7 sp)
(const_int 3 [0x3])) [0 %sfp+-17 S1 A8]))
(const_int 1 [0x1])
(and:SI (reg:SI 1 r1 [+-3 ])
(const_int 7 [0x7])))
(const_int 0 [0])))
(clobber (scratch:QI))
]) fs/ocfs2/dlm/dlmdomain.c:899 113 {*tstsi_variable_bit_qi}
(nil))
fs/ocfs2/dlm/dlmdomain.c:941:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:411
0x8e0a95 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-4.9.0/gcc/rtl-error.c:109
0x8e0abf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-4.9.0/gcc/rtl-error.c:120
0x89be7b reload_cse_simplify_operands
../../gcc-4.9.0/gcc/postreload.c:411
0x89da9c reload_cse_simplify
../../gcc-4.9.0/gcc/postreload.c:181
0x89da9c reload_cse_regs_1
../../gcc-4.9.0/gcc/postreload.c:220
0x89deab reload_cse_regs
../../gcc-4.9.0/gcc/postreload.c:68
0x89deab rest_of_handle_postreload
../../gcc-4.9.0/gcc/postreload.c:2332
0x89deab execute
../../gcc-4.9.0/gcc/postreload.c:2368
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.
make[3]: *** [fs/ocfs2/dlm/dlmdomain.o] Error 1
make[2]: *** [fs/ocfs2/dlm] Error 2
make[1]: *** [fs/ocfs2] Error 2
make: *** [fs] Error 2
The gcc information:
[root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.9.0/lto-wrapper
Target: h8300-gchen-elf
Configured with: ../gcc-4.9.0/configure --without-header --disable-nls
--enable-language=c,c++ --disable-threads --disable-shared --enable-werror=no
target_configargs=enable_vtable_verify=yes --target=h8300-gchen-elf
Thread model: single
gcc version 4.9.0 20130910 (experimental) (GCC)
[Bug c/58401] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401 Chen Gang gang.chen at asianux dot com changed: What|Removed |Added CC||gang.chen at asianux dot com --- Comment #1 from Chen Gang gang.chen at asianux dot com --- If no '-Os', it will have no issue. This bug may duplicate with Bug58400, but I am not quite sure, so send a new bug for it.
[Bug c/58401] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401
--- Comment #2 from Chen Gang gang.chen at asianux dot com ---
Alos for fs/ocfs2/dlm/dlmrecovery.c
/usr/local/bin/h8300-gchen-elf-gcc -Wp,-MD,fs/ocfs2/dlm/.dlmrecovery.o.d
-nostdinc -isystem /usr/local/lib/gcc/h8300-gchen-elf/4.9.0/include
-I/root/linux-next/arch/h8300/include -Iarch/h8300/include/generated -Iinclude
-I/root/linux-next/arch/h8300/include/uapi -Iarch/h8300/include/generated/uapi
-I/root/linux-next/include/uapi -Iinclude/generated/uapi -include
/root/linux-next/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized -mh -mint32
-fno-builtin -g -D__linux__ -DUTS_SYSNAME=\uClinux\ -fno-reorder-blocks
-fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g
-femit-struct-debug-baseonly -fno-var-tracking
-fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -Ifs/ocfs2 -DMODULE
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(dlmrecovery)
-DKBUILD_MODNAME=KBUILD_STR(ocfs2_dlm) -c -o fs/ocfs2/dlm/.tmp_dlmrecovery.o
fs/ocfs2/dlm/dlmrecovery.c
fs/ocfs2/dlm/dlmrecovery.c: In function 'dlm_begin_reco_handler':
fs/ocfs2/dlm/dlmrecovery.c:2769:1: error: insn does not satisfy its
constraints:
}
^
(insn 588 587 589 40 (parallel [
(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (mem/c:QI (plus:SI
(reg/f:SI 7 sp)
(const_int 4 [0x4])) [0 %sfp+-8 S1 A32]))
(const_int 1 [0x1])
(and:SI (reg:SI 3 r3 [orig:125 D.60588+-3 ] [125])
(const_int 7 [0x7])))
(const_int 0 [0])))
(clobber (scratch:QI))
]) fs/ocfs2/dlm/dlmrecovery.c:2748 113 {*tstsi_variable_bit_qi}
(nil))
fs/ocfs2/dlm/dlmrecovery.c:2769:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:411
0x8e0a95 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-4.9.0/gcc/rtl-error.c:109
0x8e0abf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-4.9.0/gcc/rtl-error.c:120
0x89be7b reload_cse_simplify_operands
../../gcc-4.9.0/gcc/postreload.c:411
0x89da9c reload_cse_simplify
../../gcc-4.9.0/gcc/postreload.c:181
0x89da9c reload_cse_regs_1
../../gcc-4.9.0/gcc/postreload.c:220
0x89deab reload_cse_regs
../../gcc-4.9.0/gcc/postreload.c:68
0x89deab rest_of_handle_postreload
../../gcc-4.9.0/gcc/postreload.c:2332
0x89deab execute
../../gcc-4.9.0/gcc/postreload.c:2368
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.
make[3]: *** [fs/ocfs2/dlm/dlmrecovery.o] Error 1
make[2]: *** [fs/ocfs2/dlm] Error 2
make[1]: *** [fs/ocfs2] Error 2
make: *** [fs] Error 2
[Bug c/58401] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401 --- Comment #3 from Chen Gang gang.chen at asianux dot com --- It has too many same issues (maybe they are duplicating), if necessary, I will list them too (non-reply means not need list them).
