[Bug libstdc++/59283] New: missing std::basic_string constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59283 Bug ID: 59283 Summary: missing std::basic_string constructor Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tmmikolajczyk at gmail dot com The C++11 standard specifies the following c-tor in the std::basic_string class: basic_string (const basic_string, const allocator_type); It looks like the c-tor is missing in the current libstdc++ implementation.
[Bug ipa/59282] New: ICE: When compiling 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59282 Bug ID: 59282 Summary: ICE: When compiling 252.eon Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zhenqiang.chen at linaro dot org Created attachment 31288 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31288action=edit preprocessed source file ICE for both x86-64 and ARM. ./install/bin/gcc -O2 ggNRooksSample2.ii -S ooksSample2.cc: In constructor ‘ggNRooksSample2::ggNRooksSample2()’: ggNRooksSample2.cc:41:1: error: stmt (0x7f9491441be0) marked modified after optimization pass: # .MEM_26 = VDEF .MEM_25 ggNRooksSample2::Generate (this_2(D)); ggNRooksSample2.cc:41:1: internal compiler error: verify_ssa failed 0xd129cc verify_ssa(bool) gcc/gcc/tree-ssa.c:1090 0xab8c0e execute_function_todo gcc/gcc/passes.c:1840 0xab9603 execute_todo gcc/gcc/passes.c:1873 0xabb19b execute_one_ipa_transform_pass gcc/gcc/passes.c:2058 0xabb19b execute_all_ipa_transforms() gcc/gcc/passes.c:2089 0x8544ca expand_function gcc/gcc/cgraphunit.c:1750 0x856380 expand_all_functions gcc/gcc/cgraphunit.c:1862 0x856380 compile() gcc/gcc/cgraphunit.c:2196 0x856b64 finalize_compilation_unit() gcc/gcc/cgraphunit.c:2273 0x6424ba cp_write_global_declarations() gcc/gcc/cp/decl2.c:4402 Please submit a full bug report, ./install/bin/gcc -O3 ggNRooksSample2.ii -S ggNRooksSample2.cc: In constructor ‘ggNRooksSample2::ggNRooksSample2()’: ggNRooksSample2.cc:41:1: internal compiler error: in initialize_flags_in_bb, at tree-into-ssa.c:457 0xbcb77d initialize_flags_in_bb gcc/gcc/tree-into-ssa.c:457 0xbcb77d mark_block_for_update gcc/gcc/tree-into-ssa.c:471 0xbcf89b prepare_block_for_update gcc/gcc/tree-into-ssa.c:2500 0xbcff5e prepare_block_for_update gcc/gcc/tree-into-ssa.c:2580 0xbcff5e prepare_block_for_update gcc/gcc/tree-into-ssa.c:2580 0xbcff5e prepare_block_for_update gcc/gcc/tree-into-ssa.c:2580 0xbcff5e prepare_block_for_update gcc/gcc/tree-into-ssa.c:2580 0xbd3655 update_ssa(unsigned int) gcc/gcc/tree-into-ssa.c:3223 0xab8b47 execute_function_todo gcc/gcc/passes.c:1812 0xab9603 execute_todo gcc/gcc/passes.c:1873 0xabb19b execute_one_ipa_transform_pass gcc/gcc/passes.c:2058 0xabb19b execute_all_ipa_transforms() gcc/gcc/passes.c:2089 0x8544ca expand_function gcc/gcc/cgraphunit.c:1750 0x856380 expand_all_functions gcc/gcc/cgraphunit.c:1862 0x856380 compile() gcc/gcc/cgraphunit.c:2196 0x856b64 finalize_compilation_unit() gcc/gcc/cgraphunit.c:2273 0x6424ba cp_write_global_declarations() gcc/gcc/cp/decl2.c:4402 Please submit a full bug report,
[Bug ipa/59282] ICE: When compiling 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59282 --- Comment #1 from zhenqiang.chen at linaro dot org --- ICE from: commit 3af5e0b77894f5348512dfd60c034da9e859ef11 Author: hubicka hubicka@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue Nov 19 10:05:54 2013 + * cgraph.c (cgraph_create_indirect_edge): Use get_polymorphic_call_info. * cgraph.h (cgraph_indirect_call_info): Add outer_type, maybe_in_construction and maybe_derived_type. * ipa-utils.h (ipa_polymorphic_call_context): New structure. (ipa_dummy_polymorphic_call_context): New global var. (possible_polymorphic_call_targets): Add context paramter. (dump_possible_polymorphic_call_targets): Likewise; update wrappers. (possible_polymorphic_call_target_p): Likewise. (get_polymorphic_call_info): New function. * ipa-devirt.c (ipa_dummy_polymorphic_call_context): New function. (add_type_duplicate): Remove forgotten debug output. (method_class_type): Add sanity check. (maybe_record_node): Add FINALP parameter. (record_binfo): Add OUTER_TYPE and OFFSET; walk the inner by info by get_binfo_at_offset. (possible_polymorphic_call_targets_1): Add OUTER_TYPE/OFFSET parameters; pass them to record-binfo. (polymorphic_call_target_d): Add context and FINAL. (polymorphic_call_target_hasher::hash): Hash context. (polymorphic_call_target_hasher::equal): Compare context. (free_polymorphic_call_targets_hash): (get_class_context): New function. (contains_type_p): New function. (get_polymorphic_call_info): New function. (walk_bases): New function. (possible_polymorphic_call_targets): Add context parameter; honnor it. (dump_possible_polymorphic_call_targets): Dump context. (possible_polymorphic_call_target_p): Add context. (update_type_inheritance_graph): Update comment.s (ipa_set_jf_known_type): Assert that compoentn type is known. (ipa_note_param_call): Do not tamper with offsets. (ipa_analyze_indirect_call_uses): When offset is being changed; clear outer type. (update_indirect_edges_after_inlining): Likewise. (ipa_write_indirect_edge_info): Stream new fields. (ipa_read_indirect_edge_info): Stream in new fields. * ipa/devirt9.C: Verify that the optimization happens already before. whole-program. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205019 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug bootstrap/59279] [4.9 Regression] r205337 breaks bootstrap with java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59279 --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org --- OK, thinko on my part: Can't remove the label before a JUMP_TABLE_DATA if we're in cfglayout mode, because: 1. PREV_INSN (label) may be NULL 2. remove_insn doesn't update BB_FOOTER/BB_HEADER I'll re-test the patch with a change to retain the label.
[Bug ipa/59201] [4.9 Regression] error: stmt (0x7f01c4708130) marked modified after optimization pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59201 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||zhenqiang.chen at linaro dot org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 59282 has been marked as a duplicate of this bug. ***
[Bug ipa/59282] ICE: When compiling 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59282 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Dup of PR59201 and PR59208. *** This bug has been marked as a duplicate of bug 59201 ***
[Bug c/59280] [4.8/4.9 Regression] ICE with attribute((constructor(invalid)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59280 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.8.3
[Bug target/59277] x86_64 code generation defects when SSE instructions are disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59277 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Target|X86_64 |x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-25 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- We still have to follow the ABI. Of course I'd say with -mno-sse you should get a fatal_error () whenever you run into an ABI piece that requires SSE registers (instead of silently using them). We may have one or more (near) duplicates of this bug.
[Bug middle-end/59273] [4.9 Regression] ICE in expand_expr_real_2, at expr.c:9188 on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59273 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug c++/59270] [4.9 Regression] [c++11] ICE with decltype of a broken class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59270 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Target Milestone|--- |4.9.0
[Bug c++/59271] [4.9 Regression] a.C:16:21: internal compiler error: in strip_typedefs, at cp/tree.c:1315
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59271 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug c++/59269] [4.9 Regression] ICE with reference in union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59269 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Target Milestone|--- |4.9.0
[Bug c++/59268] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr in a virtual function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59268 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.7.4
[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Component|c++ |ipa Target Milestone|--- |4.9.0 Summary|Segmentation fault in |[4.9 Regression] |ipa_note_param_call for |Segmentation fault in |-fprofile-use in SPEC |ipa_note_param_call for |CPU2006 |-fprofile-use in SPEC ||CPU2006
[Bug middle-end/59261] [4.9 regression] FAIL: gcc.dg/vect/bb-slp-26.c -flto -ffat-lto-objects (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59261 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/59262] __attribute__ ((optimize())) broken (and corrupts optimization of the whole compilation unit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59262 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- More specifically we cannot inline across changes of -ffast-math as that would generate wrong-code. Thus the non-fast-math 'sum' cannot be inlined into a fast-math annotated function. Which then of course defeats vectorization. Generally I'd advise against using the optimize attribute.
[Bug bootstrap/59260] [4.9 Regression] fold-const.c:14871:5: error: 'hash_table' has not been declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59260 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|fold-const.c:14871:5: |[4.9 Regression] |error: 'hash_table' has not |fold-const.c:14871:5: |been declared |error: 'hash_table' has not ||been declared
[Bug c++/59080] [4.9 Regression] [c++11] ICE with array of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59080 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Nov 25 09:29:18 2013 New Revision: 205344 URL: http://gcc.gnu.org/viewcvs?rev=205344root=gccview=rev Log: /cp 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/59080 * pt.c (unify): Don't call unify_array_domain with a NULL_TREE third argument. PR c++/59096 * pt.c (apply_late_template_attributes): Check that TREE_VALUE isn't NULL_TREE in the attribute_takes_identifier_p case. /testsuite 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/59080 * g++.dg/cpp0x/initlist75.C: New. PR c++/59096 * g++.dg/cpp0x/gen-attrs-57.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-57.C trunk/gcc/testsuite/g++.dg/cpp0x/initlist75.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59096] [4.9 Regression] [c++11] ICE with template attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59096 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Nov 25 09:29:18 2013 New Revision: 205344 URL: http://gcc.gnu.org/viewcvs?rev=205344root=gccview=rev Log: /cp 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/59080 * pt.c (unify): Don't call unify_array_domain with a NULL_TREE third argument. PR c++/59096 * pt.c (apply_late_template_attributes): Check that TREE_VALUE isn't NULL_TREE in the attribute_takes_identifier_p case. /testsuite 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/59080 * g++.dg/cpp0x/initlist75.C: New. PR c++/59096 * g++.dg/cpp0x/gen-attrs-57.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-57.C trunk/gcc/testsuite/g++.dg/cpp0x/initlist75.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59080] [4.9 Regression] [c++11] ICE with array of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59080 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug c/59219] ____builtin___memcpy_chk and -fno-builtin-memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59219 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Martin Sebor from comment #4) I understand. The current semantics of __builtin__xxx_chk are to: a) check the constraints of the xxx function at compile time, and b) diagnose constraint violations detected in (a) and call __xxx_chk, or c) expand xxx inline if constraints are satisfied c) isn't correct - the rule is that __xxx_chk is either expanded to a call to __builtin_xxx or to a call to __xxx_chk. __builtin_xxx is then either expanded inline or as a call to xxx dependent on cost and flags. I'm suggesting that it would be useful to change the semantics in (c): c) if constraints are satisfied, then if -fbuiltin is used, expand xxx inline, or d) if -fno-builtin is used, call xxx I think you are asking that __builtin_xxx_chk should expand to __xxx_chk or xxx (instead of __builtin_xxx). I.e., reduce the effects of the __builtin__xxx_chk intrinsics to just checking the constraints, and (when -fno-builtin is used) make it possible to customize the implementation within those constraints. This would let freestanding implementations use the __builtin__xxx_chk intrinsics and also provide their own semantics for the xxx functions within the constraints specified by the language. A target independent flag that controls inline expansion of xxx would be more useful I think. You can use -mstringop-strategy=libcall on x86. (PS I belatedly realized that my mention of a freestanding sprintf using '$' to introduce a freestanding format directive didn't make sense as it would violate the function's constraint. Please diregard that part.)
[Bug c++/59096] [4.9 Regression] [c++11] ICE with template attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59096 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug c++/59255] [4.8/4.9 Regression] Segmentation fault with std::function and -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-25 Known to work||4.7.3 Target Milestone|--- |4.8.3 Summary|Segmentation fault with |[4.8/4.9 Regression] |std::function and |Segmentation fault with |-fprofile-use |std::function and ||-fprofile-use Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug fortran/59143] [OOP] Bogus warning with array-valued type-bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59143 --- Comment #5 from janus at gcc dot gnu.org --- Author: janus Date: Mon Nov 25 09:45:40 2013 New Revision: 205345 URL: http://gcc.gnu.org/viewcvs?rev=205345root=gccview=rev Log: 2013-11-25 Janus Weil ja...@gcc.gnu.org PR fortran/59143 * interface.c (get_expr_storage_size): Handle array-valued type-bound procedures. 2013-11-25 Janus Weil ja...@gcc.gnu.org PR fortran/59143 * gfortran.dg/typebound_proc_30.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_proc_30.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/59143] [OOP] Bogus warning with array-valued type-bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59143 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from janus at gcc dot gnu.org --- Fixed with r205345. Closing. Thanks for the report!
[Bug sanitizer/59258] usan: ICE(segfault): stack-buffer-overflow with -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59258 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Nov 25 10:46:20 2013 New Revision: 205347 URL: http://gcc.gnu.org/viewcvs?rev=205347root=gccview=rev Log: 2013-11-25 Marek Polacek pola...@redhat.com * ubsan.c (ubsan_create_data): Increase the size of the fields array. Modified: trunk/gcc/ChangeLog trunk/gcc/ubsan.c
[Bug c++/59284] New: missing diagnostic on incomplete type at the point of template definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59284
Bug ID: 59284
Summary: missing diagnostic on incomplete type at the point of
template definition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
According to [temp.res]p8 this code is invalid, but gcc don't show error on it:
struct x;
template typename T
void f()
{
x x;
}
If a type used in a non-dependent name is incomplete at the point at which a
template is defined but is complete at the point at which an instantiation is
done, and if the completeness of that type affects whether or not the program
is well-formed or affects the semantics of the program, the program is
ill-formed; no diagnostic is required.
clang gives error:
19.cpp:7:7: error: variable has incomplete type 'x'
x x;
^
19.cpp:2:8: note: forward declaration of 'x'
struct x;
^
1 error generated.
[Bug sanitizer/59250] ubsan: ICE (segfault) with -fsanitize=undefined in ubsan_create_data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59250 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Nov 25 11:17:23 2013 New Revision: 205349 URL: http://gcc.gnu.org/viewcvs?rev=205349root=gccview=rev Log: 2013-11-25 Marek Polacek pola...@redhat.com testsuite/ * g++.dg/ubsan/pr59250.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr59250.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/59250] ubsan: ICE (segfault) with -fsanitize=undefined in ubsan_create_data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59250 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug middle-end/59285] New: gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 Bug ID: 59285 Summary: gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org The gcc.dg/builtin-unreachable-6.c testcase fails on arm-none-eabi with: $SRC/gcc/gcc/testsuite/gcc.dg/builtin-unreachable-6.c: In function 'foo': $SRC/gcc/gcc/testsuite/gcc.dg/builtin-unreachable-6.c:17:1: error: verify_flow_info: Incorrect fallthru 2-5 $SRC/gcc/gcc/testsuite/gcc.dg/builtin-unreachable-6.c:17:1: error: wrong insn in the fallthru edge (barrier 21 20 27) $SRC/gcc/gcc/testsuite/gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862 0x95d645 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) $SRC/gcc/gcc/rtl-error.c:109 0x69254a rtl_verify_fallthru $SRC/gcc/gcc/cfgrtl.c:2862 0x69254a rtl_verify_flow_info $SRC/gcc/gcc/cfgrtl.c:2962 0x681af7 verify_flow_info() $SRC/gcc/gcc/cfghooks.c:258 0xe5c24f if_convert $SRC/gcc/gcc/ifcvt.c:4460 0xe5d95d rest_of_handle_if_after_reload $SRC/gcc/gcc/ifcvt.c:4594 0xe5d95d execute $SRC/gcc/gcc/ifcvt.c:4625 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. Bisection shows it started with r205074: * tree-ssa-threadedge.c (thread_across_edge): After threading through a joiner, allow threading a normal block requiring duplication. * tree-ssa-threadupdate.c (thread_block_1): Improve code to detect jump threading requests that would muck up the loop structures.
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 --- Comment #5 from Akim Demaille akim.demaille at gmail dot com --- Happy two-year birthday, bug! Sorry I'm (slightly more that) off-by-one.
[Bug libstdc++/59283] missing std::basic_string constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59283 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- This is a known issue. Our std::string does not support the C++11 allocator requirements, and the current implementation probably never will. When we switch to a non-Copy-On-Write std::string it will include C++11 allocator support.
[Bug target/12306] GOT pointer (r12) reloaded unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12306 chrbr at gcc dot gnu.org changed: What|Removed |Added CC||chrbr at gcc dot gnu.org --- Comment #5 from chrbr at gcc dot gnu.org --- needs it. If we knew that that pic function can't be called from any non-pic functions by some additional information, we could optimize the code with removing that saverestore r12. or from a pic function from the same module. using visibility protected perhaps ?
[Bug middle-end/51982] Shrink-wrapping opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51982 Bug 51982 depends on bug 10474, which changed state. Bug 10474 Summary: shrink wrapping for functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/10474] shrink wrapping for functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana.r at gmail dot com Resolution|--- |FIXED --- Comment #17 from Martin Jambor jamborm at gcc dot gnu.org --- The testcase is now shrink-wrapped on ppc64 and x86_64, it is not on others such as i?86 because parameter-passing ABI basically prevents it. If any of the three testcases pass also on any other platform (e.g. Ramana claimed it also works on AArch32 [1]), feel free to add it to the dg target in the testcase(s). For my part, I now consider this to be fixed. [1] http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02726.html
[Bug bootstrap/59260] [4.9 Regression] fold-const.c:14871:5: error: 'hash_table' has not been declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59260 --- Comment #3 from Andrew Macleod amacleod at redhat dot com --- Author: amacleod Date: Mon Nov 25 13:23:09 2013 New Revision: 205352 URL: http://gcc.gnu.org/viewcvs?rev=205352root=gccview=rev Log: PR bootstrap/59260 * fold-const.c: Include hash-table.h. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug rtl-optimization/58934] [4.9 Regression]: build fails on cris-elf in reload_cse_simplify_operands for newlib dtoa.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934 --- Comment #14 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #12) FAIL: gfortran.fortran-torture/execute/pr32604.f90 execution, -O2 -fbounds-check I did not find this failure in your latest test results (http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01857.html) and so I assume it has been also fixed by any of the subsequent patches addressing other issues.
[Bug rtl-optimization/10474] shrink wrapping for functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474 --- Comment #18 from Ryan Johnson scovich at gmail dot com --- (In reply to Martin Jambor from comment #17) The testcase is now shrink-wrapped on ppc64 and x86_64, it is not on others such as i?86 because parameter-passing ABI basically prevents it. If any of the three testcases pass also on any other platform (e.g. Ramana claimed it also works on AArch32 [1]), feel free to add it to the dg target in the testcase(s). For my part, I now consider this to be fixed. [1] http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02726.html Great! Does this mean shrink-wrapping will be in gcc-4.9, at least for x86_64 and ppc64?
[Bug rtl-optimization/58934] [4.9 Regression]: build fails on cris-elf in reload_cse_simplify_operands for newlib dtoa.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #14 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #12) FAIL: gfortran.fortran-torture/execute/pr32604.f90 execution, -O2 -fbounds-check I did not find this failure in your latest test results (http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01857.html) and so I assume it has been also fixed by any of the subsequent patches addressing other issues. Right, it's gone in this weekend's bootstraps. Rainer
[Bug tree-optimization/59249] if-conversion doesn't handle basic-blocks with only critical predecessor edges
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59249 --- Comment #3 from Bingfeng Mei bmei at broadcom dot com --- Richard, I am not sure I understand about how to split edge. BB4 / \ / \ BB5| |\| | \ | | \ | | BB6 | / | / BB7 Compiler (HEAD) complains only critical predecessors of BB6 (its predcessor BB5 has more than one successor). Do you suggest to split edge between BB5 BB6 and insert an empty BB? In the email thread, you blame poor implementation of tree-level if-conversion. But RTL-level CE passes cannot handle that too.
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #38 from Sergey Matveev earthdok at google dot com --- (In reply to Jakub Jelinek from comment #28) Author: jakub Date: Fri Nov 22 21:13:08 2013 New Revision: 205290 It looks like you use dynamic linking by default. The last time I checked, leak detection (in both ASan and standalone LSan) didn't work 100% correctly with dynamic linking. Should be easy to fix by giving one of the interceptors a stronger visibility.
[Bug rtl-optimization/10474] shrink wrapping for functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474 --- Comment #19 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Ryan Johnson from comment #18) Great! Does this mean shrink-wrapping will be in gcc-4.9, at least for x86_64 and ppc64? Well, a fairly basic (but not altogether unreasonable) shrink-wrapping was in gcc 4.8 (and earlier versions) too and that has not changed at all. The problem with this and similar testcases was that the register allocator made decisions which made shrink-wrapping impossible (or at least too difficult to perform). The change I committed and which will be a part of gcc 4.9 fixes this for a class of pseudo-registers which commonly result in this problem but other cases will still remain unresolved, for example PR 51982. For some statistics about what impact the implemented technique has, see the email accompanying the first submission of the patch: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01719.html If you find another similar example which is important and clearly possible to shrink-wrap but we don't do it, feel free to submit a new missed-optimization bug and CC me.
[Bug sanitizer/59286] New: segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
Bug ID: 59286
Summary: segfault in __sanitizer::StackDepotGet
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Running our tsan instrumented code, I'm seeing a segfault in tsan. I have no
suitable testcase for this yet (short of building CP2K), so I'm posting the
backtrace here in case this rings a bell / triggers some suggestions on what
might be going on. I'll try to do some further testing.
Program received signal SIGSEGV, Segmentation fault.
0x74a27428 in __sanitizer::StackDepotGet (id=8388952,
size=0x7ffcb8f8) at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:192
192 if (s-id == id) {
(gdb) bt
#0 0x74a27428 in __sanitizer::StackDepotGet (id=8388952,
size=0x7ffcb8f8) at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:192
#1 0x74a1d9de in __tsan::ScopedReport::AddLocation (this=0x800158,
this@entry=0x7ffcb9f0, addr=140737488140536, addr@entry=137748196274048,
size=140737321271672,
size@entry=8) at ../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:339
#2 0x74a1ed30 in __tsan::ReportRace (thr=optimized out) at
../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:697
#3 0x74a21e02 in __tsan_report_race_thunk () at
../../../../gcc/libsanitizer/tsan/tsan_rtl_amd64.S:122
#4 0x749ef9c8 in HandleRace (old=..., cur=..., shadow_mem=optimized
out, thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:376
#5 MemoryAccessImpl (cur=..., shadow_mem=optimized out, kIsAtomic=optimized
out, kAccessIsWrite=optimized out, kAccessSizeLog=optimized out,
addr=optimized out,
thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:460
#6 __tsan::MemoryAccess (thr=0x761f2780, pc=496049752, addr=82100428376,
kAccessSizeLog=8, kAccessIsWrite=true, kIsAtomic=true)
at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:531
#7 0x767e62c0 in timings::timeset (routinen=error reading variable:
Cannot access memory at address 0x3fe13824d8597625,
handle=error reading variable: Cannot access memory at address
0x3fe13824d8597005, _routinen=optimized out) at
/data/vjoost/clean/cp2k/cp2k/src/../src/timings.F:254
(gdb) print s
$1 = (__sanitizer::StackDesc *) 0x4d634810890c558b
(gdb) print s-id
Cannot access memory at address 0x4d634810890c5593
(gdb) print id
$2 = 8388952
(gdb) list
187CHECK_LT(idx, kTabSize);
188atomic_uintptr_t *p = depot.tab[idx];
189uptr v = atomic_load(p, memory_order_consume);
190StackDesc *s = (StackDesc*)(v ~1);
191for (; s; s = s-link) {
192 if (s-id == id) {
193*size = s-size;
194return s-stack;
195 }
196}
(gdb) print idx
$3 = 4476
(gdb) print kTabSize
$5 = 1048576
(gdb) print depot.tab[idx]
$6 = {val_dont_use = 140737321271672}
(gdb) print depot
[Bug tree-optimization/59287] New: points-to analysis confused by union accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59287
Bug ID: 59287
Summary: points-to analysis confused by union accesses
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
static void
get_constraint_for_component_ref (tree t, vecce_s *results,
bool address_p, bool lhs_p)
{
...
/* Handle type-punning through unions. If we are extracting a pointer
from a union via a possibly type-punning access that pointer
points to anything, similar to a conversion of an integer to
a pointer. */
if (!lhs_p)
{
tree u;
for (u = t;
TREE_CODE (u) == COMPONENT_REF || TREE_CODE (u) == ARRAY_REF;
u = TREE_OPERAND (u, 0))
if (TREE_CODE (u) == COMPONENT_REF
TREE_CODE (TREE_TYPE (TREE_OPERAND (u, 0))) == UNION_TYPE)
{
struct constraint_expr temp;
temp.offset = 0;
temp.var = anything_id;
temp.type = ADDRESSOF;
results-safe_push (temp);
return;
}
}
has the adverse affect that if you have code like
foo (TREE_CODE (t))
then it makes ANYTHING escape ... which is the worst thing that can happen.
The above shouldn't be necessary.
[Bug tree-optimization/59288] New: [4.7/4.8/4.9 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59288 Bug ID: 59288 Summary: [4.7/4.8/4.9 Regression Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org
[Bug tree-optimization/59288] [4.7/4.8/4.9 Regression] ICE in get_initial_def_for_induction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59288
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.4
Summary|[4.7/4.8/4.9 Regression |[4.7/4.8/4.9 Regression]
||ICE in
||get_initial_def_for_inducti
||on
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
void
baz (int *d)
{
long int i, j, k;
for (i = 0, j = 0, k = 0; i 512; i = (int) i + 1, j = (int) j + 1, k =
(int) k + 3)
d[i] = j ^ (i * 3) ^ (2 * k + 2);
}
ICEs at -O3 with:
internal compiler error: in get_initial_def_for_induction, at
tree-vect-loop.c:3257
baz (int *d)
^
0xd581c4 get_initial_def_for_induction
../../gcc/tree-vect-loop.c:3257
0xd5df87 vectorizable_induction(gimple_statement_base*,
gimple_stmt_iterator_d*, gimple_statement_base**)
../../gcc/tree-vect-loop.c:5438
0xd4b7c0 vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator_d*,
bool*, _slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.c:6507
0xd5f0cc vect_transform_loop(_loop_vec_info*)
../../gcc/tree-vect-loop.c:5847
0xd732d3 vectorize_loops()
../../gcc/tree-vectorizer.c:379
0xc86812 tree_loop_vectorize
../../gcc/tree-ssa-loop.c:154
0xc8689c execute
../../gcc/tree-ssa-loop.c:189
[Bug tree-optimization/59288] [4.7/4.8/4.9 Regression] ICE in get_initial_def_for_induction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59288 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-25 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|gcc.dg/builtin-unreachable- |[4.9 Regression] |6.c:17:1: internal compiler |gcc.dg/builtin-unreachable- |error: in |6.c:17:1: internal compiler |rtl_verify_fallthru, at |error: in |cfgrtl.c:2862 |rtl_verify_fallthru, at ||cfgrtl.c:2862
[Bug rtl-optimization/10474] shrink wrapping for functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474 --- Comment #20 from Ryan Johnson scovich at gmail dot com --- Hi Martin, (PM reply because I don't have up-to-date information to file a proper bug report with) On 25/11/2013 9:57 AM, jamborm at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474 --- Comment #19 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Ryan Johnson from comment #18) Great! Does this mean shrink-wrapping will be in gcc-4.9, at least for x86_64 and ppc64? Well, a fairly basic (but not altogether unreasonable) shrink-wrapping was in gcc 4.8 (and earlier versions) too and that has not changed at all. The problem with this and similar testcases was that the register allocator made decisions which made shrink-wrapping impossible (or at least too difficult to perform). The change I committed and which will be a part of gcc 4.9 fixes this for a class of pseudo-registers which commonly result in this problem but other cases will still remain unresolved, for example PR 51982. For some statistics about what impact the implemented technique has, see the email accompanying the first submission of the patch: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01719.html If you find another similar example which is important and clearly possible to shrink-wrap but we don't do it, feel free to submit a new missed-optimization bug and CC me. One that comes to mind right off, but is from several years ago and possibly no longer true: on platforms like solaris/sparc, accesses to thread-local storage require a function call to retrieve the base of thread-local storage; the compiler seems to emit the call once, in the function prologue. I strongly suspect (but can't confirm, since I no longer have access to Solaris/sparc) that such a function-call-in-prologue would confound subsequent efforts at shrink wrapping. I don't know how often this sort of scenario arises any more, though. It may be that the new emutls stuff has changed everything, because on cygwin and gcc-4.8 I now see separate calls into emutls for every TLS access. As for PR 51982, it looks like having flow-sensitive local analysis could go a long way: just as it can be useful know that an escaped pointer has not *yet* escaped (e.g. PR 50346), here it would be useful to know that the stack frame, though perhaps eventually needed, is not needed just yet. Then, generation of the stack frame can be pushed down to the first basic block(s) where the need for a stack frame is undisputed, after any conditions that gate it. But I've been told that teaching gcc to think that way would not be easy... In any case, thanks for the improvement to a hairy problem. Regards, Ryan
[Bug target/59289] New: [ARM] regression on unsigned-extend-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59289 Bug ID: 59289 Summary: [ARM] regression on unsigned-extend-2.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Since commit 203160 (New rtx costs infrastructure for ARM), I have noticed that gcc.target/arm/unsigned-extend-2.c scan-assembler ands gcc.target/arm/unsigned-extend-2.c scan-assembler-not cmp now FAIL (used to PASS). I have configured GCC as: target: arm-none-linux-gnueabihf mode: thumb cpu: cortex-a15 fpu: neon-vfpv4 With r203159: movsr3, #8 .L3: lsrsr0, r0, #1 subsr3, r3, #1 andsr3, r3, #255 bne.L3 bxlr with r203160: movsr3, #0 .L3: lsrsr0, r0, #1 addsr3, r3, #1 cmpr3, #8 bne.L3 bxlr It seems that code gen has slightly evolved in trunk since r203160, but the test still fails. The code sequence does not seem really worse than the original one, but the testcase should at least be updated.
[Bug sanitizer/59258] ubsan: ICE(segfault): stack-buffer-overflow with -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59258 --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Marek Polacek from comment #6) Seems like we're passing bogus location. Can you e-mail me the unreduced testcase? I'll look into it. The unreduced testcase doesn't fail with -gstrict-dwarf.
[Bug c++/58810] [4.7/4.8/4.9 Regression] ICE with invalid function typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58810 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Nov 25 16:10:29 2013 New Revision: 205356 URL: http://gcc.gnu.org/viewcvs?rev=205356root=gccview=rev Log: /cp 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/58810 * decl.c (grokdeclarator): Don't handle qualified free functions here, leave the diagnostic to grokfndecl. /testsuite 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/58810 * g++.dg/other/cv_func3.C: New. * g++.dg/other/cv_func.C: Adjust. * g++.dg/parse/fn-typedef2.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/other/cv_func3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/cv_func.C trunk/gcc/testsuite/g++.dg/parse/fn-typedef2.C
[Bug c++/58810] [4.7/4.8 Regression] ICE with invalid function typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58810 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.7.4 |4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] ICE |ICE with invalid function |with invalid function |typedef |typedef --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot com --- Isn't this the issue fixed by 2012-06-29 Andreas Schwab sch...@linux-m68k.org * copying-lib.texi (Library Copying): Don't use @heading inside @enumerate. (which I more recently backported to 4.7 branch when I encountered it there)?
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-25 Ever confirmed|0 |1
[Bug target/12306] GOT pointer (r12) reloaded unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12306 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- Maybe something like function multi-versioning could be used for that? When compiling as PIC, each function would be output twice. Once with the assumption that it can be called from non-PIC functions and once with the assumption that it can't. So we'll have one function that does the r12 stuff and another that doesn't. Then the linker could figure it out by e.g. dead code stripping, and maybe also taking into account the visibility. In the worst case, if the linker can't make a decision, it should leave the with-r12-stuff version.
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #14 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Mon, Nov 25, 2013 at 04:15:53PM +, joseph at codesourcery dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot com --- Isn't this the issue fixed by 2012-06-29 Andreas Schwab sch...@linux-m68k.org * copying-lib.texi (Library Copying): Don't use @heading inside @enumerate. (which I more recently backported to 4.7 branch when I encountered it there)? Don't know. Don't care. I'm cleaning up old PRs and those that I'm cc'd on before I ask overseer@ to disable my account, svn access, and bugzilla access.
[Bug target/59290] New: [ARM] regression on negdi-2.c (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290 Bug ID: 59290 Summary: [ARM] regression on negdi-2.c (big-endian) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Since commit 203828 (new cortexa9_extra_costs table), I have noticed a regression on: gcc.target/arm/negdi-2.c scan-assembler-times mov 1 in big-endian targets: armeb-none-linux-gnueabihf mode: arm or thumb cpu=cortex-a9 fpu=neon-fp16 The preceding test in the same testcase (scan-assembler-times negs\\tr0, r0 1) FAILs too, but it was already the case before that commit. The testcase might need to be adapted to cope with big-endian targets.
[Bug target/53976] [SH] Unnecessary clrt after bt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976 --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Mon Nov 25 16:47:16 2013 New Revision: 205358 URL: http://gcc.gnu.org/viewcvs?rev=205358root=gccview=rev Log: PR target/53976 PR target/59243 * config/sh/sh_optimize_sett_clrt.cc (struct ccreg_value): Update comments. (sh_optimize_sett_clrt::find_last_ccreg_values): Check stack of previously visited basic blocks before recursing instead of only one basic block. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh_optimize_sett_clrt.cc
[Bug target/59243] [SH] Build fails during compiling libjava/interpret.cc with segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59243 --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Mon Nov 25 16:47:16 2013 New Revision: 205358 URL: http://gcc.gnu.org/viewcvs?rev=205358root=gccview=rev Log: PR target/53976 PR target/59243 * config/sh/sh_optimize_sett_clrt.cc (struct ccreg_value): Update comments. (sh_optimize_sett_clrt::find_last_ccreg_values): Check stack of previously visited basic blocks before recursing instead of only one basic block. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh_optimize_sett_clrt.cc
[Bug target/59243] [SH] Build fails during compiling libjava/interpret.cc with segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59243 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org --- Fixed.
[Bug target/59277] x86_64 code generation defects when SSE instructions are disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59277 --- Comment #4 from Aaron Myles Landwehr aron at udel dot edu --- That is completely fair. Correct me if I'm wrong here, but that also means that any code that passes doubles as arguments should also get fatal_error() instead of dropping arguments to the stack as is currently done.
[Bug target/54019] [SH] Tail calls with -fPIC use bsrf instead of braf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54019 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #2) Confirmed. Assuming my theories in comment #1 are correct, I guess to fix/improve this it would require similar mechanisms as mentioned in PR 12306
[Bug target/59290] [4.9 regression][ARM] regression on negdi-2.c (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-25 Version|unknown |4.9.0 Summary|[ARM] regression on |[4.9 regression][ARM] |negdi-2.c (big-endian) |regression on negdi-2.c ||(big-endian) Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Generating 2 mov instructions with the new cost tables. This is a code quality regression
[Bug target/59290] [4.9 regression][ARM] regression on negdi-2.c (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290 --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- The tests do need fixing for big-endian, though, since the rsb operation should write r1 in big-endian and r0 in little-endian.
[Bug bootstrap/59260] [4.9 Regression] fold-const.c:14871:5: error: 'hash_table' has not been declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59260 Dmitry G. Dyachenko dimhen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dmitry G. Dyachenko dimhen at gmail dot com --- fixed in r205352
[Bug target/59291] New: [SH] Group T bit related isnsn before combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59291
Bug ID: 59291
Summary: [SH] Group T bit related isnsn before combine
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The following example function
struct result
{
int a, b;
};
result test2 (int a, int b, int d)
{
result r;
r.a = a == b;
r.b = d + b + 1;
return r;
};
compiled with -O2 -m4 -ml results in
cmp/eq r5,r4
add r5,r6
mov r6,r1
movtr0
rts
add #1,r1 missed addc combine opportunity.
Initially the function is expanded to...
(notice the eq:SI that sets the T_REG and the movt that stores the comparison
result are next to each other)
(note 1 0 6 NOTE_INSN_DELETED)
(note 6 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 6 3 2 (set (reg/v:SI 166 [ a ])
(reg:SI 4 r4 [ a ])) sh_tmp.cpp:7 -1
(nil))
(insn 3 2 4 2 (set (reg/v:SI 167 [ b ])
(reg:SI 5 r5 [ b ])) sh_tmp.cpp:7 -1
(nil))
(insn 4 3 5 2 (set (reg/v:SI 168 [ d ])
(reg:SI 6 r6 [ d ])) sh_tmp.cpp:7 -1
(nil))
(note 5 4 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 5 9 2 (set (reg:SI 147 t)
(eq:SI (reg/v:SI 166 [ a ])
(reg/v:SI 167 [ b ]))) sh_tmp.cpp:9 -1
(nil))
(insn 9 8 10 2 (set (reg:SI 170 [ D.1945 ])
(reg:SI 147 t)) sh_tmp.cpp:9 -1
(nil))
(insn 10 9 11 2 (set (subreg:SI (reg:DI 164 [ D.1936 ]) 0)
(reg:SI 170 [ D.1945 ])) sh_tmp.cpp:11 -1
(nil))
(insn 11 10 12 2 (set (reg:SI 171 [ D.1946 ])
(plus:SI (reg/v:SI 168 [ d ])
(reg/v:SI 167 [ b ]))) sh_tmp.cpp:10 -1
(nil))
(insn 12 11 13 2 (set (reg:SI 172 [ D.1946 ])
(plus:SI (reg:SI 171 [ D.1946 ])
(const_int 1 [0x1]))) sh_tmp.cpp:10 -1
(nil))
(insn 13 12 14 2 (set (subreg:SI (reg:DI 164 [ D.1936 ]) 4)
(reg:SI 172 [ D.1946 ])) sh_tmp.cpp:11 -1
(nil))
(insn 14 13 18 2 (set (reg:DI 165 [ retval ])
(reg:DI 164 [ D.1936 ])) sh_tmp.cpp:11 -1
(nil))
(insn 18 14 21 2 (set (reg/i:DI 0 r0)
(reg:DI 165 [ retval ])) sh_tmp.cpp:12 -1
(nil))
(insn 21 18 0 2 (use (reg/i:DI 0 r0)) sh_tmp.cpp:12 -1
(nil))
The fwprop1 pass however, changes this to...
;;total ref usage 48{26d,22u,0e} in 9{9 regular + 0 call} insns.
(note 6 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 6 3 2 (set (reg/v:SI 166 [ a ])
(reg:SI 4 r4 [ a ])) sh_tmp.cpp:7 257 {movsi_ie}
(expr_list:REG_DEAD (reg:SI 4 r4 [ a ])
(nil)))
(insn 3 2 4 2 (set (reg/v:SI 167 [ b ])
(reg:SI 5 r5 [ b ])) sh_tmp.cpp:7 257 {movsi_ie}
(expr_list:REG_DEAD (reg:SI 5 r5 [ b ])
(nil)))
(insn 4 3 5 2 (set (reg/v:SI 168 [ d ])
(reg:SI 6 r6 [ d ])) sh_tmp.cpp:7 257 {movsi_ie}
(expr_list:REG_DEAD (reg:SI 6 r6 [ d ])
(nil)))
(note 5 4 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 5 11 2 (set (reg:SI 147 t)
(eq:SI (reg/v:SI 166 [ a ])
(reg/v:SI 167 [ b ]))) sh_tmp.cpp:9 17 {cmpeqsi_t}
(expr_list:REG_DEAD (reg/v:SI 166 [ a ])
(nil)))
(insn 11 8 12 2 (set (reg:SI 171 [ D.1946 ])
(plus:SI (reg/v:SI 168 [ d ])
(reg/v:SI 167 [ b ]))) sh_tmp.cpp:10 75 {*addsi3_compact}
(expr_list:REG_DEAD (reg/v:SI 168 [ d ])
(expr_list:REG_DEAD (reg/v:SI 167 [ b ])
(nil
(insn 12 11 26 2 (set (reg:SI 172 [ D.1946 ])
(plus:SI (reg:SI 171 [ D.1946 ])
(const_int 1 [0x1]))) sh_tmp.cpp:10 75 {*addsi3_compact}
(expr_list:REG_DEAD (reg:SI 171 [ D.1946 ])
(nil)))
(insn 26 12 27 2 (set (reg:SI 0 r0)
(reg:SI 147 t)) sh_tmp.cpp:12 399 {movt}
(expr_list:REG_DEAD (reg:SI 147 t)
(nil)))
(insn 27 26 21 2 (set (reg:SI 1 r1 [+4 ])
(reg:SI 172 [ D.1946 ])) sh_tmp.cpp:12 257 {movsi_ie}
(expr_list:REG_DEAD (reg:SI 172 [ D.1946 ])
(nil)))
(insn 21 27 0 2 (use (reg/i:DI 0 r0)) sh_tmp.cpp:12 -1
(nil))
... which makes the T_REG live across the addsi insns and thus combine will
fail to replace them with an addc insn which clobbers the T_REG.
Insns that use the T_REG (the movt insn in this case) should be reordered in
such a way that they immediately follow the insn that sets the T_REG (the
cmpeqsi insn in this case) before combine. This would increase the probability
of combine successes.
However, there could be some unlucky cases. If the movt destination is 'r0' as
above, and it is moved above other insns which might clobber/need the r0 reg
(e.g. tst #imm, logical #imm ops etc), there could be reload problems or the
code might get worse for such sequences.
[Bug target/59290] [4.9 regression][ARM] regression on negdi-2.c (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59290 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||ktkachov at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- Mine, got a patch in testing.
[Bug c/16351] NULL dereference warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #15 from Jeffrey A. Law law at redhat dot com --- I expect it will be in GCC 4.9. It's a wrap-up item for -fisolate-erroneous-paths.
[Bug rtl-optimization/58033] counterproductive bb-reorder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
Another somewhat related SH example, compiled with -m4 -O2 -ml on rev 205313:
int
foo1 (long long value)
{
const long long constant = 0xc0008000LL;
if (value constant)
return 1;
else
return 2;
}
mov.l .L12,r1
cmp/ge r1,r5
bt/s.L10 should branch to L10
cmp/gt r1,r5
mov #1,r0
.L6:
rts
nop
.align 1
.L10:
bf .L11 never branches, always falls through
.L5:
rts
mov#2,r0
.align 1
.L11:
mov.l .L13,r1
cmp/hs r1,r4
bt .L5
mov #1,r0
bra .L6 could just duplicate BB from L6 here
nop (see also PR 58615)
[Bug sanitizer/59258] ubsan: ICE(segfault): stack-buffer-overflow with -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59258 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31289 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31289action=edit gcc49-pr59258.patch Untested fix for the dwarf2out.c ICE. The problem is that -fsanitize=null will preserve in location_t of ADDR_EXPR a reference to a block, but the BLOCK isn't referenced from anywhere else and thus during ggc_collect removed as unused, then dwarf2out.c allocates the same GC memory for something else and finally when processing the ADDR_EXPR the old BLOCK is modified again. Either of the hunks in the patch should fix this, IMHO we want both, it doesn't make sense to provide any locus for the ADDR_EXPR of the string in the static ctor, and as ubsan_create_data compares loc to UNKNOWN_LOCATION in a bunch of places, not doing LOCATION_LOCUS there means it might not compare to UNKNOWN_LOCATION even when it actually is UNKNOWN_LOCATION just with some non-NULL associated block. Perhaps my * ubsan.c (ubsan_source_location): Don't crash on unknown locations. change will be unneeded now?
[Bug c++/59292] New: Spurious warning: ‘anonymous’ is used uninitialized in this function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59292 Bug ID: 59292 Summary: Spurious warning: ‘anonymous’ is used uninitialized in this function Product: gcc Version: 4.4.7 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bluesmissionnaire at gmail dot com Created attachment 31290 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31290action=edit /usr/bin/g++-4.4 -Wall -Wextra -save-temps -c -O1 anonymous_may_be_used_uninitialized.cpp Using g++-4.4 (GCC) 4.4.7 20120313 (Red Hat 4.4.7-1) /usr/bin/g++-4.4 -Wall -Wextra -save-temps -c -O1 anonymous_may_be_used_uninitialized.cpp warns: anonymous_may_be_used_uninitialized.cpp: In function ‘typename T::value_type gccBug::getFirstElement(const T) [with T = std::mapgccBug::VectorSubclass, gccBug::SomeTemplatedTypegccBug::SomeEnum, unsigned int, std::lessgccBug::VectorSubclass, std::allocatorstd::pairconst gccBug::VectorSubclass, gccBug::SomeTemplatedTypegccBug::SomeEnum, unsigned int ]’: anonymous_may_be_used_uninitialized.cpp:45: warning: ‘anonymous’ may be used uninitialized in this function anonymous_may_be_used_uninitialized.cpp:45: note: ‘anonymous’ was declared here When I decrease optimization level to 0 a warning disappears. I checked test files attached to multiple similar bugs (including http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58877 which disappeared after upgrade from 4.4.6 to 4.4.7) but none of them generated this warning. That is why I am creating a new bug. Using http://gcc.godbolt.org/ I confirmed that this bug still occurs on Ubuntu/Linaro 4.4.7-1ubuntu2 and does not occur on newer versions so at least the code attached my serve as an addition to your regression suite.
[Bug c++/59292] Spurious warning: ‘anonymous’ is used uninitialized in this function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59292 --- Comment #1 from Przemysław Strzelczak bluesmissionnaire at gmail dot com --- Created attachment 31291 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31291action=edit corresponding source file.
[Bug c++/59113] [c++1y] ICE using auto as parameter in local function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59113 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org --- Fixed by Adam's patch.
[Bug c++/59112] [c++1y] ICE using auto as parameter in local class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59112 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org --- Fixed by Adam's patch.
[Bug c/59293] New: Bogus -Wsign-compare warning when using typeof() on a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59293
Bug ID: 59293
Summary: Bogus -Wsign-compare warning when using typeof() on a
constant
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shawn at churchofgit dot com
#define MAX(a,b) \
__extension__ ({ \
typeof(a) _a = (a); \
typeof(b) _b = (b); \
_a _b ? _a : _b; \
})
int main() {
if (MAX(5, (unsigned)3))
return 1;
return 0;
}
gives:
excessive_signed_compare.c:5:28: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
_a _b ? _a : _b; \
^
excessive_signed_compare.c:9:6: note: in expansion of macro ‘MAX’
if (MAX(5, (unsigned)3))
^
excessive_signed_compare.c:5:38: warning: signed and unsigned type in
conditional expression [-Wsign-compare]
_a _b ? _a : _b; \
[Bug sanitizer/59258] ubsan: ICE(segfault): stack-buffer-overflow with -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59258 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #10) Created attachment 31289 [details] Untested fix for the dwarf2out.c ICE. Seem to solve the problem with both -g and no -g for one unreduced test file. Thanks! Perhaps my * ubsan.c (ubsan_source_location): Don't crash on unknown locations. change will be unneeded now? Possibly yes; when I revert it, PR59250's test case still passes and also the unreduced test case (for this PR's problem) passes. (I will try the bigger code tomorrow.)
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 --- Comment #1 from Jeffrey A. Law law at redhat dot com --- Patch in testing.
[Bug fortran/58026] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1521
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026 janus at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from janus at gcc dot gnu.org --- For the record: The code that I'm proposing to remove in comment 4 has been added by Paul in r105913: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=105913
[Bug c++/58607] [4.9 Regression] [c++11] ICE with undeclared variable in constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58607 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug c++/55004] [meta-bug] constexpr issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 58607, which changed state. Bug 58607 Summary: [4.9 Regression] [c++11] ICE with undeclared variable in constexpr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58607 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/58607] [4.9 Regression] [c++11] ICE with undeclared variable in constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58607 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Nov 25 20:51:56 2013 New Revision: 205364 URL: http://gcc.gnu.org/viewcvs?rev=205364root=gccview=rev Log: /cp 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/58607 * semantics.c (check_constexpr_ctor_body): Check for BIND_EXPR_VARS. /testsuite 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/58607 * g++.dg/cpp0x/constexpr-ice9.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/58026] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1521
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58026 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to janus from comment #6) For the record: The code that I'm proposing to remove in comment 4 has been added by Paul in r105913: For PR24158 (ice-on-invalid-code), which was on 2005-10-26.
[Bug target/59187] internal error with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59187 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, bug was already fixed. Therefore closed
[Bug lto/55902] lto1 SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55902 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- Gold isn't available for pe-coff targets. Gold is ELF only. You might want to check if you have same issues with HJ's *special* ld version. HJ's patched variant never got into upstream (AFAIK), but resolves a lot of such issues. Biggest problem here is mainly that LTO doesn't handle object-files proper in linker. By this crt-objects (startup and co) might cause issues. I learned that in some cases it was helpful to build mingw-w64's startup-libraries with enabled -flto.
[Bug target/52368] internal compiler error: in convert_move, at expr.c:326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52368 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- So report is older then 1 year, no reply. So assume issue is solved.
[Bug other/33797] Enable zlib for x86_64-pc-mingw32 64-bit targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33797 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- gcc build libz only if libjava gets enabled. There is no need for gcc to build it without this target-library. YOu can enable now java built, then libz gets built too.
[Bug rtl-optimization/56451] [4.8/4.9 regression] Wrong code for gcc.c-torture/execute/941015-1.c on SH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56451 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-25 Ever confirmed|0 |1 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- Hm, I'm just poking around here, sorry if it's just useless noise ... In dbr_schedule, doing: fill_simple_delay_slots (1); fill_simple_delay_slots (0); fill_eager_delay_slots (); relax_delay_slots (first); or // fill_simple_delay_slots (1); fill_simple_delay_slots (0); fill_eager_delay_slots (); relax_delay_slots (first); - produces bad code. fill_simple_delay_slots (1); fill_simple_delay_slots (0); // fill_eager_delay_slots (); relax_delay_slots (first); - doesn't do anything to the code. // fill_simple_delay_slots (1); // fill_simple_delay_slots (0); fill_eager_delay_slots (); relax_delay_slots (first); or fill_simple_delay_slots (1); // fill_simple_delay_slots (0); fill_eager_delay_slots (); relax_delay_slots (first); - results in the following code (looks OK): mov.l .L8,r1 cmp/ge r1,r5 bf/s.L11 mov #1,r0 cmp/gt r1,r5 bt/s.L6 mov #2,r0 mov.l .L9,r1 cmp/hs r1,r4 bt .L6 mov #1,r0 .L6: .align 1 .L11: rts nop .L10:
[Bug c++/56597] unaligned local variable used by implicit sse instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56597 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- Issue here is that x64 ABI just requires that stack has 16-byte alignment. So that means within a function, using instruction requestion higher-alignment, compiler should either make sure that for those instructions variables get desired alignment, or that unaligned access is used. Otherwise I don't see here a way to resolve that, especially in scenario that code gets used by foreign compiler.
[Bug c++/55898] Can't obtain stack trace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55898 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-25 Ever confirmed|0 |1 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, this is related to the switch --enable-sjlj-exceptions turning off eh_frame information
[Bug c/59293] Bogus -Wsign-compare warning when using typeof() on a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59293 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I don't think this is a bogus warning as the warning is correct as you have a signed int variable unsigned int variable. The compiler does not know that variable is assigned to a constant here.
[Bug bootstrap/55886] gcc/configure.ac problems lead to GCC 4.7.2 not building for x86_64-pc-mingw64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55886 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-25 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- The use of target's host-part-name mingw64 is strongly discuraged. Most checks in binutils, gdb, gcc, etc (and all their testsuites) are using still mingw32. Therefore for resolve your issue use triplet x86_64-pc-mingw32 instead. I will keep this bug as long-term issue. Nothing to fix soon.
[Bug bootstrap/49557] make chokes on various Makefile constructs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #13 from Kai Tietz ktietz at gcc dot gnu.org --- No response for over 2 years now. close at won't fix
[Bug c++/54485] g++ should diagnose default arguments in out-of-line definitions for template class member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54485 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/54485] g++ should diagnose default arguments in out-of-line definitions for template class member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54485 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Nov 25 22:24:58 2013 New Revision: 205367 URL: http://gcc.gnu.org/viewcvs?rev=205367root=gccview=rev Log: /cp 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/54485 * decl.c (duplicate_decls): Enforce 8.3.6/6 about default arguments for member functions of class templates. /testsuite 2013-11-25 Paolo Carlini paolo.carl...@oracle.com PR c++/54485 * g++.dg/other/default8.C: New. * g++.dg/tc1/dr217.C: Remove xfail. * g++.dg/other/default5.C: Adjust. * g++.old-deja/g++.mike/p1989.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/other/default8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/default5.C trunk/gcc/testsuite/g++.dg/tc1/dr217.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p1989.C
[Bug c++/58950] [4.9 Regression] Missing statement has no effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- For __builtin_shuffle, the issue is that we now call save_expr, which always sets TREE_SIDE_EFFECTS to 1. I don't know if it would make sense to introduce a maybe_save_expr that is equivalent to save_expr but does not set TREE_SIDE_EFFECTS if its argument doesn't have it. But in any case I think we still want to warn for an unused result in __builtin_shuffle(x,++m) so that's not the solution. In C we also have the side_effects_flag but we still warn in warn_if_unused_value (the default for unknown trees), whereas in C++ (near the end of convert_to_void in cvt.c) only some tcc_comparison, tcc_unary and tcc_binary can warn when they have side effects. It would be easy to add VEC_PERM_EXPR to the list and get a value computed is not used, I just don't know if something more general is possible. For (i+i), the PLUS_EXPR ends up with nowarning_flag = 1 somehow.
[Bug c++/59292] Spurious warning: ‘anonymous’ is used uninitialized in this function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59292 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Thanks for the report. However, this testcase is not very useful for the regression testsuite. We need a minimal testcase: http://gcc.gnu.org/bugs/minimize.html. Since you say that the bug is not present in newer releases (4.4 is very old), I think it is better to close this.
[Bug c/59293] Bogus -Wsign-compare warning when using typeof() on a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59293 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- This would require CCP in the FE or moving these warnings to the middle-end, which is something that no current developer thinks is a good idea. Clang also warns here. *** This bug has been marked as a duplicate of bug 38470 ***
[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38470 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||shawn at churchofgit dot com --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 59293 has been marked as a duplicate of this bug. ***
[Bug c++/59294] New: template friend declaration 'hidden' by member of same name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59294
Bug ID: 59294
Summary: template friend declaration 'hidden' by member of same
name
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan.schwarzer at ipm dot fraunhofer.de
/* Dear experts,
I would like to use the same identifier for a member function and
a friend function of similar signature. Either declaring the friend
or the member works fine, but if both (#ifdef PROBLEM true) are present,
g++ starts yelling at me:
*/
template class T class Q;
template class T
const QT conjugate(const QT );
templateclass T
struct Q {
#define PROBLEM
#ifdef PROBLEM
const Q conjugate() { return *this; }
#endif
friend const QT conjugateT(const QT ); // PROBLEM
// friend const Q conjugateT(const Q ); // -- equivalent
// friend const Q conjugate(const Q ); // -- equivalent
};
template class T
const QT conjugate(const QT ) { return QT(); }
int main () {
Qint q;
#ifdef PROBLEM
q.conjugate();
#endif
conjugate(q);
return 0;
}
/*
$ g++ t.cc
t.cc:17:20: error: ‘conjugate’ is neither function nor member function; cannot
be declared friend
friend const QT conjugateT(const QT );
^
t.cc:17:20: error: expected ‘;’ at end of member declaration
t.cc:17:29: error: expected unqualified-id before ‘’ token
friend const QT conjugateT(const QT );
Nothing I tried really helps:
- the existence or not of the forward declaration does not help
- my three feeble attempts of syntax variation (in comments) behave
equivalently
- using a qualified-id ::conjugate in the friend declaration only changes the
error message
Am I missing something basic or is this a compiler bug?
(debian testing)
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-1)
*/
