[Bug c/59963] Wrong column number for warning -Woverflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59963 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Fri Jan 31 08:13:50 2014 New Revision: 207335 URL: http://gcc.gnu.org/viewcvs?rev=207335&root=gcc&view=rev Log: PR c/59963 c-family/ * c-common.c (add_atomic_size_parameter): Pass vNULL to build_function_call_vec. (resolve_overloaded_builtin): Likewise. * c-common.h (build_function_call_vec): Adjust declaration. cp/ * typeck.c (build_function_call_vec): Add dummy arg_loc parameter. c/ * c-typeck.c (convert_lvalue_to_rvalue): Pass vNULL to build_function_call_vec. (build_function_call): Likewise. (build_atomic_assign): Likewise. (build_function_call_vec): Add arg_loc parameter. Use it. (convert_arguments): Likewise. (convert_for_assignment): Rename rhs_loc to expr_loc. * c-parser.c (c_parser_attributes): Pass NULL to c_parser_expr_list. (c_parser_objc_keywordexpr): Likewise. (c_parser_postfix_expression_after_primary): Call build_function_call_vec with expr_loc rather than op_loc. Call c_parser_expr_list to fill arg_loc. Pass arg_loc to build_function_call_vec. (c_parser_expr_list): Add locations parameter. Fill it with locations of function arguments. * c-decl.c (finish_decl): Pass vNULL to build_function_call_vec. objc/ * objc-next-runtime-abi-02.c (build_throw_stmt): Pass vNULL to build_function_call_vec. (finish_catch): Likewise. (next_runtime_abi_02_get_class_reference): Likewise. * objc-next-runtime-abi-01.c (build_objc_method_call): Pass vNULL to build_function_call_vec. (build_throw_stmt): Likewise. * objc-gnu-runtime-abi-01.c: (build_objc_method_call): Pass vNULL to build_function_call_vec. (build_throw_stmt): Likewise. testsuite/ * gcc.dg/pr59940.c (g): Adjust dg-warning. (y): Adjust dg-error. * gcc.dg/cast-function-1.c (bar): Adjust dg-warnings. * gcc.dg/pr59963-1.c: New test. * gcc.dg/pr59963-2.c: New test. * gcc.dg/pr59963-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr59963-1.c trunk/gcc/testsuite/gcc.dg/pr59963-2.c trunk/gcc/testsuite/gcc.dg/pr59963-3.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/c/c-parser.c trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-gnu-runtime-abi-01.c trunk/gcc/objc/objc-next-runtime-abi-01.c trunk/gcc/objc/objc-next-runtime-abi-02.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cast-function-1.c trunk/gcc/testsuite/gcc.dg/pr59940.c
[Bug c/59963] Wrong column number for warning -Woverflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59963 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Should be fixed.
[Bug libitm/60004] Conditional return within transaction causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60004 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-31 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. We hit 2103 case GIMPLE_EH_ELSE: 2104 /* We should be eliminating this in lower_try_finally et al. */ 2105 gcc_unreachable ();
[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003 --- Comment #2 from Jakub Jelinek --- Ah, I see what's going on. eliminate_unnecessary_calls in dce calls clear_special_calls. Before my patch, __builtin_setjmp lowering would add a dummy non-local label to the function, so that while dce would clear cfun->calls_setjmp, cfun->has_nonlocal_label would be still set, but with my patch that is no longer happening, so stmt_can_make_abnormal_goto is always false during inlining and the corresponding edges aren't added. So, either e.g. tree-cfg.c could just set cfun->has_nonlocal_label when it sees a __builtin_setjmp_receiver (or say gimple-low.c when lowering __builtin_setjmp could set it) to restore status quo. Or I wonder, is there any special reason to avoid cfun->calls_setjmp when you actually call setjmp? Like say make __builtin_setjmp_receiver ECF_RETURNS_TWICE, or just special casing it in notice_special_calls and in the inliner (which just should call notice_special_calls)?
[Bug middle-end/59737] [4.9 Regression] ice from optimize_inline_calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59737 --- Comment #2 from Markus Trippelsdorf --- Valgrind shows: ==26377== Invalid read of size 4 ==26377==at 0x7D91EE: fold_stmt_1(gimple_stmt_iterator*, bool) (gimple-fold.c:1186) ==26377==by 0x997F29: fold_marked_statements(int, pointer_set_t*) (tree-inline.c:4511) ==26377==by 0x99FF50: optimize_inline_calls(tree_node*) (tree-inline.c:4592) ==26377==by 0xDAF93E: (anonymous namespace)::pass_early_inline::execute() (ipa-inline.c:2272) ==26377==by 0x8BC9C9: execute_one_pass(opt_pass*) (passes.c:2226) ==26377==by 0x8BCC45: execute_pass_list(opt_pass*) (passes.c:2279) ==26377==by 0x8BB54D: do_per_function_toporder(void (*)(void*), void*) (passes.c:1627) ==26377==by 0x8BD156: execute_ipa_pass_list(opt_pass*) (passes.c:2610) ==26377==by 0x6E4229: compile() (cgraphunit.c:2033) ==26377==by 0x6E4A74: finalize_compilation_unit() (cgraphunit.c:2319) ==26377==by 0x5960C4: cp_write_global_declarations() (decl2.c:4431) ==26377==by 0x957DCC: compile_file() (toplev.c:562) ==26377== Address 0x5627794 is 4 bytes inside a block of size 40 free'd ==26377==at 0x402AABE: realloc (vg_replace_malloc.c:687) ==26377==by 0xE4BF8C: xrealloc (xmalloc.c:179) ==26377==by 0x803712: maybe_record_node(vec&, tree_node*, pointer_set_t*, bool*) (vec.h:293) ==26377==by 0x805668: possible_polymorphic_call_targets(tree_node*, long, ipa_polymorphic_call_context, bool*, void**) (ipa-devirt.c:1185) ==26377==by 0x7D91DA: fold_stmt_1(gimple_stmt_iterator*, bool) (ipa-utils.h:135) ==26377==by 0x997F29: fold_marked_statements(int, pointer_set_t*) (tree-inline.c:4511) ==26377==by 0x99FF50: optimize_inline_calls(tree_node*) (tree-inline.c:4592) ==26377==by 0xDAF93E: (anonymous namespace)::pass_early_inline::execute() (ipa-inline.c:2272) ==26377==by 0x8BC9C9: execute_one_pass(opt_pass*) (passes.c:2226) ==26377==by 0x8BCC45: execute_pass_list(opt_pass*) (passes.c:2279) ==26377==by 0x8BB54D: do_per_function_toporder(void (*)(void*), void*) (passes.c:1627) ==26377==by 0x8BD156: execute_ipa_pass_list(opt_pass*) (passes.c:2610) ==26377== ==26377== Invalid read of size 1 ==26377==at 0x8061D8: hash_table::dispose() (vec.h:1656) ==26377==by 0x804386: free_polymorphic_call_targets_hash() (ipa-devirt.c:845) ==26377==by 0x6DCD08: cgraph_remove_node(cgraph_node*) (cgraph.c:364) ==26377==by 0x8248D4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:472) ==26377==by 0x6E4027: compile() (cgraphunit.c:2176) ==26377==by 0x6E4A74: finalize_compilation_unit() (cgraphunit.c:2319) ==26377==by 0x5960C4: cp_write_global_declarations() (decl2.c:4431) ==26377==by 0x957DCC: compile_file() (toplev.c:562) ==26377==by 0x959A27: toplev_main(int, char**) (toplev.c:1914) ==26377==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so) ==26377== Address 0x5627793 is 3 bytes inside a block of size 40 free'd ==26377==at 0x402AABE: realloc (vg_replace_malloc.c:687) ==26377==by 0xE4BF8C: xrealloc (xmalloc.c:179) ==26377==by 0x803712: maybe_record_node(vec&, tree_node*, pointer_set_t*, bool*) (vec.h:293) ==26377==by 0x805668: possible_polymorphic_call_targets(tree_node*, long, ipa_polymorphic_call_context, bool*, void**) (ipa-devirt.c:1185) ==26377==by 0x7D91DA: fold_stmt_1(gimple_stmt_iterator*, bool) (ipa-utils.h:135) ==26377==by 0x997F29: fold_marked_statements(int, pointer_set_t*) (tree-inline.c:4511) ==26377==by 0x99FF50: optimize_inline_calls(tree_node*) (tree-inline.c:4592) ==26377==by 0xDAF93E: (anonymous namespace)::pass_early_inline::execute() (ipa-inline.c:2272) ==26377==by 0x8BC9C9: execute_one_pass(opt_pass*) (passes.c:2226) ==26377==by 0x8BCC45: execute_pass_list(opt_pass*) (passes.c:2279) ==26377==by 0x8BB54D: do_per_function_toporder(void (*)(void*), void*) (passes.c:1627) ==26377==by 0x8BD156: execute_ipa_pass_list(opt_pass*) (passes.c:2610) ==26377== ==26377== Invalid free() / delete / delete[] / realloc() ==26377==at 0x40298B0: free (vg_replace_malloc.c:468) ==26377==by 0x8061EC: hash_table::dispose() (vec.h:312) ==26377==by 0x804386: free_polymorphic_call_targets_hash() (ipa-devirt.c:845) ==26377==by 0x6DCD08: cgraph_remove_node(cgraph_node*) (cgraph.c:364) ==26377==by 0x8248D4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:472) ==26377==by 0x6E4027: compile() (cgraphunit.c:2176) ==26377==by 0x6E4A74: finalize_compilation_unit() (cgraphunit.c:2319) ==26377==by 0x5960C4: cp_write_global_declarations() (decl2.c:4431) ==26377==by 0x957DCC: compile_file() (toplev.c:562) ==26377==by 0x959A27: toplev_main(int, char**) (toplev.c:1914) ==26377==by 0x4ED5F8F: (below main) (in /lib64/libc-2.18.90.so) ==26377== Address 0x5627790 is 0 bytes inside a block of size 40 free'd ==26377==at 0x402AABE: realloc (vg_replace_malloc.c:687) ==26377==by 0xE4BF8C: xrealloc (xmalloc.c:179) ==26377==
[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003 --- Comment #3 from Jakub Jelinek --- Created attachment 31997 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31997&action=edit gcc49-pr60003-1.patch Untested quick hack to set cfun->has_nonlocal_label, seems to work on this testcase.
[Bug tree-optimization/55260] [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260 --- Comment #11 from Markus Trippelsdorf --- Martin, can you take a look?
[Bug fortran/59906] [4.7/4.8/4.9 Regression] error: size of variable '' is too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59906 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- (In reply to Harald Anlauf from comment #3) > I ran the testcase under gdb to see where the error is thrown. > snip > It appears that the error is generated rather late. Are there any > intermediate files it makes sense to look at, to see the effect of > slight variations of the input? (E.g. where the "anonymous namespace" > comes from.) It would be very useful if you would try to compile it with -ftree-dump-original and post the result around the scalarization loop for ! Does not compile: print*,str_cmp((/'aaa','bbb'/), str_aux) In order to isolate all the code associated with a particular line, I cast it into a contained subroutine which is then called instead of the offending line. (I am not in a position to do it myself until tonight.) HJ is certainly correct that r158683 is the cause - Thanks for the heads-up, HJ. It amazes me that this bug has not been triggered in 3 years and 9 months! Cheers Paul
[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003 --- Comment #4 from Eric Botcazou --- > Ah, I see what's going on. eliminate_unnecessary_calls in dce calls > clear_special_calls. Before my patch, __builtin_setjmp lowering would add a > dummy non-local label to the function, so that while dce would clear > cfun->calls_setjmp, cfun->has_nonlocal_label would be still set, but with my > patch that is no longer happening, so stmt_can_make_abnormal_goto is always > false during inlining and the corresponding edges aren't added. OK, thanks for analysis. > So, either e.g. tree-cfg.c could just set cfun->has_nonlocal_label when it > sees a __builtin_setjmp_receiver (or say gimple-low.c when lowering > __builtin_setjmp could set it) to restore status quo. At the RTL level, cfun->has_nonlocal_label is set when __builtin_setjmp_setup is expanded (in expand_builtin_setjmp_setup) so I think that we should do the same at the Tree level. My preference would be for gimple-low.c but no strong opinion. > Or I wonder, is there any special reason to avoid cfun->calls_setjmp when > you actually call setjmp? Like say make __builtin_setjmp_receiver > ECF_RETURNS_TWICE, or just special casing it in notice_special_calls and in > the inliner (which just should call notice_special_calls)? Historically cfun->calls_setjmp is a big hammer that disables optimization passes, which was unnecessary for __builtin_setjmp because everything is exposed in the IL. Nowadays the distinction with the regular setjmp is less clear, but I think that we should lean towards clearing cfun->calls_setjmp rather than setting it, or else reducing its impact on optimization passes.
[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003 --- Comment #5 from Jakub Jelinek --- Created attachment 31998 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31998&action=edit gcc49-pr60003-2.patch Untested variant which makes __builtin_setjmp_receiver a returns twice function. For some strange reason this doesn't work, the test hangs.
[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003 --- Comment #6 from Jakub Jelinek --- Created attachment 31999 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31999&action=edit gcc49-pr60003-3.patch Untested third variant, which just makes sure cfun->calls_setjmp is set even for __builtin_setjmp_receiver. This one seems to work for the testcase.
[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003 --- Comment #7 from Jakub Jelinek --- (In reply to Eric Botcazou from comment #4) > > So, either e.g. tree-cfg.c could just set cfun->has_nonlocal_label when it > > sees a __builtin_setjmp_receiver (or say gimple-low.c when lowering > > __builtin_setjmp could set it) to restore status quo. > > At the RTL level, cfun->has_nonlocal_label is set when > __builtin_setjmp_setup is expanded (in expand_builtin_setjmp_setup) so I > think that we should do the same at the Tree level. My preference would be > for gimple-low.c but no strong opinion. Ok, so you prefer the first patch? Now to write some comment explaining why... > > Or I wonder, is there any special reason to avoid cfun->calls_setjmp when > > you actually call setjmp? Like say make __builtin_setjmp_receiver > > ECF_RETURNS_TWICE, or just special casing it in notice_special_calls and in > > the inliner (which just should call notice_special_calls)? > > Historically cfun->calls_setjmp is a big hammer that disables optimization > passes, which was unnecessary for __builtin_setjmp because everything is > exposed in the IL. Nowadays the distinction with the regular setjmp is less > clear, but I think that we should lean towards clearing cfun->calls_setjmp > rather than setting it, or else reducing its impact on optimization passes. At GIMPLE level indeed, cfun->calls_setjmp is now purely about whether the abnormal edges are constructed or not, the tree-tailcall.c use probably could go. For normal setjmp calls (and fork etc.) we do nothing though at the RTL level though, so cfun->calls_setjmp is probably still needed there.
[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003 --- Comment #8 from Eric Botcazou --- > Ok, so you prefer the first patch? Now to write some comment explaining > why... Yes, I'm very fond of one-liners. :-) You can say that the label taken by __builtin_setjmp is treated as a non-local label by the middle-end.
[Bug tree-optimization/59998] [4.9 regression] internal compiler error: SSA corruption: Unable to coalesce ssa_names 4 and 135 which are marked as MUST COALESCE.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59998 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 59993 ***
[Bug middle-end/59993] [4.9 Regression] ICE: SSA corruption
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59993 Richard Biener changed: What|Removed |Added CC||gerald at pfeifer dot com --- Comment #10 from Richard Biener --- *** Bug 59998 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #1 from Richard Biener --- I guess pure co-incidence
[Bug tree-optimization/60000] [4.8/4.9 Regression] GCC trunk build failure caused by the vectorizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #2 from Paulo J. Matos --- (In reply to Richard Biener from comment #1) > I guess pure co-incidence If I understand you correctly you think that the patch I mentioned is not the culprit but simply triggered this to happen. It might be true indeed. The patch was obtained with a simple bisect from the git repository using the v850 as testing backend since the mep backend is much more recent so I couldn't really test it.
[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Created attachment 32000 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32000&action=edit gcc49-pr60003.patch Ok, so this is what I'm going to bootstrap/regtest.
[Bug tree-optimization/60001] VRP fails to fold identical unsigned comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60001
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-01-31
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
:
p_10 = ASSERT_EXPR ;
q_11 = ASSERT_EXPR p_10>;
if (p_10 >= q_11)
goto ;
else
goto ;
Visiting statement:
p_10 = ASSERT_EXPR ;
Intersecting
[0, q_2(D) + 4294967295] EQUIVALENCES: { p_1(D) } (1 elements)
and
VARYING
to
[0, q_2(D) + 4294967295] EQUIVALENCES: { p_1(D) } (1 elements)
Found new range for p_10: [0, q_2(D) + 4294967295]
Visiting statement:
q_11 = ASSERT_EXPR p_10>;
Intersecting
[p_10 + 1, +INF] EQUIVALENCES: { q_2(D) } (1 elements)
and
VARYING
to
[p_10 + 1, +INF] EQUIVALENCES: { q_2(D) } (1 elements)
Found new range for q_11: [p_10 + 1, +INF]
Visiting conditional with predicate: if (p_10 >= q_11)
With known ranges
p_10: [0, q_2(D) + 4294967295] EQUIVALENCES: { p_1(D) } (1 elements)
q_11: [p_10 + 1, +INF] EQUIVALENCES: { q_2(D) } (1 elements)
Predicate evaluates to: DON'T KNOW
Why we don't fold this we should
see that p_10 >= q_11 is equivalent to p_10 >= [p_10 + 1, +INF]
Ah. It doesn't even ask that. I can make it ask [p_10 + 1, +INF] <= p_10.
Then it says that p_10 and +INF are un-ordered (it doesn't see that p_10
cannot be +INF because then [p_10 + 1, +INF] wouldn't be a valid range).
Similar it says that p_10 + 1 and p_10 are un-ordered because if p_10 is
+INF then p_10 + 1 will wrap.
So compare_range_with_value needs to be more sophisticated for these cases
(involving symbolic ranges).
[Bug tree-optimization/60003] [4.9 regression] wrong code with __builtin_setjmp/__builtin_longjmp and inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60003 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/59595] [4.9 Regression] Segmentation fault: build/genpreds -c ../../gcc/gcc/config/arm/arm.md > tmp-constrs.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59595 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug fortran/59765] [4.9 Regression] [OOP] ICE on valid with finalizable array components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug fortran/58470] [4.9 Regression] [OOP] ICE on invalid with FINAL procedure and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.8.3
[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59727 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.7.4
[Bug target/59385] [4.9 regression] gcc 4.9 fails to use fma with __attribute__((target("fma")))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.7.4
[Bug fortran/58470] [4.9 Regression] [OOP] ICE on invalid with FINAL procedure and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 Richard Biener changed: What|Removed |Added Priority|P3 |P5
[Bug ipa/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug libstdc++/60005] New: std::wcstod() doesn't work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60005
Bug ID: 60005
Summary: std::wcstod() doesn't work properly
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: zizheng.tai at gmail dot com
According to cppreference, the second argument passed to std::wcstod, which is
a pointer to a pointer to wchar_t (i.e., of type wchar_t **), will
1) be used to store the end of the converted part of the string if the argument
is not nullptr; or
2) not be used at all if the argument is nullptr.
However, when the following code is compiled and linked with mingw32-gcc4.8.0
on 32-bit Windows 7 with command line "g++ a.cpp -std=c++11 -Wall -Wextra", no
warning showed up but the program crashed when running.
// a.cpp
#include
int main()
{
std::wcstod(L"5000", nullptr);
return 0;
}
While the following code has no problem:
// acpp
#include
int main()
{
wchar_t *p = nullptr;
std::wcstod(L"5000", &p);
return 0;
}
[Bug target/59385] [4.9 regression] gcc 4.9 fails to use fma with __attribute__((target("fma")))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Richard Biener --- (In reply to Julian Taylor from comment #6) > shouldn't -ffast-math enable -ffp-contract=fast? it doesn't (it probably should) > also gcc 4.9 still documents -ffp-contract=fast as being the default while > it is apparently not anymore. it's the default unless you override it with -std=c99 (always use -std=gnu99). Are you sure this worked correctly in 4.8.0? I see both functions using vfmadd132sd there - that's cleary wrong as well. Works for me correctly, with -std=gnu99. Thus, it works as intended in 4.9 and the bug in 4.8 was fixed.
[Bug rtl-optimization/59393] [4.8/4.9 regression] mips16 code size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 Richard Biener changed: What|Removed |Added Target|mips16 | Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-31 CC||rguenth at gcc dot gnu.org Component|target |rtl-optimization Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed, not only mips16 is affected.
[Bug rtl-optimization/59393] [4.8/4.9 regression] mips16 code size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed as far as we care.
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/59082] [4.7/4.8/4.9 Regression] ICE with duplicate (virtual) base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59082 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-31 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Mine.
[Bug lto/59626] [4.8/4.9 Regression] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626 Richard Biener changed: What|Removed |Added Keywords||lto Priority|P3 |P1 Target Milestone|4.9.0 |4.8.3 Summary|[4.9 lto] |[4.8/4.9 Regression] |/usr/include/bits/unistd.h: |/usr/include/bits/unistd.h: |173:1: error: inlining |173:1: error: inlining |failed in call to |failed in call to |always_inline 'readlinkat': |always_inline 'readlinkat': |recursive inlining |recursive inlining
[Bug lto/59723] [4.9 Regression] ICE: in lto_output_tree, at lto-streamer-out.c:1390 when compiling some Fortran tests with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59723 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/59646] [4.7/4.8/4.9 Regression] ICE with volatile in initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59646 Richard Biener changed: What|Removed |Added Keywords|error-recovery |rejects-valid Priority|P3 |P2
[Bug middle-end/59737] [4.9 Regression] ice from optimize_inline_calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59737 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/59762] [4.9 Regression] func-vararg-mixed.c fails on PowerPC starting with revision 204079
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59762 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1
[Bug fortran/59765] [4.9 Regression] [OOP] ICE on valid with finalizable array components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/59811] [4.8/4.9 Regression] Huge increase in memory usage and compile time in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Bah. Add a limiting --param to combine?
[Bug fortran/59906] [4.7/4.8/4.9 Regression] error: size of variable '' is too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59906 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug regression/59923] [4.9 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239 with -mcpu=cortex-a15 -mthumb -O2 -fvisibility=hidden -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59923 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug bootstrap/59913] [4.9 Regresion] bootstrap failure on arm-linux-gnueabihf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59913 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/59918] [4.9 Regression] ICE in record_target_from_binfo, at ipa-devirt.c:693
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/59924] [4.9 Regression] uninit memory hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59924 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|other |tree-optimization
[Bug target/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59927 Richard Biener changed: What|Removed |Added Target||i?86-*-* Priority|P3 |P1 Component|other |target
[Bug ipa/59947] [4.9 Regression] Segmentation fault with #pragma GCC optimize ("O2"), ICE in get_odr_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59947 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Component|tree-optimization |rtl-optimization --- Comment #3 from Richard Biener --- Yes, I think that the IV choice merely shows that we miss to optimize the extension - which would be somewhere in the RTL opt pipeline.
[Bug rtl-optimization/59811] [4.8/4.9 Regression] Huge increase in memory usage and compile time in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 --- Comment #6 from Jakub Jelinek --- Dunno what to limit there though. BTW, the 1000 default for sccvn-max-alias-queries-per-access param was some carefully chosen value, e.g. does the test that was fixed by the addition of the param fail if it is bumped to say 1500 or 2000, or can we just bump slightly the default?
[Bug rtl-optimization/59811] [4.8/4.9 Regression] Huge increase in memory usage and compile time in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 --- Comment #7 from rguenther at suse dot de --- On Fri, 31 Jan 2014, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 > > --- Comment #6 from Jakub Jelinek --- > Dunno what to limit there though. > > BTW, the 1000 default for sccvn-max-alias-queries-per-access param was some > carefully chosen value, e.g. does the test that was fixed by the addition of > the param fail if it is bumped to say 1500 or 2000, or can we just bump > slightly the default? It was reasonably chosen - the testcase I added it for still uses a lot of time in alias-walking (~30% I think which I decided was reasonable for the testcase). We sure can slightly bump it, but that only requires a slightly larger testcase to re-trigger this bug?
[Bug middle-end/59990] [4.7/4.8 regression] incorrect memcpy optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990 Richard Biener changed: What|Removed |Added Priority|P2 |P3 Known to work||4.9.0 Summary|[4.7/4.8/4.9 regression]|[4.7/4.8 regression] |incorrect memcpy|incorrect memcpy |optimization|optimization --- Comment #14 from Richard Biener --- Fixed for trunk sofar.
[Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990 --- Comment #13 from Richard Biener --- Author: rguenth Date: Fri Jan 31 11:54:26 2014 New Revision: 207338 URL: http://gcc.gnu.org/viewcvs?rev=207338&root=gcc&view=rev Log: 2014-01-31 Richard Biener PR middle-end/59990 * builtins.c (fold_builtin_memory_op): Make sure to not use a floating-point mode or a boolean or enumeral type for the copy operation. * gcc.dg/torture/pr59990.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59990.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/59990] [4.7/4.8 regression] incorrect memcpy optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #4 from Paulo J. Matos --- (In reply to Richard Biener from comment #3) > Yes, I think that the IV choice merely shows that we miss to optimize the > extension - which would be somewhere in the RTL opt pipeline. Makes sense. My first instinct was to do it in expand but since expand does one gimple statement at a time it might be too much for it to handle since it probably has to detect the sign extend and promote the type of the register if there are no conflicting conditions. If you suggest where to do this kind of thing I can give it a try. Thanks.
[Bug target/59385] [4.9 regression] gcc 4.9 fails to use fma with __attribute__((target("fma")))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385 --- Comment #8 from Julian Taylor --- > > > also gcc 4.9 still documents -ffp-contract=fast as being the default > while > > it is apparently not anymore. > > it's the default unless you override it with -std=c99 (always use > -std=gnu99). > it would be nice if the documentation would be updated to reflect this. It is not obvious -std overrides it, you expect the more specific options override the generic ones (e.g. -O2 -ftree-vectorize). > Are you sure this worked correctly in 4.8.0? I see both functions using > vfmadd132sd there - that's cleary wrong as well. > I can't say if its correct, but it behaved as I expected it. The emitting of fma in the non-fma target is a different issue, see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54344
[Bug sanitizer/59410] tsan tests fail with address randomization disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 --- Comment #32 from Yury Gribov --- Jakub has posted patch which may fix this: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg02044.html
[Bug tree-optimization/60006] New: [4.9 Regression] FAIL: c-c++-common/cilk-plus/CK/fib_no_(return|sync).c -O3 with -m32 after r207231 on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60006 Bug ID: 60006 Summary: [4.9 Regression] FAIL: c-c++-common/cilk-plus/CK/fib_no_(return|sync).c -O3 with -m32 after r207231 on x86_64-apple-darwin13 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, jakub at gcc dot gnu.org Host: x86_64-apple-darwin13 Target: x86_64-apple-darwin13 Build: x86_64-apple-darwin13 After r207231 the following tests fail on x86_64-apple-darwin13 with -m32 FAIL: c-c++-common/cilk-plus/CK/fib_no_return.c -O3 (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/CK/fib_no_return.c -O3 compilation failed to produce executable FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c -O3 (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/CK/fib_no_sync.c -O3 compilation failed to produce executable FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O2 -flto execution test FAIL: c-c++-common/cilk-plus/CK/fib_no_return.c -O3 -g (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/CK/fib_no_return.c -O3 -g compilation failed to produce executable FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c -O3 -g (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/CK/fib_no_sync.c -O3 -g compilation failed to produce executable FAIL: c-c++-common/cilk-plus/CK/fib_no_return.c -O3 -flto -g (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/CK/fib_no_return.c -O3 -flto -g compilation failed to produce executable FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c -O3 -flto -g (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/CK/fib_no_sync.c -O3 -flto -g compilation failed to produce executable The failures are of the kind /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccE8IAa2.s:856:FATAL:Symbol L2$pb already defined. The failures need -O3, but not -g nor -flto, and r207230 is OK.
[Bug preprocessor/60007] New: preprocessor aborts with internal error when redefining a flag set by -D option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60007
Bug ID: 60007
Summary: preprocessor aborts with internal error when
redefining a flag set by -D option
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: lutzwei at gmx dot de
Consider the following program stored in file "test.c" :
-
#define ANY_FLAG
int main() { int i=1;}
-
If you issue the command
cpp -DANY_FLAG test.c
you get an internal compiler error abort as follows:
--
# 1 "test.c"
# 1 ""
# 1 "test.c"
test.c:1:0: warning: "ANY_FLAG" redefined [enabled by default]
#define ANY_FLAG
^
:0:0: note: this is the location of the previous definition
test.c:1:0: internal compiler error: Segmentation fault
#define ANY_FLAG
^
0x99c5bf crash_signal
../../gcc-4.9.0/gcc/toplev.c:337
0xf0d747 add_file_to_cache_tab
../../gcc-4.9.0/gcc/input.c:296
0xf0d747 lookup_or_add_file_to_cache_tab
../../gcc-4.9.0/gcc/input.c:330
0xf0d747 location_get_source_line(expanded_location, int*)
../../gcc-4.9.0/gcc/input.c:704
0xf0868b diagnostic_show_locus(diagnostic_context*, diagnostic_info const*)
../../gcc-4.9.0/gcc/diagnostic.c:304
0xf096cb diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc-4.9.0/gcc/diagnostic.c:800
0x5cd9f4 c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char
const*, __va_list_tag (*) [1])
../../gcc-4.9.0/gcc/c-family/c-common.c:9639
0xf17ef6 cpp_error_with_line(cpp_reader*, int, unsigned int, unsigned int, char
const*, ...)
../../gcc-4.9.0/libcpp/errors.c:163
0xf27f4f _cpp_create_definition
../../gcc-4.9.0/libcpp/macro.c:3124
0xf146f1 do_define
../../gcc-4.9.0/libcpp/directives.c:584
0xf15f27 _cpp_handle_directive
../../gcc-4.9.0/libcpp/directives.c:492
0xf22a2c _cpp_lex_token
../../gcc-4.9.0/libcpp/lex.c:2067
0xf2761f cpp_get_token_1
../../gcc-4.9.0/libcpp/macro.c:2362
0x5e995f scan_translation_unit
../../gcc-4.9.0/gcc/c-family/c-ppoutput.c:176
0x5e995f preprocess_file(cpp_reader*)
../../gcc-4.9.0/gcc/c-family/c-ppoutput.c:101
0x5e8378 c_common_init()
../../gcc-4.9.0/gcc/c-family/c-opts.c:1040
0x57aacd c_objc_common_init()
../../gcc-4.9.0/gcc/c/c-objc-common.c:65
0x99e616 lang_dependent_init
../../gcc-4.9.0/gcc/toplev.c:1712
0x99e616 do_compile
../../gcc-4.9.0/gcc/toplev.c:1900
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
--
The preprocessor version is:
-bash-4.1$ cpp -v
--
Using built-in specs.
COLLECT_GCC=cpp
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.0/configure
LDFLAGS=-Wl,-rpath,/home/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc/lib
--prefix=/home/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc
--with-gmp=/home/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc
--with-mpfr=/home/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc
--with-mpc=/home/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc
--with-gcc-version-trigger=/work/weimann/installs/gcc-4.9.0/gcc/version.c
--enable-languages=c,c++,f95 --disable-multilib
Thread model: posix
gcc version 4.9.0 20140124 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
/nfs/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1
-E -quiet -v -iprefix
/nfs/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/
- -mtune=generic -march=x86-64
ignoring nonexistent directory
"/nfs/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/nfs/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include"
ignoring duplicate directory
"/nfs/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include-fixed"
ignoring nonexistent directory
"/nfs/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/nfs/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include
/nfs/datanumerik/archiv/software/linux64/gcc-4.9.0/gcc/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include-fixed
/usr/local/include
/nfs/datanume
[Bug bootstrap/59985] stage2/3 compare error on lto-streamer-in.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59985 --- Comment #13 from Bernd Edlinger --- (In reply to Richard Biener from comment #1) > does it work if you configure with --without-build-config? (thus, disable > bootstrap-debug) Just for the recores, this configure option produces a usable gcc. I will try if I can execute the test suite now.
[Bug gcov-profile/60008] New: x86_64: Segmentation fault if compiled with -fcall-saved-rdi -O2 --coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60008
Bug ID: 60008
Summary: x86_64: Segmentation fault if compiled with
-fcall-saved-rdi -O2 --coverage
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: peter.oberparleiter at de dot ibm.com
Programs compiled on x86_64 with GCC and options "-fcall-saved-rdi -O2
--coverage" cause a segmentation fault.
Minimal test case:
echo "int main() { return 0; }" | gcc -xc - -o /tmp/test --coverage -O2
-fcall-saved-rdi && /tmp/test
Release:
- gcc version 4.9.0 20140116 (experimental) [master revision
c334d99:760dcd4:018db0b6e750f01880f0d601e1cf167948f55ab5] (GCC)
Configured with: configure --prefix=gcc-head-install --enable-shared
--with-system-zlib --enable-threads=posix --enable-__cxa_atexit
--enable-checking --enable-gnu-indirect-function --program-suffix=-4.9.0
--with-as=binutils/install/bin/as --with-ld=binutils/install/bin/ld
--enable-languages=c
Also found on:
- gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
- gcc version 4.7.2 (Debian 4.7.2-5)
- gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
Environment:
GNU/Linux
Additional information:
The cause for the segmentation fault can be found when comparing the
generated constructor functions:
gcc --coverage -O2 -fcall-saved-rdi
00400c10 <_GLOBAL__I_65535_0_main>:
400c10: 57 push %rdi
400c11: 5f pop%rdi
400c12: e9 09 00 00 00 jmpq 400c20 <__gcov_init>
-> Nothing is loaded into %rdi, __gcov_init() accesses random memory
gcc --coverage -O2
00400c10 <_GLOBAL__I_65535_0_main>:
400c10: 48 83 ec 08 sub$0x8,%rsp
400c14: bf 60 2a 60 00 mov$0x602a60,%edi
400c19: 48 83 c4 08 add$0x8,%rsp
400c1d: e9 0e 00 00 00 jmpq 400c30 <__gcov_init>
-> %rdi contains pointer to gcov_info structure when __gcov_init() is called
gcc --coverage -fcall-saved-rdi
00400c11 <_GLOBAL__I_65535_0_main>:
400c11: 55 push %rbp
400c12: 48 89 e5mov%rsp,%rbp
400c15: 57 push %rdi
400c16: 48 83 ec 08 sub$0x8,%rsp
400c1a: bf 80 2a 60 00 mov$0x602a80,%edi
400c1f: e8 0c 00 00 00 callq 400c30 <__gcov_init>
400c24: 48 83 c4 08 add$0x8,%rsp
400c28: 5f pop%rdi
400c29: c9 leaveq
400c2a: c3 retq
-> %rdi contains pointer to gcov_info structure when __gcov_init() is called
[Bug preprocessor/60007] preprocessor aborts with internal error when redefining a flag set by -D option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60007 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- This is already fixed. Dup. *** This bug has been marked as a duplicate of bug 59935 ***
[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 Markus Trippelsdorf changed: What|Removed |Added CC||lutzwei at gmx dot de --- Comment #11 from Markus Trippelsdorf --- *** Bug 60007 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/60002] ICE: SIGSEGV in skip_artificial_parms_for() with -O2 -fcompare-debug -fdeclone-ctor-dtor -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60002 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I think the problem is in build_function_decl_skip_args removing various arguments for a clone, but DECL_LANG_SPECIFIC being copied rather than thrown away. While it takes care to change METHOD_TYPE into FUNCTION_TYPE if the first parameter is being removed, in this case it is preserved, but other parameters removed, and whether they must be there or not is recorded in DECL_LANG_SPECIFIC.
[Bug tree-optimization/60002] ICE: SIGSEGV in skip_artificial_parms_for() with -O2 -fcompare-debug -fdeclone-ctor-dtor -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60002 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-31 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- So, either we do something like: --- gcc/cgraphclones.c.jj2014-01-03 11:40:46.0 +0100 +++ gcc/cgraphclones.c2014-01-31 14:34:59.734148380 +0100 @@ -390,6 +390,9 @@ build_function_decl_skip_args (tree orig DECL_BUILT_IN_CLASS (new_decl) = NOT_BUILT_IN; DECL_FUNCTION_CODE (new_decl) = (enum built_in_function) 0; } + /* The FE might have information and assumptions about the other + arguments. */ + DECL_LANG_SPECIFIC (new_decl) = NULL; return new_decl; } (works on the testcase, otherwise untested), or add some language hook where the FE will have a chance to adjust it's DECL_LANG_SPECIFIC based on which arguments are being removed.
[Bug gcov-profile/60008] x86_64: Segmentation fault if compiled with -fcall-saved-rdi -O2 --coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60008 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Don't do it then? %rdi is the first parameter register on x86_64, so making it call saved is a very bad idea for many reasons.
[Bug gcov-profile/60008] x86_64: Segmentation fault if compiled with -fcall-saved-rdi -O2 --coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60008 --- Comment #2 from Jakub Jelinek --- E.g. -fcall-saved-rdi option is ABI changing option, so you'd need to have everything (from libc, libgcov, libgcc, libstdc++, ...) built that way. Furthermore, I don't think we consider this case e.g. to disallow tail call optimization (which is generally not possible under such weird ABI).
[Bug target/59952] -march=core-avx2 should not enable RTM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952 --- Comment #11 from Yukhin Kirill --- (In reply to Yukhin Kirill from comment #9) > (In reply to Jakub Jelinek from comment #6) > > Prerelease samples shouldn't count, people using those just can avoid using > > -march=haswell and use -march=ivybridge -mavx2 or similar instead. Can > > anyone from Intel verify if all released Haswell CPUs have BMI2 (and if > > there aren't plans to ship Haswell CPUs without BMI2)? > > I am checking and will get back to. I though all AVX2 parts had BMI1/2 AVX2 must imply BMI. AVX2 w/ BMI disabled are not-for-sale SKUs.
[Bug c++/59980] Diagnostics relating to template-specialisations using enums.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980
--- Comment #3 from Jason ---
C-style enums decay to the underlying integer representation, this particular
behaviour helps complicate considering how any modification to the diagnostic
might be implemented. Enum-classes are not without their own set of
complications,
but these are fewer than C-style enums, and might be more amenable to
implementing this modification of the diagnostic. As I see it the basic problem
is that the mapping of integers to sets-of-{of enumerator values} is not unique
for C-style enums. The issue is one of choice: (expression) can map to
{enumerator-names}, so which should one choose? But if one were to restrict
oneself to enum-classes, the mapping of (expression) to sets-of-{of enemerator
values} has been broken: one must explicitly cast, so at the cast-site the
particular enumeration is known, and if the results maps to an enumeration
value, it can be printed, otherwise the value could just be printed, with the
cast, as is done already. In particular, in my example of the
template-specialisation, the target enum-class is known, therefore the
diagnostic can reasonably coerce the result of the expression to a matching
enumeration-value, if it exists, and print that name. Of course one would need
to ensure that the enumerator-names have been stored with the enumerator-values
within the enumeration to allow this to occur.
[Bug c++/59646] [4.7/4.8/4.9 Regression] ICE with volatile in initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59646 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-31 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/59980] Diagnostics relating to template-specialisations using enums.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980 --- Comment #4 from Jonathan Wakely --- (In reply to Jason from comment #3) > C-style enums decay to the underlying integer representation, this > particular behaviour helps complicate considering how any modification to > the diagnostic might be implemented. I don't see how the decay is relevant, if the template parameter is of type E then the compiler's IR stores a value with that type, not an integer, so there's no decaying. For the purposes of this diagnostic I don't see any difference between scoped and unscoped enums.
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #5 from Richard Biener --- Apart from expand there is the redundant-extension-elimination, ree.c.
[Bug c++/60009] New: g++ allows copy-initialization of an array of class type from a non-braced string literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60009
Bug ID: 60009
Summary: g++ allows copy-initialization of an array of class
type from a non-braced string literal
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot co.uk
The following code should be rejected, but is accepted by g++ 4.8.1, in both
C++03 and C++11 mode:
struct s { s(const char *); } a[] = "";
It is rejected by clang++ and MSVC. Credit:
http://stackoverflow.com/questions/21481462/what-does-this-code-mean-and-why-does-it-work
List-initialization is correctly allowed in the braced-init-list case
(a[]{""}), and correctly disallowed in the parenthesized case (a[]("")).
Giving the array extent (a[2] = "") does not appear to make any difference.
It looks like the extent of the array is being taken from the length of the
string literal (including terminator), with some amusing results:
#include
#include
int main() {
std::string a[] = "hello";
for (int i = 0; i < sizeof(a)/sizeof(a[0]); ++i) std::cout << a[i] << '\n';
}
outputs:
hello
hello
hello
hello
hello
hello
(6, count 'em).
If an array extent is provided (e.g. std::string a[10] = "hello"), then the
string literal will be used to initialize each element.
[Bug gcov-profile/60008] x86_64: Segmentation fault if compiled with -fcall-saved-rdi -O2 --coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60008 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener --- Yep. Cite from invoke.texi "It is an error to use this flag with the frame pointer or stack pointer. Use of this flag for other registers that have fixed pervasive roles in the machine's execution model produces disastrous results."
[Bug tree-optimization/60006] [4.9 Regression] FAIL: c-c++-common/cilk-plus/CK/fib_no_(return|sync).c -O3 with -m32 after r207231 on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60006 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #6 from Paulo J. Matos --- humm, ree is no good because by then we missed already the generation of zero overhead loops. Do you think this is something that could be added to expand?
[Bug c++/59646] [4.7/4.8/4.9 Regression] ICE with volatile in initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59646 --- Comment #3 from Jason Merrill --- Author: jason Date: Fri Jan 31 15:20:12 2014 New Revision: 207346 URL: http://gcc.gnu.org/viewcvs?rev=207346&root=gcc&view=rev Log: PR c++/59646 * call.c (convert_like_real) [ck_aggr]: Set TARGET_EXPR_LIST_INIT_P. [ck_list]: Check for error_mark_node. (build_aggr_conv): Set LOOKUP_NO_NARROWING and check_narrowing. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist79.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/57043] [4.7/4.8/4.9 Regression] converting overloaded complex function pow in C++11 is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57043 --- Comment #6 from Jason Merrill --- Author: jason Date: Fri Jan 31 15:20:05 2014 New Revision: 207345 URL: http://gcc.gnu.org/viewcvs?rev=207345&root=gcc&view=rev Log: PR c++/57043 * pt.c (fn_type_unification): Don't do DEDUCE_EXACT check during partial ordering. Added: trunk/gcc/testsuite/g++.dg/template/partial15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/57043] [4.7/4.8/4.9 Regression] converting overloaded complex function pow in C++11 is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57043 --- Comment #7 from Jason Merrill --- Author: jason Date: Fri Jan 31 15:21:13 2014 New Revision: 207347 URL: http://gcc.gnu.org/viewcvs?rev=207347&root=gcc&view=rev Log: PR c++/57043 * pt.c (fn_type_unification): Don't do DEDUCE_EXACT check during partial ordering. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/partial15.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug c++/59646] [4.7/4.8/4.9 Regression] ICE with volatile in initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59646 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.7.4 |4.8.3 --- Comment #5 from Jason Merrill --- Fixed for 4.8.3/4.9. Not applying to 4.7 unless someone cares.
[Bug c++/59646] [4.7/4.8/4.9 Regression] ICE with volatile in initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59646 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Jan 31 15:21:20 2014 New Revision: 207348 URL: http://gcc.gnu.org/viewcvs?rev=207348&root=gcc&view=rev Log: PR c++/59646 * call.c (convert_like_real) [ck_aggr]: Set TARGET_EXPR_LIST_INIT_P. [ck_list]: Check for error_mark_node. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/initlist79.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/call.c
[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915 --- Comment #8 from Jakub Jelinek --- Created attachment 32001 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32001&action=edit gcc49-pr57915.patch Untested fix.
[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915 Jakub Jelinek changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- I'd say if (plus:SI (symbol_ref:SI ...) (const_int ...)) not surrounded by (const:SI ) is considered invalid IL, then trying to workaround cprop bug in some other pass is still workaround rather than fix. So, either we make sure that it is simplified (will attach an untested patch for that), or do some minimal sanity checking for 'X' operands in asm_operand_ok (basically verify it is valid RTL, say start with testing for this missing CONST), or both.
[Bug pch/60010] New: AArch64: sigsegv in cc1plus using pch without defining TRY_EMPTY_VM_SPACE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60010 Bug ID: 60010 Summary: AArch64: sigsegv in cc1plus using pch without defining TRY_EMPTY_VM_SPACE Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: kyle at redhat dot com Created attachment 32002 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32002&action=edit add TRY_EMPTY_VM_SPACE define for __aarch64__ Building Fedora with randomize_vm_space on, we've noticed segmentation faults in cc1plus when precompiled headers are used. While I was debugging the PCH internals, Jakub kindly pointed out that AArch64 would probably need a TRY_EMPTY_VM_SPACE define to start looking for free memory at, instead of the default 0. (I suspect that buffer_size needs to be bigger than 32MB now.) Attached is a patch that survived rebuilding our easiest reproducing test-case (wxGTK) 30 times without issue. Thanks, Kyle M.
[Bug c++/55800] Link failure with thread_local in unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55800 Jason Merrill changed: What|Removed |Added CC||conradsand.arma at gmail dot com --- Comment #6 from Jason Merrill --- *** Bug 59364 has been marked as a duplicate of this bug. ***
[Bug c++/59994] [meta-bug] thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994 Bug 59994 depends on bug 55800, which changed state. Bug 55800 Summary: Link failure with thread_local in unnamed namespace http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55800 What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |---
[Bug c++/59364] thread_local link error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Resolution|FIXED |DUPLICATE --- Comment #8 from Jason Merrill --- Duplicate, yes. *** This bug has been marked as a duplicate of bug 55800 ***
[Bug c++/55800] Link failure with thread_local in unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55800 Jason Merrill changed: What|Removed |Added Status|RESOLVED|ASSIGNED Last reconfirmed||2014-01-31 CC||jason at gcc dot gnu.org Resolution|FIXED |--- Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug pch/60010] AArch64: sigsegv in cc1plus using pch without defining TRY_EMPTY_VM_SPACE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60010 --- Comment #1 from Kyle McMartin --- https://bugzilla.redhat.com/show_bug.cgi?id=1058991 Just FYI, this is RHBZ#1058991.
[Bug c++/57043] [4.7/4.8/4.9 Regression] converting overloaded complex function pow in C++11 is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57043 --- Comment #8 from Jason Merrill --- Author: jason Date: Fri Jan 31 15:55:46 2014 New Revision: 207355 URL: http://gcc.gnu.org/viewcvs?rev=207355&root=gcc&view=rev Log: PR c++/57043 * pt.c (fn_type_unification): Don't do DEDUCE_EXACT check during partial ordering. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/partial15.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/pt.c
[Bug c++/57043] [4.7/4.8/4.9 Regression] converting overloaded complex function pow in C++11 is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57043 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- Fixed.
[Bug c++/59082] [4.7/4.8/4.9 Regression] ICE with duplicate (virtual) base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59082 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Jan 31 16:22:53 2014 New Revision: 207359 URL: http://gcc.gnu.org/viewcvs?rev=207359&root=gcc&view=rev Log: /cp 2014-01-31 Paolo Carlini PR c++/59082 * class.c (build_vfield_ref): Early return error_mark_node if TYPE_VFIELD (type) is null. (build_base_path): Check return value of build_vfield_ref. /testsuite 2014-01-31 Paolo Carlini PR c++/59082 * g++.dg/inherit/crash4.C: New. Added: trunk/gcc/testsuite/g++.dg/inherit/crash4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59082] [4.7/4.8 Regression] ICE with duplicate (virtual) base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59082 Paolo Carlini 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 duplicate |with duplicate (virtual) |(virtual) base |base --- Comment #3 from Paolo Carlini --- Fixed for 4.9.0.
