[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 --- Comment #8 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-04-07 06:20:24 UTC --- There is a call to a non-static member function of the object before initialization by a constructor. That's undefined behavior. Not a compiler bug.
Re: Optimisation Problem
But i wanted to try them indivisually. Is there any method to do so? The compiler doesn't optimize anything if you don't pass at least -O. -- Eric Botcazou
[Bug rtl-optimization/45570] [4.6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4584
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45570 --- Comment #6 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 06:50:12 UTC --- Author: abel Date: Thu Apr 7 06:50:08 2011 New Revision: 172077 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172077 Log: Backport from mainline 2010-10-14 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45570 * sel-sched-ir.c (cfg_preds_1): When walking out of the region, assert that we are pipelining outer loops. Allow returning zero predecessors. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45570.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/46204] g++.dg/torture/stackalign/throw-1.C fails to compile on IA64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46204 --- Comment #5 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 06:51:52 UTC --- Author: abel Date: Thu Apr 7 06:51:49 2011 New Revision: 172078 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172078 Log: Backport from mainline 2010-11-12 Alexander Monakov amona...@ispras.ru PR rtl-optimization/46204 sel-sched-ir.c (maybe_tidy_empty_bb): Remove second argument. pdate all callers. Do not recompute topological order. Adjust allthrough edges following a degenerate conditional jump. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c
[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518 --- Comment #15 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 06:52:33 UTC --- Author: abel Date: Thu Apr 7 06:52:29 2011 New Revision: 172079 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172079 Log: Backport from mainline 2010-11-18 Alexander Monakov amona...@ispras.ru PR middle-end/46518 * sel-sched-ir.c (init_expr): Use the correct type for target_available. * sel-sched.c (fill_vec_av_set): Use explicitly signed char type. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c branches/gcc-4_5-branch/gcc/sel-sched.c
[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652 --- Comment #12 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 06:53:48 UTC --- Author: abel Date: Thu Apr 7 06:53:44 2011 New Revision: 172080 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172080 Log: Backport from mainline 2010-11-22 Alexander Monakov amona...@ispras.ru PR rtl-optimization/45652 * alias.c (get_reg_base_value): New. * rtl.h (get_reg_base_value): Add prototype. * sel-sched.c (init_regs_for_mode): Use it. Don't use registers with non-null REG_BASE_VALUE for renaming. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45652.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/alias.c branches/gcc-4_5-branch/gcc/rtl.h branches/gcc-4_5-branch/gcc/sel-sched.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/46602] [4.6 Regression] gcc.dg/pr42245-2.c ICE on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46602 --- Comment #3 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 06:54:25 UTC --- Author: abel Date: Thu Apr 7 06:54:23 2011 New Revision: 172081 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172081 Log: Backport from mainline 2010-11-25 Alexander Monakov amona...@ispras.ru PR rtl-optimization/46602 * sel-sched-ir.c (maybe_tidy_empty_bb): Move checking ... (tidy_control_flow): Here. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c
[Bug rtl-optimization/46585] [4.6 Regression] ICE: SIGSEGV in vinsn_create (sel-sched-ir.c:1189) with -fno-dce -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46585 --- Comment #10 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 06:56:50 UTC --- Author: abel Date: Thu Apr 7 06:56:47 2011 New Revision: 172082 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172082 Log: Backport from mainline 2010-11-25 Alexander Monakov amona...@ispras.ru PR rtl-optimization/46585 * sel-sched-ir.c (return_regset_to_pool): Verify that RS is not NULL. (vinsn_init): Skip computation of dependencies for local NOPs. (vinsn_delete): Don't try to free regsets for local NOPs. (setup_nop_and_exit_insns): Change definition of nop_pattern. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46585.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/45354] [4.6 regression] ICE with -fselective-scheduling and -freorder-blocks-and-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45354 --- Comment #12 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 06:58:31 UTC --- Author: abel Date: Thu Apr 7 06:58:29 2011 New Revision: 172083 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172083 Log: Backport from mainline 2010-12-03 Alexander Monakov amona...@ispras.ru PR rtl-optimization/45354 * sel-sched-ir.c (jump_leads_only_to_bb_p): Rename to ... (bb_has_removable_jump_to_p): This. Update all callers. Make static. Allow BBs ending with a conditional jump. Forbid EDGE_CROSSING jumps. * sel-sched-ir.h (jump_leads_only_to_bb_p): Delete prototype. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-prof/pr45354.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c branches/gcc-4_5-branch/gcc/sel-sched-ir.h branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #12 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 06:59:21 UTC --- Author: abel Date: Thu Apr 7 06:59:19 2011 New Revision: 172084 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172084 Log: Backport from mainline 2010-12-07 Andrey Belevantsev a...@ispras.ru PR target/43603 * haifa-sched.c (sched_create_recovery_edges): Update dominator info. * sel-sched-ir.c (maybe_tidy_empty_bb): Update dominator info after deleting an empty block. (tidy_control_flow): Also verify dominators. (sel_remove_bb): Update dominator info after removing a block. (sel_redirect_edge_and_branch_force): Assert that no unreachable blocks will be created. Update dominator info. (sel_redirect_edge_and_branch): Update dominator info when basic blocks do not become unreachable. (sel_remove_loop_preheader): Update dominator info. 2010-10-14 Andrey Belevantsev a...@ispras.ru * sel-sched-ir.c (maybe_tidy_empty_bb): Simplify comment. (tidy_control_flow): Tidy vertical space. (sel_remove_bb): New variable idx. Use it to remember the basic block index before deleting the block. (sel_remove_empty_bb): Remove dead code, simplify and insert to ... (sel_merge_blocks): ... here. * sel-sched-ir.h (sel_remove_empty_bb): Remove prototype. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/opt/pr46640.C branches/gcc-4_5-branch/gcc/testsuite/gcc.target/ia64/pr43603.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/haifa-sched.c branches/gcc-4_5-branch/gcc/sel-sched-ir.c branches/gcc-4_5-branch/gcc/sel-sched-ir.h branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/46875] [4.6 Regression] ICE: verify_flow_info failed: too many outgoing branch edges from bb 3 with -Os -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46875 --- Comment #5 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:00:15 UTC --- Author: abel Date: Thu Apr 7 07:00:10 2011 New Revision: 172085 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172085 Log: Backport from mainline 2010-12-14 Alexander Monakov amona...@ispras.ru PR rtl-optimization/46875 * sched-vis.c (print_pattern): Dump sequence for ADDR_VECs. * sel-sched-ir.c (bb_has_removable_jump_to_p): Forbid table jumps. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46875.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sched-vis.c branches/gcc-4_5-branch/gcc/sel-sched-ir.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/46649] [4.6 Regression] ICE: in move_bb_info, at sel-sched-ir.c:5080 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46649 --- Comment #10 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:01:30 UTC --- Author: abel Date: Thu Apr 7 07:01:25 2011 New Revision: 172086 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172086 Log: Backport from mainline 2010-12-15 Alexander Monakov amona...@ispras.ru PR rtl-optimization/46649 * sel-sched-ir.c (purge_empty_blocks): Unconditionally skip the first basic block in the region. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/opt/pr46649.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/47036] [4.6 Regression] ICE: in move_cond_jump, at sel-sched.c:4901 with -fschedule-insns -fselective-scheduling -fno-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47036 --- Comment #4 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:02:40 UTC --- Author: abel Date: Thu Apr 7 07:02:34 2011 New Revision: 172087 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172087 Log: Backport from mainline 2010-12-24 Alexander Monakov amona...@ispras.ru PR rtl-optimization/47036 * sel-sched-ir.c (fallthru_bb_of_jump): Remove special support for unconditional jumps. * sel-sched.c (moveup_expr): Ditto. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/opt/pr47036.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c branches/gcc-4_5-branch/gcc/sel-sched.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/46521] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 with -Os -fselective-scheduling2 -fsel-sched-pipelining -fprofile-generate -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46521 --- Comment #5 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:04:10 UTC --- Author: abel Date: Thu Apr 7 07:04:02 2011 New Revision: 172088 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172088 Log: Backport from mainline 2011-01-13 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45352 * sel-sched.c: Update copyright years. (reset_sched_cycles_in_current_ebb): Also recheck the DFA state in the advancing loop when we have issued issue_rate insns. Backport from mainline 2010-12-22 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45352 PR rtl-optimization/46521 PR rtl-optimization/46522 * sel-sched.c (reset_sched_cycles_in_current_ebb): Recheck the DFA state on the last iteration of the advancing loop. (sel_sched_region_1): Propagate the rescheduling bit to the next block also for empty blocks. Backport from mainline 2010-11-08 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45352 * sel-sched.c (find_best_expr): Do not set pneed_stall when the variable_issue hook is not implemented. (fill_insns): Remove dead variable stall_iterations. (init_seqno_1): Force EBB start for resetting sched cycles on any successor blocks of the rescheduled region. (sel_sched_region_1): Use bitmap_bit_p instead of bitmap_clear_bit. (reset_sched_cycles_in_current_ebb): Add debug printing. New variable issued_insns. Advance state when we have issued issue_rate insns. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352-3.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46521.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46522.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45352-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45352-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45352.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/46522] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 with -O3 -fsel-sched-pipelining -fselective-scheduling2 -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46522 --- Comment #6 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:04:10 UTC --- Author: abel Date: Thu Apr 7 07:04:02 2011 New Revision: 172088 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172088 Log: Backport from mainline 2011-01-13 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45352 * sel-sched.c: Update copyright years. (reset_sched_cycles_in_current_ebb): Also recheck the DFA state in the advancing loop when we have issued issue_rate insns. Backport from mainline 2010-12-22 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45352 PR rtl-optimization/46521 PR rtl-optimization/46522 * sel-sched.c (reset_sched_cycles_in_current_ebb): Recheck the DFA state on the last iteration of the advancing loop. (sel_sched_region_1): Propagate the rescheduling bit to the next block also for empty blocks. Backport from mainline 2010-11-08 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45352 * sel-sched.c (find_best_expr): Do not set pneed_stall when the variable_issue hook is not implemented. (fill_insns): Remove dead variable stall_iterations. (init_seqno_1): Force EBB start for resetting sched cycles on any successor blocks of the rescheduled region. (sel_sched_region_1): Use bitmap_bit_p instead of bitmap_clear_bit. (reset_sched_cycles_in_current_ebb): Add debug printing. New variable issued_insns. Advance state when we have issued issue_rate insns. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352-3.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46521.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46522.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45352-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45352-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45352.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352 --- Comment #29 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:04:09 UTC --- Author: abel Date: Thu Apr 7 07:04:02 2011 New Revision: 172088 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172088 Log: Backport from mainline 2011-01-13 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45352 * sel-sched.c: Update copyright years. (reset_sched_cycles_in_current_ebb): Also recheck the DFA state in the advancing loop when we have issued issue_rate insns. Backport from mainline 2010-12-22 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45352 PR rtl-optimization/46521 PR rtl-optimization/46522 * sel-sched.c (reset_sched_cycles_in_current_ebb): Recheck the DFA state on the last iteration of the advancing loop. (sel_sched_region_1): Propagate the rescheduling bit to the next block also for empty blocks. Backport from mainline 2010-11-08 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/45352 * sel-sched.c (find_best_expr): Do not set pneed_stall when the variable_issue hook is not implemented. (fill_insns): Remove dead variable stall_iterations. (init_seqno_1): Force EBB start for resetting sched cycles on any successor blocks of the rescheduled region. (sel_sched_region_1): Use bitmap_bit_p instead of bitmap_clear_bit. (reset_sched_cycles_in_current_ebb): Add debug printing. New variable issued_insns. Advance state when we have issued issue_rate insns. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352-3.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45352.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46521.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46522.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45352-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45352-2.c branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45352.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/48144] ICE: in code_motion_path_driver, at sel-sched.c:6575 with -fselective-scheduling2 and custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48144 --- Comment #6 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:05:19 UTC --- Author: abel Date: Thu Apr 7 07:05:16 2011 New Revision: 172089 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172089 Log: Backport from mainline 2011-03-26 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/48144 * sel-sched-ir.c (merge_history_vect): Factor out from ... (merge_expr_data): ... here. (av_set_intersect): Rename to av_set_code_motion_filter. Update all callers. Call merge_history_vect when an expression is found in both sets. * sel-sched-ir.h (av_set_code_motion_filter): Add prototype. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr48144.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-ir.c branches/gcc-4_5-branch/gcc/sel-sched-ir.h branches/gcc-4_5-branch/gcc/sel-sched.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:09:33 UTC --- Fixed on 4.5.
[Bug rtl-optimization/48215] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1268 on IA-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48215 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:15:53 UTC --- I have backported the patch for PR 46518 to 4.5, so fixed.
[Bug rtl-optimization/48442] ICE: in init_seqno, at sel-sched.c:6767 with -Os -fselective-scheduling2 --param max-sched-extend-regions-iters=100
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added CC||abel at gcc dot gnu.org --- Comment #3 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:18:04 UTC --- (In reply to comment #2) Confirmed. The 4.4/4.5 failure is most likely a dup of PR 46204. The 4.6/4.7 I have ported PR 46204 to 4.5, so we need to recheck there and probably port your patch to 4.5 too.
[Bug target/48273] [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added CC||abel at gcc dot gnu.org --- Comment #6 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 07:25:19 UTC --- (In reply to comment #5) + current_loop_nest != NULL + /* Check that there is at least one exit. */ + current_loop_nest-exits-next-e); This exposes loop optimizer internals, so please add a helper to cfgloop.c instead.
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||irar at gcc dot gnu.org
Resolution|INVALID |
Summary|[4.6 regression]|[4.6/4.7 regression]
|miscompilation at -O3 |miscompilation at -O3
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07
07:44:18 UTC ---
I'd say that is a vectorization bug then. Either it shouldn't vectorize it at
all, or needs to ensure unaligned vector loads (resp. stores) are used
everywhere.
Short testcase:
typedef unsigned int U __attribute__((__aligned__ (1), __may_alias__));
__attribute__((noinline, noclone)) unsigned int
foo (const char *s, int len)
{
const U *p = (const U *) s;
unsigned int f = len / sizeof (unsigned int), hash = len, i;
for (i = 0; i f; ++i)
hash += *p++;
return hash;
}
char buf[64] __attribute__((aligned (32)));
int
main (void)
{
return foo (buf + 1, 26);
}
[Bug rtl-optimization/48374] ICE: in single_succ_edge, at basic-block.h:562 with -fselective-scheduling2 and __builtin_unreachable()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48374
Andrey Belevantsev abel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.04.07 07:45:54
CC||abel at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |abel at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07
07:45:54 UTC ---
Confirmed, yet another case when we don't expect a block with zero successors.
The following fixes the problem.
Btw, --param max-sched-extend-regions-iters=2 is enough to reproduce the bug.
Zdenek, for most functions you don't want more than two iterations (you can see
the comment in sched-rgn.c:1248, so in your experiments you can limit it to not
more than 5-10. You actually need a positive value for the region extension
code to fire though.
diff --git a/gcc/sel-sched-ir.h b/gcc/sel-sched-ir.h
index 5516da9..13af1b5 100644
--- a/gcc/sel-sched-ir.h
+++ b/gcc/sel-sched-ir.h
@@ -1119,7 +1119,8 @@ get_all_loop_exits (basic_block bb)
/* If bb is empty, and we're skipping to loop exits, then
consider bb as a possible gate to the inner loop now. */
while (sel_bb_empty_or_nop_p (bb)
- in_current_region_p (bb))
+ in_current_region_p (bb)
+ EDGE_COUNT (bb-succs) 0)
{
bb = single_succ (bb);
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #18 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-04-07 07:59:00 UTC --- (In reply to comment #15) ld: 0711-596 SEVERE ERROR: Object expand.o An RLD for section 2 (.data) refers to symbol 852, but the storage class of the symbol is not C_EXT or C_HIDEXT. I got this when I tried to build GNU's make on 5.3 TL10 SP02 with just the assembler APAR. I tried two versions of GCC: 4.2.0 and 4.5.2. IBM is aware of the issue (via me and others). The last tidbit I have is that it appears as if it is another assembler bug but that is not confirmed yet. I don't have a fix nor do I have an APAR number yet. Looks like this one is it: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #13 from Ira Rosen irar at il dot ibm.com 2011-04-07 08:00:23 UTC --- The vectorizer uses loop peeling to align the loads from *p (by checking the address at the run time).
[Bug target/48273] [4.6/4.7 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273 --- Comment #7 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 08:00:28 UTC --- And some of our sel-sched-ir.h helpers can be moved to cfgloop.c as well (e.g. get_loop_exit_edges_unique_dests).
[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920 --- Comment #10 from vries at gcc dot gnu.org 2011-04-07 08:10:38 UTC --- Author: vries Date: Thu Apr 7 08:10:34 2011 New Revision: 172090 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172090 Log: 2011-04-07 Tom de Vries t...@codesourcery.com PR target/43920 * cfgcleanup.c (equal_different_set_p, can_replace_by, merge_dir): New function. (old_insns_match_p): Change return type. Replace return false/true with return dir_none/dir_both. Use can_replace_by. (flow_find_cross_jump): Add dir_p parameter. Init replacement direction from dir_p. Register replacement direction in dir, last_dir and afterlast_dir.Handle new return type of old_insns_match_p using merge_dir. Return replacement direction in dir_p. (flow_find_head_matching_sequence, outgoing_edges_match): Handle new return type of old_insns_match_p. (try_crossjump_to_edge): Add argument to call to flow_find_cross_jump. * ifcvt.c ( cond_exec_process_if_block): Add argument to call to flow_find_cross_jump. * basic-block.h (enum replace_direction): New type. (flow_find_cross_jump): Add parameter to declaration. Modified: trunk/gcc/ChangeLog trunk/gcc/basic-block.h trunk/gcc/cfgcleanup.c trunk/gcc/ifcvt.c
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07
08:20:30 UTC ---
Sure, but for types with user alignment smaller than their size, loop peeling
may often never be able to align it.
This regressed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=161797
What I mean is that for say unsigned int type with 32-bit alignment loop
peeling for valid code should always end up with correct alignment, but for
unsigned int with 8-bit alignment it can't. And e.g. i?86 long long is of the
same category, it has 64-bit size, but 32-bit alignment, so if you have a
pointer
to long long array, the whole array might be just 32-bit aligned, but not
64-bit,
then any kind of peeling will still result in misalignment.
__attribute__((noinline, noclone)) unsigned long long
foo (const char *s, int len)
{
const unsigned long long *p = (const unsigned long long *) s;
unsigned long long f = len / sizeof (unsigned long long), hash = len, i;
for (i = 0; i f; ++i)
hash += *p++;
return hash;
}
struct S
{
int i;
long long buf[64];
} s;
int
main (void)
{
return foo ((const char *) s.buf, 60);
}
works fine though (with -m32 -O3 -mavx or -m32 -O3 -msse4).
[Bug libfortran/48488] New: Wrong default format for real numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488 Summary: Wrong default format for real numbers Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net In write.c the intended default format for real numbers is documented as: /* Output a real number with default format. This is 1PG14.7E2 for REAL(4), 1PG23.15E3 for REAL(8), 1PG28.19E4 for REAL(10) and 1PG43.34E4 for REAL(16). */ // FX -- FIXME: should we change the default format for __float128-real(16)? This is reasonable, since it reflects the rounded-down number of decimal significant digits for each format: 7, 15, 19, 34. Thus any number with less decimal digits than the maximum precision always retains its original decimal value which is a useful feature. But it is implemented incorrectly as the following example shows: print (1PG14.7E2), .3_4 ! 0.300 print *, .3_4 ! 0.3001 expected 0.300 print (1PG23.15E3), .3_8 ! 0.300 print *, .3_8 ! 0.2 expected 0.300 print (1PG28.19E4), .3_10 ! 0.300 print *, .3_10 ! 0.3001 expected (s.a.) print (1PG43.34E4), .3_16 ! 0.3 print *, .3_16 ! 0.299 exp. (s.a)
[Bug c++/48446] [4.3/4.4/4.5/4.6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1946
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48446
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07
08:30:57 UTC ---
templatetypename T
struct A
{
~A ();
T *operator- () const;
};
struct B
{
typedef A B P;
static P foo (int);
};
struct C
{
typedef AC P;
static const int c = 80;
};
C::P bar ();
void
baz ()
{
char z[bar ()-c];
{
B::P m = B::foo (sizeof (z));
}
}
Yeah, apparently some problem on the FE side with cleanups, where
CLEANUP_POINT_EXPR already for z is given the cleanups for m, which are in a
nested bind though and thus m wasn't seen in bind expr yet.
[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920 --- Comment #11 from vries at gcc dot gnu.org 2011-04-07 08:35:27 UTC --- Author: vries Date: Thu Apr 7 08:35:23 2011 New Revision: 172091 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172091 Log: 2011-04-07 Tom de Vries t...@codesourcery.com PR target/43920 * cfgcleanup.c (walk_to_nondebug_insn): New function. (flow_find_cross_jump): Use walk_to_nondebug_insn. Recalculate bb1 and bb2. (try_crossjump_to_edge): Handle case that newpos1 or newpos2 is not src1 or src2. Redirect edges to the last basic block. Update frequency and count on multiple basic blocks in case of fallthru. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c
[Bug c++/48446] [4.3/4.4/4.5/4.6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1946
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48446 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07 08:36:41 UTC --- Most likely caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=128979 (r128750 works, r129000 ICEs, am lazy to bisect it exactly).
[Bug rtl-optimization/48272] internal compiler error: in setup_insn_reg_pressure_info, at haifa-sched.c:1124
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48272
Andrey Belevantsev abel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.04.07 08:48:57
CC||abel at gcc dot gnu.org,
||vmakarov at redhat dot com
Ever Confirmed|0 |1
--- Comment #2 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07
08:48:57 UTC ---
Confirmed (nice non-sensical set of options, btw.)
The problem is that register pressure code is not prepared for new insns
created during scheduling (for ia64, this is speculation checks and recovery
code). The ICE happens because we do not initialize register pressure
structures. The below patch seems to fix it, but I am not sure it is correct.
The patch calls setup_insn_reg_pressure_info (renamed to
init_insn_reg_pressure_info because there is the function with the same name in
haifa-sched.c) from within haifa_init_insn, where new instructions created
during scheduling are initialized. The patch does not call setup_insn_reg_uses
as sched_analyze_insn does, because there is no deps context at that point. If
some processing of this kind is desired, I guess we need to amend the functions
that copy/init dependencies for recovery code (that is, create_check_block_twin
and add_to_speculative_block). Finally, better name for
init_insn_reg_pressure_info should be devised.
Vlad, it would be great if you can advise me on how to improve the patch.
diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 30f55be..6908a11 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -5611,6 +5611,8 @@ haifa_init_insn (rtx insn)
/* Extend dependency caches by one element. */
extend_dependency_caches (1, false);
}
+ if (sched_pressure_p)
+init_insn_reg_pressure_info (insn);
}
/* Init data for the new basic block BB which comes after AFTER. */
diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c
index dcee019..393e651 100644
--- a/gcc/sched-deps.c
+++ b/gcc/sched-deps.c
@@ -1991,8 +1991,8 @@ mark_insn_reg_clobber (rtx reg, const_rtx setter, void
*data)
}
/* Set up reg pressure info related to INSN. */
-static void
-setup_insn_reg_pressure_info (rtx insn)
+void
+init_insn_reg_pressure_info (rtx insn)
{
int i, len;
enum reg_class cl;
@@ -2774,7 +2774,7 @@ sched_analyze_insn (struct deps_desc *deps, rtx x, rtx
insn)
if (sched_pressure_p)
{
setup_insn_reg_uses (deps, insn);
- setup_insn_reg_pressure_info (insn);
+ init_insn_reg_pressure_info (insn);
}
/* Add register dependencies for insn. */
diff --git a/gcc/sched-int.h b/gcc/sched-int.h
index d5add3b..d5c9509 100644
--- a/gcc/sched-int.h
+++ b/gcc/sched-int.h
@@ -1194,6 +1194,7 @@ extern void init_deps_global (void);
extern void finish_deps_global (void);
extern void deps_analyze_insn (struct deps_desc *, rtx);
extern void remove_from_deps (struct deps_desc *, rtx);
+extern void init_insn_reg_pressure_info (rtx);
extern dw_t get_dep_weak_1 (ds_t, ds_t);
extern dw_t get_dep_weak (ds_t, ds_t);
[Bug c++/48446] [4.3/4.4/4.5/4.6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1946
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48446 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07 08:55:37 UTC --- Actually now verified that it is r128979.
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #15 from Ira Rosen irar at il dot ibm.com 2011-04-07 09:00:43 UTC --- (In reply to comment #14) Sure, but for types with user alignment smaller than their size, loop peeling may often never be able to align it. This regressed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=161797 This patch only allowed peeling for loads. So the problem existed for stores before this revision. What I mean is that for say unsigned int type with 32-bit alignment loop peeling for valid code should always end up with correct alignment, but for unsigned int with 8-bit alignment it can't. And e.g. i?86 long long is of the same category, it has 64-bit size, but 32-bit alignment, so if you have a pointer to long long array, the whole array might be just 32-bit aligned, but not 64-bit, then any kind of peeling will still result in misalignment. The vectorizer calls builtin_vector_alignment_reachable in case of unknown alignment to verify that the access is naturally aligned. (i?86 doesn't implement this builtin and uses the default implementation). There is PR 42652 for a similar problem. Thanks, Ira
[Bug libfortran/48488] Wrong default format for real numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-04-07 09:08:01 UTC --- In write.c the intended default format for real numbers is documented as: /* Output a real number with default format. This is 1PG14.7E2 for REAL(4), 1PG23.15E3 for REAL(8), 1PG28.19E4 for REAL(10) and 1PG43.34E4 for REAL(16). */ // FX -- FIXME: should we change the default format for __float128-real(16)? This is reasonable, since it reflects the rounded-down number of decimal significant digits for each format: 7, 15, 19, 34. Thus any number with less decimal digits than the maximum precision always retains its original decimal value which is a useful feature. I think the error is in the documentation: the actual formats are 1PG16.8E2 for REAL(4), 1PG26.17E3 for REAL(8), 1PG30.20E4 for REAL(10) and 1PG45.35E4 for REAL(16) as shown by the following modified test print (1PG16.8E2), .3_4 print *, .3_4 print (1PG26.17E3), .3_8 print *, .3_8 print (1PG30.20E4), .3_10 print *, .3_10 print *, x10 print (1PG45.35E4), .3_16 print *, .3_16 end that gives 0.3001 0.3001 0.2 0.2 0.3001 0.3001 0.299 0.299 The values 8, 17, 20, and 35 (?see FIXME) are chosen such that reading the default output will always returns the original value up to the last bit. There is a test in the test suite checking that, but AFAIK not for all supported reals, in particular I don't think this has been tested for REAL(16).
[Bug tree-optimization/48484] [4.7 Regression] ICE: vector VEC(use_pred_info_t,base) index domain error, in pred_chain_length_cmp at tree-ssa-uninit.c:1626 with -Wuninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48484 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||xinliangli at gmail dot com Target Milestone|--- |4.7.0
[Bug libmudflap/48485] mudflap don't discover mistake - negative one index on static array i.e. a[-1]=b;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.04.07 09:23:54 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-07 09:23:54 UTC --- Testcase?
[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920 --- Comment #12 from vries at gcc dot gnu.org 2011-04-07 09:28:15 UTC --- Author: vries Date: Thu Apr 7 09:28:11 2011 New Revision: 172093 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172093 Log: 2011-04-07 Tom de Vries t...@codesourcery.com PR target/43920 * lib/scanasm.exp (object-size): New proc. * gcc.target/arm/pr43920-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr43920-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/scanasm.exp
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07
09:34:36 UTC ---
So perhaps:
bool
default_builtin_vector_alignment_reachable (const_tree type, bool is_packed)
{
- if (is_packed)
+ if (is_packed || (TYPE_USER_ALIGN (type) compare_tree_int (TYPE_SIZE
(type), TYPE_ALIGN (type)) == 1)
return false;
and similarly in rs6000 and other hooks?
BTW, tree_int_cst_compare (TYPE_SIZE (type), bitsize_int (POINTER_SIZE))
in the default hook probably should be compare_tree_int too.
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|REOPENED|NEW CC||rguenth at gcc dot gnu.org --- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-07 09:35:08 UTC --- Confirmed. Peeling for alignment is pointless if the access isn't at least aligned to the natural alignment of the vector element.
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-07
09:39:13 UTC ---
(In reply to comment #16)
So perhaps:
bool
default_builtin_vector_alignment_reachable (const_tree type, bool is_packed)
{
- if (is_packed)
+ if (is_packed || (TYPE_USER_ALIGN (type) compare_tree_int (TYPE_SIZE
(type), TYPE_ALIGN (type)) == 1)
return false;
and similarly in rs6000 and other hooks?
BTW, tree_int_cst_compare (TYPE_SIZE (type), bitsize_int (POINTER_SIZE))
in the default hook probably should be compare_tree_int too.
I think rather tree-vect-data-refs.c:vector_alignment_reachable_p should
be adjusted. These packed checks in the target hooks don't make any
sense to me either. In fact, I fail to see the point of a target hook
completely (if it isn't maybe just for cost issues).
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-07 09:41:55 UTC --- (In reply to comment #7) The example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483#c2 shows a compiler bug. No it doesn't. TYPE VARIABLE [ARGUMENT-TO-CONSTRUCT] The compiler must doing like this: 1. Compile ARGUMENT-TO-CONSTRUCT 2. Checking of TYPE 3. VARIABLE declaration No, the variable is in scope after its identifier, so it can be used in the initializer expression, e.g. int i = sizeof(i); // ok int i = i+1; // not ok The BIG mistake is declaration of VARIABLE from wrong position. No, C++ does not work the way you think it does. It's not a bug. It would be nice to get a warning, but it's not easy to do that.
[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920 --- Comment #13 from vries at gcc dot gnu.org 2011-04-07 09:48:42 UTC --- Author: vries Date: Thu Apr 7 09:48:39 2011 New Revision: 172094 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172094 Log: 2011-04-07 Tom de Vries t...@codesourcery.com PR target/43920 * cfgcleanup.c (try_crossjump_to_edge): Add dir parameter. Pass dir to flow_find_cross_jump. Swap variables to implement backward replacement. (try_crossjump_bb): Add argument to try_crossjump_to_edge. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #19 from Ira Rosen irar at il dot ibm.com 2011-04-07 09:55:44 UTC --- (In reply to comment #18) I think rather tree-vect-data-refs.c:vector_alignment_reachable_p should be adjusted. These packed checks in the target hooks don't make any sense to me either. Yes, I think this can be moved to vector_alignment_reachable_p. In fact, I fail to see the point of a target hook completely (if it isn't maybe just for cost issues). There are some target specific checks in rs6000.c and arm.c.
[Bug libmudflap/48485] mudflap don't discover mistake - negative one index on static array i.e. a[-1]=b;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485 --- Comment #2 from konst krasutug at mail dot ru 2011-04-07 10:04:07 UTC --- Created attachment 23907 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23907 main.c
[Bug libmudflap/48485] mudflap don't discover mistake - negative one index on static array i.e. a[-1]=b;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485 --- Comment #3 from konst krasutug at mail dot ru 2011-04-07 10:08:59 UTC --- gcc -fmudflap main.c -lmudflap -o main ./main and nothing, but if I do 'a[-2]=c;' in main.c and compile it then the mistake is discovered by following output: *** mudflap violation 1 (check/write): time=1302170495.754005 ptr=0x7fff720f68f0 size=18446744073709551396 pc=0x7f5975684391 location=`main.c:5:8 (main)' /usr/lib64/libmudflap.so.0(__mf_check+0x41) [0x7f5975684391] ./main(main+0xa0) [0x400a64] /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f597532bbfd] Nearby object 1: checked region begins 0B into and ends 2381354758B after mudflap object 0x706ea0: name=`main.c:2:6 (main) a' bounds=[0x7fff720f68f0,0x7fff720f68f9] size=10 area=stack check=0r/3w liveness=3 alloc time=1302170495.753888 pc=0x7f5975683791 Nearby object 2: checked region begins 280B before and ends 2381354472B after mudflap object 0x702370: name=`argv[]' bounds=[0x7fff720f6a08,0x7fff720f6a17] size=16 area=static check=0r/3w liveness=3 alloc time=1302170495.753853 pc=0x7f5975683791 Nearby object 3: checked region begins 296B before and ends 2381353720B after mudflap object 0x706ab0: name=`environ[]' bounds=[0x7fff720f6a18,0x7fff720f6d07] size=752 area=static check=0r/3w liveness=3 alloc time=1302170495.753885 pc=0x7f5975683791 number of nearby objects: 97 = This is my system versions: = uname --all Linux home 2.6.37.1-1.2-desktop #1 SMP PREEMPT 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 GNU/Linux == gcc -v Используются внутренние спецификации. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.5.2/lto-wrapper Целевая архитектура: x86_64-suse-linux Параметры конфигурации: ./configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++ --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --enable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --enable-gold --with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Модель многопоточности: posix gcc версия 4.5.2 20101208 (prerelease) [gcc-4_5-branch revision 167585] (SUSE Linux)
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #20 from rguenther at suse dot de rguenther at suse dot de 2011-04-07 10:24:45 UTC --- On Thu, 7 Apr 2011, irar at il dot ibm.com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #19 from Ira Rosen irar at il dot ibm.com 2011-04-07 09:55:44 UTC --- (In reply to comment #18) I think rather tree-vect-data-refs.c:vector_alignment_reachable_p should be adjusted. These packed checks in the target hooks don't make any sense to me either. Yes, I think this can be moved to vector_alignment_reachable_p. In fact, I fail to see the point of a target hook completely (if it isn't maybe just for cost issues). There are some target specific checks in rs6000.c and arm.c. I saw them, but I can't see what the difference is between aligned and aligned ;) Either the targets have aligned loads or they don't. We can target independently check whether we can for example reach 16-byte alignment - in which cases is it then we can't reach that alignment anyway due to target issues?
[Bug libmudflap/48485] mudflap don't discover mistake - negative one index on static array i.e. a[-1]=b;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-07 10:50:10 UTC --- It works for me. /tmp /space/rguenther/install/gcc-4.5.2/bin/gcc -fmudflap t.c -lmudflap -o t /tmp ./t *** mudflap violation 1 (check/write): time=1302173318.008878 ptr=0x7fffde10 size=18446744073709551396 pc=0x77a3dcb1 location=`t.c:5:8 (main)' /usr/lib64/libmudflap.so.0(__mf_check+0x41) [0x77a3dcb1] ./t(main+0xa0) [0x400a64] /lib64/libc.so.6(__libc_start_main+0xe6) [0x776f9586] Nearby object 1: checked region begins 0B into and ends 8678B after mudflap object 0x706960: name=`t.c:2:6 (main) a' bounds=[0x7fffde10,0x7fffde19] size=10 area=stack check=0r/3w liveness=3 alloc time=1302173318.008431 pc=0x77a3d3f1 Nearby object 2: checked region begins 264B before and ends 8408B after mudflap object 0x702370: name=`argv[]' bounds=[0x7fffdf18,0x7fffdf27] size=16 area=static check=0r/3w liveness=3 alloc time=1302173318.008116 pc=0x77a3d3f1 Nearby object 3: checked region begins 280B before and ends 7712B after mudflap object 0x706570: name=`environ[]' bounds=[0x7fffdf28,0x7fffe1df] size=696 area=static check=0r/3w liveness=3 alloc time=1302173318.008412 pc=0x77a3d3f1 number of nearby objects: 90 Note that openSUSE has libmudflap disabled, so I wonder how it even compiles and links for you ;)
[Bug libmudflap/48485] mudflap don't discover mistake - negative one index on static array i.e. a[-1]=b;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48485 --- Comment #5 from konst krasutug at mail dot ru 2011-04-07 11:01:30 UTC --- Note that openSUSE has libmudflap disabled, so I wonder how it even compiles and links for you ;) Yes, I downloaded src.rpm, compiled it (gcc and mudflap) and make install
[Bug libfortran/48488] Wrong default format for real numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48488
--- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net
2011-04-07 11:22:49 UTC ---
Ok, now I found that this was changed in
http://gcc.gnu.org/viewcvs?view=revisionrevision=128967
The testcase says:
! This tests that the default formats for formatted I/O of reals are
! wide enough and have enough precision, by checking that values can
! be written and read back.
However, the selected width in the current version (8, 17, 20, 35) is not big
enough to guarantee that. See IEEE 754/2008:
For the purposes of discussing the limits on correctly rounded conversion,
define the following quantities:
...
― for binary32, Pmin(binary32) = 9
― for binary64, Pmin(binary64) = 17
― for binary128, Pmin(binary128) = 36
― for all other binary formats bf, Pmin(bf) = 1 + ceiling(p×log10(2)), where
p is the number of significant bits in bf
...
Conversions from a supported binary format bf to an external character sequence
and back again results in a copy of the original number so long as there are at
least Pmin(bf) significant digits specified and the rounding-direction
attributes in effect during the two conversions are round to nearest
rounding-direction attributes.
I see two possibilities:
A. We aim to make the default format useful for human readers, so that e.g. 0.3
is always represented as 0.3000...
In that case we must choose P(bf) = floor(p×log10(2))
P = {7, 15, 19, 34}
B. We aim to make the default format useful for round-trip conversion, so that
a binary value is always converted to the same binary value.
In that case we must choose P(bf) = 1 + ceiling(p×log10(2))
P = {9, 17, 21, 36}
I personally prefer A.
Currently the values are sort of in the middle (except for real64).
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #21 from Ira Rosen irar at il dot ibm.com 2011-04-07 11:37:29 UTC --- (In reply to comment #20) I saw them, but I can't see what the difference is between aligned and aligned ;) Either the targets have aligned loads or they don't. We can target independently check whether we can for example reach 16-byte alignment - in which cases is it then we can't reach that alignment anyway due to target issues? What kind of target independent check do you have in mind? I guess this hook was added because such check is hard to implement. Here is the discussion about adding it http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00082.html.
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #11 from Joel Sherrill joel at gcc dot gnu.org 2011-04-07 11:44:54 UTC --- In both cases, I built gcc + newlib multilib + rtems multilib to ensure the entire software base was built with and without the patch. $ m68k-rtems4.11-gcc --version m68k-rtems4.11-gcc (GCC) 4.6.1 20110329 (prerelease) Without patch.. results are at: http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000516.html http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00525.html === gcc Summary === # of expected passes67228 # of unexpected failures386 # of expected failures121 # of unresolved testcases77 # of unsupported tests1095 === g++ Summary === # of expected passes24705 # of unexpected failures720 # of expected failures162 # of unsupported tests449 With the patch ... results are at: http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000517.html http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00533.html === gcc Summary === # of expected passes67231 # of unexpected failures383 # of expected failures121 # of unresolved testcases77 # of unsupported tests1095 === g++ Summary === # of expected passes24705 # of unexpected failures720 # of expected failures162 # of unsupported tests449 It looks like it didn't make anything worse and fixed 3 C tests. :-D I think this should be committed to the 4.6 branch and head. If you like, we can repeat the experiment on the 4.5 branch if that is desired. FWIW I would be happy to help run down some of the failure cases if someone is interested in trying to fix them. :-D
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07 11:45:57 UTC --- When would compare_tree_int (TYPE_SIZE (type), TYPE_ALIGN (type)) = 0 give not what you are looking for?
[Bug c++/48489] New: Invalid error message 'has no member named' when referring directly to the base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48489
Summary: Invalid error message 'has no member named' when
referring directly to the base class
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ethou...@gmail.com
Created attachment 23908
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23908
Short C++ code that reproduces the problem.
There is one case, having that:
struct Base { };
struct Concrete: Base { void setValue( string, string ); };
and using:
v-BaseType::setValue( this-name, this-value );
[with template parameter BaseType = Base]
generates the following error:
newmpl.cc:37:35: error: ‘struct Concrete’ has no member named ‘setValue’
which is a lie, because Concrete::setValue exists. The mistaken here is the
name of the class that does not have given member, which should be ‘struct
Base’ here, because this call refers directly to the given class (not to the
'v' pointer's class).
Please find the reproduction example in attachment (no dependencies but C++
standard library). You can see that the 'Base' class has 'setValue' commented
out in order to make this error occur.
The same behavior is with the latest version, gcc 4.7.0.
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #23 from Ira Rosen irar at il dot ibm.com 2011-04-07 12:02:46 UTC --- Well, it's hard to accept such an easy solution when the original patch has hundreds of rows ;) So, you think that Index: tree-vect-data-refs.c === --- tree-vect-data-refs.c (revision 172019) +++ tree-vect-data-refs.c (working copy) @@ -1110,12 +1110,9 @@ vector_alignment_reachable_p (struct dat if (ba) is_packed = contains_packed_reference (ba); - if (vect_print_dump_info (REPORT_DETAILS)) - fprintf (vect_dump, Unknown misalignment, is_packed = %d,is_packed); - if (targetm.vectorize.vector_alignment_reachable (type, is_packed)) - return true; - else - return false; + if (is_packed + || compare_tree_int (TYPE_SIZE (type), TYPE_ALIGN (type)) 0) +return false; } return true; is enough, and we can just get rid of vector_alignment_reachable? Thanks, Ira
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 Bernd Schmidt bernds at gcc dot gnu.org changed: What|Removed |Added Attachment #23890|0 |1 is obsolete|| --- Comment #12 from Bernd Schmidt bernds at gcc dot gnu.org 2011-04-07 12:03:48 UTC --- Created attachment 23909 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23909 Better fix Sorry to do this to you, but can you test this one? I looked at the code again a bit more closely and I believe the previous patch was incorrect :-(
[Bug rtl-optimization/48144] ICE: in code_motion_path_driver, at sel-sched.c:6575 with -fselective-scheduling2 and custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48144 --- Comment #7 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 12:07:29 UTC --- Author: abel Date: Thu Apr 7 12:07:24 2011 New Revision: 172097 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172097 Log: Backport from mainline 2011-03-26 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/48144 * sel-sched-ir.c (merge_history_vect): Factor out from ... (merge_expr_data): ... here. (av_set_intersect): Rename to av_set_code_motion_filter. Update all callers. Call merge_history_vect when an expression is found in both sets. * sel-sched-ir.h (av_set_code_motion_filter): Add prototype. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48144.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/sel-sched-ir.c branches/gcc-4_6-branch/gcc/sel-sched-ir.h branches/gcc-4_6-branch/gcc/sel-sched.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/48144] ICE: in code_motion_path_driver, at sel-sched.c:6575 with -fselective-scheduling2 and custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48144 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Andrey Belevantsev abel at gcc dot gnu.org 2011-04-07 12:07:45 UTC --- Fixed.
[Bug c++/48481] C++ overloading memory hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48481 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07 12:16:23 UTC --- Haven't bootstrapped/regtested it, but it is definitely improvement. With N=1000 and N=2000 the generated assembly is identical, for N=1000 reported TOTAL went down from 432768 kB to 89362 kB, for N=2000 from 1672544 kB to 298232 kB and on a box with 8GB of RAM I can compile even N=5000 case, which takes 1685817 kB reported TOTAL memory. N=1 requires already too much RAM though. In the -DN=5000 -fmem-report dump the only interesting allocations are: cp/tree.c:1447 (ovl_cons)160016:97.9% 0: 0.0%1280032: 2.0% 0: 0.0% 50045001 Total1634296366 38329920 65115511 11401989 51377483 source location GarbageFreed Leak OverheadTimes so if even that garbage could be freed, this would be fixed completely. Even for N=1000 ovl_cons is the only one that really matters: cp/tree.c:1447 (ovl_cons) 64032000:90.2% 0: 0.0% 256032: 1.8% 0: 0.0%2009001 Total 71012606 8986384 14294815 2724053 2289400 source location GarbageFreed Leak OverheadTimes Those ovl_cons calls are from lookup_arg_dependent - ... - add_function - build_overload. Is it guaranteed that perform_koenig_lookup, if it returns a chain of OVERLOADs, all OVERLOADs have been freshly make_noded and aren't shared with anything else? If yes, perhaps we could afterwards ggc_free the chain, or move it to some cache of OVERLOAD nodes and make ovl_cons start from that cache.
[Bug c++/48490] New: delete with template convertion operator does overload resolution for class operands, but shouldn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48490
Summary: delete with template convertion operator does
overload resolution for class operands, but shouldn't.
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp
GCC accepts following code. But it should be reject.
testcase.C
struct S
{
template typename T
operator T *() { return 0; }
};
int main()
{
S s;
delete s;
}
All of following versions accept it.
Ubuntu/Linaro 4.4.4-14ubuntu5
4.5.2
4.5.3 20110217
4.6.0
4.6.1 20110310
4.7.0 20110405
[Bug c++/48491] New: ICE in delete with template convertion operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48491
Summary: ICE in delete with template convertion operator
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp
GCC becomes ICE with -flto option.
testcase.C
struct S
{
template typename T
operator T *() { return 0; }
};
int main()
{
S s;
delete s;
}
---
GCC outputs following error.
testcase.C: In function 'int main()':
testcase.C:10:12: warning: possible problem detected in invocation of delete
operator: [enabled by default]
testcase.C:10:12: warning: invalid use of template type parameter 'T' [enabled
by default]
testcase.C:10:12: note: neither the destructor nor the class-specific operator
delete will be called, even if they are declared when the class is defined
testcase.C: At top level:
testcase.C:11:1: internal compiler error: tree code 'template_type_parm' is not
supported in gimple streams
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
All of following versions become ICE.
4.5.2
4.5.3 20110217
4.6.0
4.6.1 20110310
4.7.0 20110405
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #24 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-07 12:42:48 UTC --- (In reply to comment #23) Well, it's hard to accept such an easy solution when the original patch has hundreds of rows ;) So, you think that Index: tree-vect-data-refs.c === --- tree-vect-data-refs.c (revision 172019) +++ tree-vect-data-refs.c (working copy) @@ -1110,12 +1110,9 @@ vector_alignment_reachable_p (struct dat if (ba) is_packed = contains_packed_reference (ba); - if (vect_print_dump_info (REPORT_DETAILS)) - fprintf (vect_dump, Unknown misalignment, is_packed = %d,is_packed); - if (targetm.vectorize.vector_alignment_reachable (type, is_packed)) - return true; - else - return false; + if (is_packed + || compare_tree_int (TYPE_SIZE (type), TYPE_ALIGN (type)) 0) +return false; } return true; is enough, and we can just get rid of vector_alignment_reachable? Yes, I think so. Richard. Thanks, Ira
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #25 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-07 12:44:35 UTC --- (In reply to comment #24) (In reply to comment #23) Well, it's hard to accept such an easy solution when the original patch has hundreds of rows ;) So, you think that Index: tree-vect-data-refs.c === --- tree-vect-data-refs.c (revision 172019) +++ tree-vect-data-refs.c (working copy) @@ -1110,12 +1110,9 @@ vector_alignment_reachable_p (struct dat if (ba) is_packed = contains_packed_reference (ba); - if (vect_print_dump_info (REPORT_DETAILS)) - fprintf (vect_dump, Unknown misalignment, is_packed = %d,is_packed); - if (targetm.vectorize.vector_alignment_reachable (type, is_packed)) - return true; - else - return false; + if (is_packed + || compare_tree_int (TYPE_SIZE (type), TYPE_ALIGN (type)) 0) +return false; } return true; is enough, and we can just get rid of vector_alignment_reachable? Yes, I think so. Even is_packed shouldn't be necessary, TYPE_ALIGN should better be correct (but IIRC it isn't for the FIELD_DECL types of packed struckts).
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07
12:48:12 UTC ---
int a = __alignof__ (double);
struct A { int b; double c; int d; } e;
int f = __alignof__ (e.c);
double *p;
int g = __alignof__ (*p);
int a2 = __alignof__ (long long);
struct A2 { int b; long long c; int d; } e2;
int f2 = __alignof__ (e2.c);
long long *p2;
int g2 = __alignof__ (*p2);
on powerpc64-linux unfortunately shows that the target hook is needed, at least
with -m64 -malign-power. Though, what the target hook does is definitely
weird:
if (TARGET_32BIT)
{
if (rs6000_alignment_flags == MASK_ALIGN_NATURAL)
return true;
if (rs6000_alignment_flags == MASK_ALIGN_POWER)
return true;
return false;
}
else
{
if (TARGET_MACHO)
return false;
/* Assuming that all other types are naturally aligned. CHECKME! */
return true;
}
I believe rs6000_alignment_flags can be either MASK_ALIGN_NATURAL, or
MASK_ALIGN_POWER, nothing else, so wonder why it just doesn't return true for
TARGET_32BIT. And, for TARGET_64BIT !TARGET_MACHO, clearly DFmode types
aren't naturally aligned with rs6000_alignment_flags == MASK_ALIGN_POWER.
Therefore I'd say it should return false for
TYPE_MODE (strip_array_types (type)) == DFmode !TARGET_ALIGN_NATURAL, at
least for Linux (rs6000 has unfortunately way too many ABIs and even more
target switches). For TARGET_MACHO, ADJUST_FIELD_ALIGN is
darwin.h:#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED)\
darwin.h- (TARGET_ALIGN_NATURAL ? (COMPUTED)\
darwin.h- : (COMPUTED) == 128 ? 128\
darwin.h- : MIN ((COMPUTED), 32))
thus I think it could use ADJUST_FIELD_ALIGN (NULL, TYPE_ALIGN (type)) ==
TYPE_ALIGN (type). And AIX is the same as Linux TARGET_64BIT, probably even
for 32-bit AIX though.
So, I think you want the compare_tree_int check in generic code (not sure if
is_packed isn't redundant with that check), plus a hook which will sometimes
tell you peeling won't necessarily align either.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #19 from Perry Smith pedzsan at gmail dot com 2011-04-07 12:55:19 UTC --- Yes. Thats the one. Dave, First, I believe this link is a public facing interface to Fix Central http://www.ibm.com/support/fixcentral/ (it came from google). If not, post back, and I'll try and find one. I *think* you can do instfix IZx or something to that effect and it will say yea or nah as to if you have the APAR. I don't know for sure. I usually go by fileset and VRMF levels like bos.foo 4.3.2.1. I assume you know that each TL has its own APAR for each problem so you have to look for sister APARs. Fix central is suppose to be smart enough to do that but I'm not sure about instfix. Also you did flip around some things. 5.3 TL10 SP03 has the problem SP05 has the first fix but not the second. For 5.3 TL12, SP02 has the first fix as IZ81341. Note that the two issues are very similar. The error number changed and that is what I key off of. You can do oslevel -s to get the service pack level that you have installed. The reason I put the link to fix central is IBM charges for support -- not updates. As far as I can tell, anyone can go to fix central and download any fix they want. Hope this helps
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #27 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-07
12:56:34 UTC ---
(In reply to comment #26)
int a = __alignof__ (double);
struct A { int b; double c; int d; } e;
int f = __alignof__ (e.c);
double *p;
int g = __alignof__ (*p);
int a2 = __alignof__ (long long);
struct A2 { int b; long long c; int d; } e2;
int f2 = __alignof__ (e2.c);
long long *p2;
int g2 = __alignof__ (*p2);
on powerpc64-linux unfortunately shows that the target hook is needed, at
least
with -m64 -malign-power.
You mean a != f in the above? That's the basic issue of stor-layout not
using properly aligned types for FIELD_DECL types (same issue for packed
structs). So you can't really use type alignment for memory references
but you have to use get_object_alignment friends. Same happens on
any target for non-packed but just custom (mis-)aligned struct types.
[Bug bootstrap/48492] New: [4.7 Regression] LTO bootstrap failure in copy_constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48492 Summary: [4.7 Regression] LTO bootstrap failure in copy_constant Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Created attachment 23910 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23910 broken patch ../configure --enable-languages=all,obj-c++,ada,lto,go --enable-checking=yes,rtl --with-build-config=bootstrap-lto make -j64 fails with: ../../gcc/ada/ali.ads:39:1: internal compiler error: in copy_constant, at varasm.c:3030 while linking gnatbind with -flto. The problem is related to streaming out and in DECL_IN_CONSTANT_POOL var decls, I guess in the original compilation it is streamed out normally, but when it is streamed in, tree_output_constant_def isn't called on the DECL_INITIAL, so it isn't registered with varpool and thus when streaming it out again, varpool_get_node returns NULL and we stream the decl with DECL_IN_CONSTANT_POOL set, but DECL_INITIAL being error_mark_node. When it is streamed in again, and expand_debug_expr calls mark_decl_rtl on it, it ICEs, because error_mark_node isn't a constant. I believe we need to stream DECL_IN_CONSTANT_POOL vars specially, basically stream just the constants from its DECL_INITIAL and have the stream reader call tree_output_constant_def for it. Tried to do this in attached patch, but probably it needs to be done slightly elsewhere, perhaps after after caching it or whatever. Not too familiar with the streamer...
[Bug c++/48489] Invalid error message 'has no member named' when referring directly to the base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48489
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.04.07 13:02:52
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-07
13:02:52 UTC ---
The attachment can be simplified to:
struct Base{ };
struct Concrete : Base
{
void setValue();
};
int main()
{
Concrete d;
d.Base::setValue();
}
which gives the error:
error: 'struct Concrete' has no member named 'setValue'
expected:
error: 'struct Base' has no member named 'setValue'
[Bug middle-end/48493] New: [ICE] in expand_expr_addr_expr_1, at expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493
Summary: [ICE] in expand_expr_addr_expr_1, at expr.c
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yuf...@gcc.gnu.org
CC: ja...@gcc.gnu.org, ram...@gcc.gnu.org
The arm gcc fails in compiling the following reproducible code:
-- CODE --
typedef long long T __attribute__((may_alias, aligned (1)));
struct S
{
_Complex float d __attribute__((aligned (8)));
};
void bar (struct S);
void
f1 (T x)
{
struct S s;
*(T *) ((char *) s.d + 1) = x;
bar (s);
}
-- CUT --
The following error message will be given when the above code is compiled with
options -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon -O1
(-O1 itself should be enough to reproduce the problem):
repro.c: In function 'f1':
repro.c:14:30: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:6922
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The test is derived from the regression test case gcc.dg/pr48335-2.c which was
added in r171855 (http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00047.html) on 1st
April. However, the compiler before the commit, and even the 4.6.1 compiler,
fails in the same way. FYI. the commit is a patch for bug 48335, in which the
'arm' target was not tested according to bug 48335, comment #6:
Created attachment 23818 [details]
gcc46-pr48335.patch
Updated patch, all the new tests now compile, on
i386/x86_64/ppc/ppc64/s390/s390x.
[Bug bootstrap/48492] [4.7 Regression] LTO bootstrap failure in copy_constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48492 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org, hubicka at gcc dot ||gnu.org Target Milestone|--- |4.7.0
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07
13:16:13 UTC ---
I mean a and g are 8 with -m64 -malign-power, but f is 4. If you do:
extern void abort (void);
struct S { long long x; int a; double b[1]; int c; } s;
double *p = s.b[0];
int
main ()
{
if (((long) p) (__alignof__ (*p) - 1))
abort ();
return 0;
}
I believe it will fail with -m64 -malign-power, and here it doesn't help at all
that you check get_object_alignment, because __alignof__ (*p) is still 8,
but
.comms,80016,8
...
p:
.quads+12
This isn't the default ABI for powerpc64-linux fortunately, but anyway.
But, the above fails on i?86 too (without non-default -malign-double).
So, we need some target hook that will tell us if ADJUST_FIELD_ALIGN could ever
lower alignment of the type when present in structs...
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 --- Comment #10 from Lisp2D lisp2d at lisp2d dot net 2011-04-07 13:19:16 UTC --- (In reply to comment #9) No, the variable is in scope after its identifier, so it can be used in the initializer expression, e.g. int i = sizeof(i); // ok int i = i+1; // not ok My opinion is that C habit rules here. In C int i=i+1; - int i; i=i+1; without constructors, objects e.t.c. This example will bring just a warning. In C++ Class i(i.Method()); eval i.Method() - construct with Class::Class(result) another order of calculation. (see comment 2) Must be an error. The answer of question gives the C++ standard. Show me this document.
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #29 from rguenther at suse dot de rguenther at suse dot de
2011-04-07 13:21:20 UTC ---
On Thu, 7 Apr 2011, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07
13:16:13 UTC ---
I mean a and g are 8 with -m64 -malign-power, but f is 4. If you do:
extern void abort (void);
struct S { long long x; int a; double b[1]; int c; } s;
double *p = s.b[0];
Here's a known type-inconsistency as well. Or it's even an
invalid testcase ...
int
main ()
{
if (((long) p) (__alignof__ (*p) - 1))
abort ();
return 0;
}
I believe it will fail with -m64 -malign-power, and here it doesn't help at
all
that you check get_object_alignment, because __alignof__ (*p) is still 8,
but
.comms,80016,8
...
p:
.quads+12
This isn't the default ABI for powerpc64-linux fortunately, but anyway.
But, the above fails on i?86 too (without non-default -malign-double).
So, we need some target hook that will tell us if ADJUST_FIELD_ALIGN could
ever
lower alignment of the type when present in structs...
Well. It's also wrong with
struct S { long long x; int a; double b[1]; int c; } s
__attribute__((aligned(4)));
double *p = s.b[0];
on x86_64. And honestly I'm not exactly sure if that situation is
different than the i?86 or ppc one or if it is just a bug in the
C standard that it allows this kind of alignment behavior (and
thus, a bug in the GCC extension that allows adjusting it).
Richard.
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-07
13:26:16 UTC ---
(In reply to comment #10)
The answer of question gives the C++ standard. Show me this document.
3.3.1 Point of declaration [basic.scope.decl]
1 The point of declaration for a name is immediately after its complete
declarator (clause 8) and before its initializer (if any), except as noted
below. [Example:
int x = 12;
{ int x = x; }
Here the second x is initialized with its own (indeterminate) value. ]
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #30 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07
13:29:15 UTC ---
This is certainly a valid testcase:
struct S { long long x; int a; double b[1]; int c; } s;
double *p = s.b[0];
int
foo (double *q)
{
int i, j = 0;
for (i = 0; i 1; i++)
j += *q++;
return j;
}
int
main (void)
{
return foo (p);
}
and without the target hook, vectorizer would think it can peel the loop and
get it naturally aligned (assuming it isn't inlined at least etc. to see that q
points to s.b[0] initially).
I think the bug is in the ABIs that do that kind of thing, but it is too late
to fix the ABIs up.
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-07 13:29:43 UTC --- For the example in comment 2 G++, EDG and Clang++ all accept it without warning. MSVC rejects it, but is wrong to do so.
[Bug middle-end/48335] [4.6/4.7 Regression] ICE in convert_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335 Yufeng Zhang yufeng at gcc dot gnu.org changed: What|Removed |Added CC||yufeng at gcc dot gnu.org --- Comment #10 from Yufeng Zhang yufeng at gcc dot gnu.org 2011-04-07 13:30:04 UTC --- (In reply to comment #6) Created attachment 23818 [details] gcc46-pr48335.patch Updated patch, all the new tests now compile, on i386/x86_64/ppc/ppc64/s390/s390x. Hi Jakub, The test gcc.dg/pr48335-2.c unfortunately fails in the arm-eabi testing with an ICE: gcc.dg/pr48335-2.c: In function 'f1': gcc.dg/pr48335-2.c:19:30: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6922 I've raised the bug 48493 for this. I'm not sure how it is related with this bugzilla as the compiler before your commit fails on the test as well. Cheers, Yufeng
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #31 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-07
13:35:04 UTC ---
(In reply to comment #30)
This is certainly a valid testcase:
struct S { long long x; int a; double b[1]; int c; } s;
double *p = s.b[0];
int
foo (double *q)
{
int i, j = 0;
for (i = 0; i 1; i++)
j += *q++;
return j;
}
int
main (void)
{
return foo (p);
}
and without the target hook, vectorizer would think it can peel the loop and
get it naturally aligned (assuming it isn't inlined at least etc. to see that
q
points to s.b[0] initially).
I think the bug is in the ABIs that do that kind of thing, but it is too late
to fix the ABIs up.
The question is what we should do in the middle-end. If the above would
happen for strict-alignment targets then *p would simply trap. The
only consistent way for the middle-end would be to simply assume all
pointer-to-doubles are only aligned to 4 bytes, thus use the minimal
alignment that can happen (without using GCC extensions).
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-07 13:38:11 UTC --- (In reply to comment #10) (In reply to comment #9) No, the variable is in scope after its identifier, so it can be used in the initializer expression, e.g. int i = sizeof(i); // ok int i = i+1; // not ok My opinion is that C habit rules here. In C int i=i+1; - int i; i=i+1; In C++ this can be written: int i(i+1); The initialization rules for C++ do without constructors, objects e.t.c. This example will bring just a warning. In C++ Class i(i.Method()); eval i.Method() - construct with Class::Class(result) Note that this is similar to: Class i = i.Method(); For the purposes of your complaint it's not relevant that it's a class with a constructor. Obviously i.Method() has to be evaluated first at runtime, but that doesn't make it a compile-time error. i is in scope as soon a Class i has been parsed, so the expression i.Method() in the initializer can be compiled. another order of calculation. (see comment 2) Must be an error. No. The behaviour at runtime is undefined, but it is not an error at compile time - the syntax is valid, but the result is undefined. I understand what you're saying, but you're wrong. C++ doesn't work how you think it works.
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-07 13:39:45 UTC --- (In reply to comment #13) (In reply to comment #10) (In reply to comment #9) No, the variable is in scope after its identifier, so it can be used in the initializer expression, e.g. int i = sizeof(i); // ok int i = i+1; // not ok My opinion is that C habit rules here. In C int i=i+1; - int i; i=i+1; In C++ this can be written: int i(i+1); The initialization rules for C++ do ... not care if the type is a class or not, the variable name is still in scope before the initializer is parsed.
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07 13:43:47 UTC --- Given that without vectorization that code surely works well on all the weird ABIs, such ADJUST_FIELD_ALIGN is used only on targets that either aren't strict alignment targets, or aren't strict alignment targets for the particular types. You know, for most CPUs strict alignment isn't a binary thing, many targets including i?86/x86_64 are only partially strict alignment targets. Even for targets where say int needs to be accessed aligned often e.g. double can be just 4 byte aligned and insns that read/write doubles handle it. We really shouldn't change __alignof__ of types/INDIRECT_REFs/etc., those are all ABI changes. The problem with vectorization is that often the vectors have strict alignment, while non-vector ops are not.
[Bug middle-end/48377] [4.6/4.7 regression] miscompilation at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #33 from rguenther at suse dot de rguenther at suse dot de 2011-04-07 13:57:09 UTC --- On Thu, 7 Apr 2011, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377 --- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07 13:43:47 UTC --- Given that without vectorization that code surely works well on all the weird ABIs, such ADJUST_FIELD_ALIGN is used only on targets that either aren't strict alignment targets, or aren't strict alignment targets for the particular types. You know, for most CPUs strict alignment isn't a binary thing, many targets including i?86/x86_64 are only partially strict alignment targets. Even for targets where say int needs to be accessed aligned often e.g. double can be just 4 byte aligned and insns that read/write doubles handle it. We really shouldn't change __alignof__ of types/INDIRECT_REFs/etc., those are all ABI changes. The problem with vectorization is that often the vectors have strict alignment, while non-vector ops are not. Sure, I agree with all of the above. Still, if we need target hooks for this kind of stuff then something is really rotten in the middle-end. Richard.
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 --- Comment #15 from Lisp2D lisp2d at lisp2d dot net 2011-04-07 13:58:38 UTC --- (In reply to comment #12) For the example in comment 2 G++, EDG and Clang++ all accept it without warning. MSVC rejects it, but is wrong to do so. The answer is good. Let's talk about warnings. I think that processing option -Winit-self must to be rewritten. Just create SymbolVariableProcessingInConstructor and checking of all symbols in line. This will free the brain.
[Bug c++/48483] Construct from yourself w/o warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.04.07 14:01:09
Ever Confirmed|0 |1
Severity|normal |enhancement
--- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-07
14:01:09 UTC ---
Confirming as an enhancement request for a warning from:
struct A {
A(int);
int i;
};
A a(a.i);
-Winit-self doesn't work properly for C++, this is a known issue.
[Bug boehm-gc/48494] New: FAIL: boehm-gc.c/gctest.c -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48494 Summary: FAIL: boehm-gc.c/gctest.c -O2 (test for excess errors) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: boehm-gc AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: ../libtool --silent --tag=CC --mode=link /test/gnu/gcc/objdi r/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gcc/boehm-gc/testsuite/boeh m-gc.c/gctest.c /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./boehm-gc/libgcjgc.l a -O2 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./boehm-gc/include -I/test/ gnu/gcc/gcc/boehm-gc/testsuite/../include -Wc,-shared-libgcc -lpthread -lrt -l m -o ./gctest(timeout = 300) libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: warning: `./gctest' will be relinked during installation output is: libtool: link: warning: this platform does not like uninstalled shared libraries libtool: link: warning: `./gctest' will be relinked during installation FAIL: boehm-gc.c/gctest.c -O2 (test for excess errors) Similar fails: FAIL: boehm-gc.c/leak_test.c -O2 (test for excess errors) FAIL: boehm-gc.c/middle.c -O2 (test for excess errors) FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors) FAIL: boehm-gc.lib/staticrootstest.c -O2 (test for excess errors)
[Bug inline-asm/48435] [4.7 Regression] Assertion failure during IRA (df_scan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48435 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.07 14:03:22 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-04-07 14:03:22 UTC --- All pseudos got 0 available hard regs and therefore spills. Something wrong with calculation of number of available hard regs for targets which can use reg pairs starting only on even/odd hard regs. I'm seeing this on the SPARC as well (gcc.target/sparc/combined-1.c): Loop 0 (parent -1, header bb0, depth 0) bbs: 2 all: 0r122 1r121 2r115 3r116 4r120 5r119 modified regnos: 115 116 119 120 121 122 border: Pressure: GENERAL_OR_EXTRA_FP_REGS=8 [...] Allocno a0r122 of EXTRA_FP_REGS(64) has 0 avail. regs obj 0 32 [...] Allocno a1r121 of EXTRA_FP_REGS(64) has 0 avail. regs obj 0 32 [...] Coalescing spilled allocnos a1r121-a5r119 Coalescing spilled allocnos a0r122-a2r115 Slot 1 (freq,size): a0r122(2000,8) a2r115(4000,8) Slot 2 (freq,size): a3r116(4000,8) Slot 3 (freq,size): a1r121(2000,8) a5r119(2000,8) Slot 4 (freq,size): a4r120(2000,8) Assigning 120(freq=2000) a new slot 3 Assigning 119(freq=2000) a new slot 2 Assigning 121(freq=2000) slot 2 of 119 Assigning 116(freq=4000) a new slot 1 Assigning 115(freq=4000) a new slot 0 Assigning 122(freq=2000) slot 0 of 115
[Bug target/48495] New: ICE in in reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48495
Summary: ICE in in reload_cse_simplify_operands
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
CC: d...@gcc.gnu.org, berg...@gcc.gnu.org,
meiss...@gcc.gnu.org
Host: powerpc64-linux
Target: powerpc64-linux
Build: powerpc64-linux
Created attachment 23911
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23911
reduced testcase
Noticed the following building cpu2000 benchmark 176.gcc.
$ ~/install/gcc/trunk/bin/gcc -c -O3 -mcpu=power7 recog.c
recog.c: In function ‘constrain_operands’:
recog.c:149:1: error: insn does not satisfy its constraints:
(insn 958 1120 1122 13 (set (mem:V2DI (plus:DI (reg:DI 7 7)
(reg:DI 5 5 [orig:336 ivtmp.91 ] [336])) [2 MEM[symbol:
constraints, index: ivtmp.91_200, offset: 0B]+0 S16 A128])
(reg:V2DI 8 8 [639])) recog.c:67 754 {*vsx_movv2di}
(nil))
recog.c:149:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 --- Comment #6 from Jeffrey A. Law law at redhat dot com 2011-04-07 15:04:49 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/06/11 17:00, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2011-04-06 23:00:31 UTC --- Created attachment 23905 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23905 First shot at a fix (also for PR48486) Well, one can always hope for a quick fix. I was looking at your proposed patch -- the first thing that jumps out is cfgbuild.c has many tests similar to the one you fixed (testing for eq/ne without masking off irrelevant bits). I'd hate to see this once instance get fixed and all the others left behind, but I'm also not familiar enough with the code to say for sure if the other tests are correct as-written or definitely need to be fixed. The cfgexpand changes look pretty reasonable. The extra barrier is odd, but not terribly surprising given the wacky way we've represented jump tables in RTL. It's not clear why you twiddled the code to mask off EDGE_EXECUTABLE, but it's not terribly important, just a curiosity on my part. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNndKIAAoJEBRtltQi2kC7fAgH/3A9Rsa28p2Kkly/eZAf5kBU aGFO3XbeC/MfarJQM7AdQ33WVFL+bAr2DBUaxXE304WGM0T4S/jwEPOiYbeJ2Bsi ziXZfa3urRgC10zAVSqAbP8y40NLqC3aO9NL9o+OB6eyjWuDSPTDakOpmWNJOqGg A3oAg5ONWcJO5CxODIUBaXlJBtV7igGNjrQnSPouKOCC8lR+Ljy8yQK62kMR6pP3 h7hJzhEr09wWpq5rd5rEekZd9xvboPGChvD5QK6BMHtE6HdM2UVJ7Z02X8EgKUJj J8oCGd4RK6fsRWvO00fAZBeev2ccz5zjKhlry4QiXm9tNHwN8n0Xff2k32jEFgs= =cObX -END PGP SIGNATURE-
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #56 from Dave Korn davek at gcc dot gnu.org 2011-04-07 15:15:14 UTC --- What works for me on Cygwin, and so may well also work for anyone using MSYS, is setting the heap_chunk_in_mb registry parameter to some value in the range 1024 - 1536. I use 1024 myself and that gives me sufficient headroom to link libgcj dll, which is huge; if it works for that, it's likely to help with wx dll as well. http://cygwin.com/cygwin-ug-net/setup-maxmem.html
[Bug rtl-optimization/48496] New: [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 Summary: [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: amona...@gcc.gnu.org CC: s...@cup.hp.com Target: ia64-linux-gnu Created attachment 23912 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23912 Test case Trunk fails to complete bootstrap on ia64 when building target libffi (if configured with java enabled). A reduced test case is attached. $ ../../stage1-gcc/cc1 -O2 -fexceptions -quiet tt.i tt.i: In function 'ffi_call': tt.i:15:3: error: 'asm' operand requires impossible reload
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #13 from Joel Sherrill joel at gcc dot gnu.org 2011-04-07 15:28:39 UTC --- Not a problem to redo.. just CPU time and if you don't use it, you lose it. :-D I am repeating some information so it is all in one post. In both cases, I built gcc + newlib multilib + rtems multilib to ensure the entire software base was built with and without the patch. $ m68k-rtems4.11-gcc --version m68k-rtems4.11-gcc (GCC) 4.6.1 20110329 (prerelease) Without patch.. results are at: http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000516.html http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00525.html === gcc Summary === # of expected passes67228 # of unexpected failures386 # of expected failures121 # of unresolved testcases77 # of unsupported tests1095 === g++ Summary === # of expected passes24705 # of unexpected failures720 # of expected failures162 # of unsupported tests449 With the patch ... results are at: http://www.rtems.org/pipermail/rtems-tooltestresults/2011-April/000518.html http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00577.html === gcc Summary === # of expected passes67230 # of unexpected failures384 # of expected failures121 # of unresolved testcases77 # of unsupported tests1095 === g++ Summary === # of expected passes24705 # of unexpected failures720 # of expected failures162 # of unsupported tests449 Only an increase of two passes. I don't know what was the 3rd test that passed with the previous patch and not with this one.
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #14 from Bernd Schmidt bernds at gcc dot gnu.org 2011-04-07 15:35:34 UTC --- From the test results you posted, it appears to have been +WARNING: program timed out. +FAIL: gcc.dg/torture/fp-int-convert-double.c -O2 -flto execution test Probably unrelated.
[Bug rtl-optimization/48389] [4.5/4.6/4.7 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #7 from Michael Matz matz at gcc dot gnu.org 2011-04-07 15:38:38 UTC --- Hmpf, what doesn't work with just moving the rebuild_jump_labels call? The testcase works, but I haven't tried the testsuite. Because it should theoretically work. The insertion of barrier inside BBs is fixed up in cfgexpand at some places, we possibly merely need to extend them. See maybe_cleanup_end_of_block.
[Bug rtl-optimization/48496] [4.7 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #15 from Joel Sherrill joel at gcc dot gnu.org 2011-04-07 15:44:16 UTC --- (In reply to comment #14) From the test results you posted, it appears to have been +WARNING: program timed out. +FAIL: gcc.dg/torture/fp-int-convert-double.c -O2 -flto execution test Probably unrelated. When I compiled it by hand and ran it, it passed. I think that makes the test results the same. Strangely, none of the gcc.dg/torture tests that failed appear to have left executables. :(
[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447 --- Comment #5 from Dave Korn davek at gcc dot gnu.org 2011-04-07 15:49:29 UTC --- Well, this is basically a weakness in the pass-through solution implemented for PR 42690; it only knows about the compilers stdlibs, and doesn't process any user-specified libs on the command line. In the general case that's how things ought to be: LTRANS only generates new references to builtins/libcalls, not any of the user's code. However when you use -nostdlib and pass libgcc as if it were a user library, as in case 3, the pass-through mechanism doesn't know that it's actually a compiler runtime rather than user library and doesn't pass it through. The correct fix is going to be in the linker, not the compiler, by implementing a second library scan pass and obsoleting the pass-through mechanism. I've got a revised version of that experimental patch that I'll attach to this PR for reference.
[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447 --- Comment #6 from Dave Korn davek at gcc dot gnu.org 2011-04-07 15:51:30 UTC --- Created attachment 23913 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23913 WIP patch Work in progress: see comment at start of do_rescan_work() re DT_NEEDED libs, but should be worth trying.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #57 from Dongsheng Song dongsheng.song at gmail dot com 2011-04-07 15:53:38 UTC --- (In reply to comment #56) What works for me on Cygwin, and so may well also work for anyone using MSYS, is setting the heap_chunk_in_mb registry parameter to some value in the range 1024 - 1536. I use 1024 myself and that gives me sufficient headroom to link libgcj dll, which is huge; if it works for that, it's likely to help with wx dll as well. http://cygwin.com/cygwin-ug-net/setup-maxmem.html I don't think so. Because I observed ld.exe use memory over 1.7GB, so link wx monolithic library require use more memory than 32 bit OS limit. For cross compile under Linux, link wx can use near 3G memory, it still failed. Then link wx require 4G or more memory, maybe someone can try use 64bit linker to build single huge monolithic library, tell us the max memory ld used.
[Bug rtl-optimization/48455] [4.7 Regression] Huge code size regression for all ARM configurations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48455 --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-04-07 16:00:04 UTC --- Created attachment 23914 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23914 first testcase Compile with -Os -mcpu=arm7tdmi -marm -fno-short-enums -fno-builtin
