[Bug middle-end/37852] [graphite] ICE in gbb_loop_index, at graphite.h:252
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 07:34 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37852
[Bug middle-end/38125] [graphite] ICE :Segmentation fault
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 07:34 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38125
[Bug middle-end/38039] [graphite] -02/O3 -fgraphite-identity causes ICE when compiling aermod.f90 Polyhedron 2005 benchmark
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 07:33 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38039
[Bug middle-end/37928] [graphite] ICE :Segmentation fault
--- Comment #6 from spop at gcc dot gnu dot org 2008-12-11 07:32 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37928
[Bug middle-end/38038] [graphite] -03 -fgraphite-identity causes ICE when compiling ac.f90 Polyhedron 2005 benchmark
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 07:32 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38038
[Bug middle-end/37980] [graphite] ICE : verify_ssa failed
--- Comment #7 from spop at gcc dot gnu dot org 2008-12-11 07:31 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37980
[Bug middle-end/38083] [graphite] ICE: in verify_loop_structure, at cfgloop.c:1569
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 07:30 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38083
[Bug middle-end/38073] [graphite] ICE: Segmentation fault
--- Comment #4 from spop at gcc dot gnu dot org 2008-12-11 07:30 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38073
[Bug middle-end/38038] [graphite] -03 -fgraphite-identity causes ICE when compiling ac.f90 Polyhedron 2005 benchmark
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-11 07:24 --- Subject: Bug 38038 Author: spop Date: Thu Dec 11 07:23:02 2008 New Revision: 142673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142673 Log: 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Fix testsuite/gfortran.dg/graphite/id-4.f90. * graphite.c (scan_tree_for_params): Do not compute the multiplicand when not needed. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> * graphite.c (build_scops_1): Initialize open_scop.exit and sinfo.last. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR middle-end/37852 PR middle-end/37883 PR middle-end/37928 PR middle-end/37980 PR middle-end/38038 PR middle-end/38039 PR middle-end/38073 PR middle-end/38083 PR middle-end/38125 * tree-phinodes.c (remove_phi_nodes): New, extracted from... * tree-cfg.c (remove_phi_nodes_and_edges_for_unreachable_block): ...here. * tree-flow.h (remove_phi_nodes, canonicalize_loop_ivs): Declared. * Makefile.in (graphite.o): Depend on value-prof.h. (graphite.o-warn): Removed -Wno-error. * tree-parloops.c (canonicalize_loop_ivs): Allow reduction_list to be a NULL pointer. Call update_stmt. Return the newly created cannonical induction variable. * graphite.h (debug_rename_map): Declared. Fix some comments. * graphite.c: Reimplement the code generation from graphite to gimple. Include value-prof.h. (loop_iv_stack_get_iv): Do not return NULL for constant substitutions. (get_old_iv_from_ssa_name): Removed. (graphite_stmt_p): New. (new_graphite_bb): Test for useful statements before building a graphite statement for the basic block. (free_graphite_bb): Do not free GBB_DATA_REFS: this is a bug in free_data_ref that calls BITMAP_FREE (DR_VOPS (dr)) without reason. (recompute_all_dominators, graphite_verify, nb_reductions_in_loop, graphite_loop_normal_form): New. (scop_record_loop): Call graphite_loop_normal_form. (build_scop_loop_nests): Iterate over all the blocks of the function instead of relying on the incomplete information from SCOP_BBS. Return the success of the operation. (find_params_in_bb): Use the data from GBB_DATA_REFS. (add_bb_domains): Removed. (build_loop_iteration_domains): Don't call add_bb_domains. Add the iteration domain only to the basic blocks that have been translated to graphite. (build_scop_conditions_1): Add constraints only if the basic block have been translated to graphite. (build_scop_data_accesses): Completely disabled until data dependence is correctly implemented. (debug_rename_elt, debug_rename_map_1, debug_rename_map): New. (remove_all_edges_1, remove_all_edges): Removed. (get_new_name_from_old_name): New. (graphite_rename_variables_in_stmt): Renamed rename_variables_in_stmt. Call get_new_name_from_old_name. Use replace_exp and update_stmt. (is_old_iv): Renamed is_iv. (expand_scalar_variables_stmt): Extra parameter for renaming map. Use replace_exp and update_stmt. (expand_scalar_variables_expr): Same. Use the map to get the new names for the renaming of induction variables and for the renaming of variables after a basic block has been copied. (expand_scalar_variables): Same. (graphite_rename_variables): Renamed rename_variables. (move_phi_nodes): Removed. (get_false_edge_from_guard_bb): New. (build_iv_mapping): Do not insert the induction variable of a loop in the renaming iv map if the basic block does not belong to that loop. (register_old_new_names, graphite_copy_stmts_from_block, copy_bb_and_scalar_dependences): New. (translate_clast): Heavily reimplemented: copy basic blocks, do not move them. Finally, in call cleanup_tree_cfg in gloog. At each translation step call graphite_verify ensuring the consistency of the SSA, loops and dominators information. (collect_virtual_phis, find_vdef_for_var_in_bb, find_vdef_for_var_1, find_vdef_for_var, patch_phis_for_virtual_defs): Removed huge hack. (mark_old_loops, remove_dead_loops, skip_phi_defs, collect_scop_exit_phi_args, patch_scop_exit_phi_args, gbb_can_be_ignored, scop_remove_ignoreable_gbbs, ): Removed. (remove_sese_region, ifsese, if_region_entry, if_region_exit, if_region_get_condition_block, if_region_set_false_region, create_if_region_on_edge, move_sese_in_condition, bb_in_sese_p, sese_find_uses_to_rename_use, sese_f
[Bug middle-end/38073] [graphite] ICE: Segmentation fault
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-11 07:24 --- Subject: Bug 38073 Author: spop Date: Thu Dec 11 07:23:02 2008 New Revision: 142673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142673 Log: 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Fix testsuite/gfortran.dg/graphite/id-4.f90. * graphite.c (scan_tree_for_params): Do not compute the multiplicand when not needed. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> * graphite.c (build_scops_1): Initialize open_scop.exit and sinfo.last. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR middle-end/37852 PR middle-end/37883 PR middle-end/37928 PR middle-end/37980 PR middle-end/38038 PR middle-end/38039 PR middle-end/38073 PR middle-end/38083 PR middle-end/38125 * tree-phinodes.c (remove_phi_nodes): New, extracted from... * tree-cfg.c (remove_phi_nodes_and_edges_for_unreachable_block): ...here. * tree-flow.h (remove_phi_nodes, canonicalize_loop_ivs): Declared. * Makefile.in (graphite.o): Depend on value-prof.h. (graphite.o-warn): Removed -Wno-error. * tree-parloops.c (canonicalize_loop_ivs): Allow reduction_list to be a NULL pointer. Call update_stmt. Return the newly created cannonical induction variable. * graphite.h (debug_rename_map): Declared. Fix some comments. * graphite.c: Reimplement the code generation from graphite to gimple. Include value-prof.h. (loop_iv_stack_get_iv): Do not return NULL for constant substitutions. (get_old_iv_from_ssa_name): Removed. (graphite_stmt_p): New. (new_graphite_bb): Test for useful statements before building a graphite statement for the basic block. (free_graphite_bb): Do not free GBB_DATA_REFS: this is a bug in free_data_ref that calls BITMAP_FREE (DR_VOPS (dr)) without reason. (recompute_all_dominators, graphite_verify, nb_reductions_in_loop, graphite_loop_normal_form): New. (scop_record_loop): Call graphite_loop_normal_form. (build_scop_loop_nests): Iterate over all the blocks of the function instead of relying on the incomplete information from SCOP_BBS. Return the success of the operation. (find_params_in_bb): Use the data from GBB_DATA_REFS. (add_bb_domains): Removed. (build_loop_iteration_domains): Don't call add_bb_domains. Add the iteration domain only to the basic blocks that have been translated to graphite. (build_scop_conditions_1): Add constraints only if the basic block have been translated to graphite. (build_scop_data_accesses): Completely disabled until data dependence is correctly implemented. (debug_rename_elt, debug_rename_map_1, debug_rename_map): New. (remove_all_edges_1, remove_all_edges): Removed. (get_new_name_from_old_name): New. (graphite_rename_variables_in_stmt): Renamed rename_variables_in_stmt. Call get_new_name_from_old_name. Use replace_exp and update_stmt. (is_old_iv): Renamed is_iv. (expand_scalar_variables_stmt): Extra parameter for renaming map. Use replace_exp and update_stmt. (expand_scalar_variables_expr): Same. Use the map to get the new names for the renaming of induction variables and for the renaming of variables after a basic block has been copied. (expand_scalar_variables): Same. (graphite_rename_variables): Renamed rename_variables. (move_phi_nodes): Removed. (get_false_edge_from_guard_bb): New. (build_iv_mapping): Do not insert the induction variable of a loop in the renaming iv map if the basic block does not belong to that loop. (register_old_new_names, graphite_copy_stmts_from_block, copy_bb_and_scalar_dependences): New. (translate_clast): Heavily reimplemented: copy basic blocks, do not move them. Finally, in call cleanup_tree_cfg in gloog. At each translation step call graphite_verify ensuring the consistency of the SSA, loops and dominators information. (collect_virtual_phis, find_vdef_for_var_in_bb, find_vdef_for_var_1, find_vdef_for_var, patch_phis_for_virtual_defs): Removed huge hack. (mark_old_loops, remove_dead_loops, skip_phi_defs, collect_scop_exit_phi_args, patch_scop_exit_phi_args, gbb_can_be_ignored, scop_remove_ignoreable_gbbs, ): Removed. (remove_sese_region, ifsese, if_region_entry, if_region_exit, if_region_get_condition_block, if_region_set_false_region, create_if_region_on_edge, move_sese_in_condition, bb_in_sese_p, sese_find_uses_to_rename_use, sese_f
[Bug middle-end/38083] [graphite] ICE: in verify_loop_structure, at cfgloop.c:1569
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-11 07:24 --- Subject: Bug 38083 Author: spop Date: Thu Dec 11 07:23:02 2008 New Revision: 142673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142673 Log: 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Fix testsuite/gfortran.dg/graphite/id-4.f90. * graphite.c (scan_tree_for_params): Do not compute the multiplicand when not needed. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> * graphite.c (build_scops_1): Initialize open_scop.exit and sinfo.last. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR middle-end/37852 PR middle-end/37883 PR middle-end/37928 PR middle-end/37980 PR middle-end/38038 PR middle-end/38039 PR middle-end/38073 PR middle-end/38083 PR middle-end/38125 * tree-phinodes.c (remove_phi_nodes): New, extracted from... * tree-cfg.c (remove_phi_nodes_and_edges_for_unreachable_block): ...here. * tree-flow.h (remove_phi_nodes, canonicalize_loop_ivs): Declared. * Makefile.in (graphite.o): Depend on value-prof.h. (graphite.o-warn): Removed -Wno-error. * tree-parloops.c (canonicalize_loop_ivs): Allow reduction_list to be a NULL pointer. Call update_stmt. Return the newly created cannonical induction variable. * graphite.h (debug_rename_map): Declared. Fix some comments. * graphite.c: Reimplement the code generation from graphite to gimple. Include value-prof.h. (loop_iv_stack_get_iv): Do not return NULL for constant substitutions. (get_old_iv_from_ssa_name): Removed. (graphite_stmt_p): New. (new_graphite_bb): Test for useful statements before building a graphite statement for the basic block. (free_graphite_bb): Do not free GBB_DATA_REFS: this is a bug in free_data_ref that calls BITMAP_FREE (DR_VOPS (dr)) without reason. (recompute_all_dominators, graphite_verify, nb_reductions_in_loop, graphite_loop_normal_form): New. (scop_record_loop): Call graphite_loop_normal_form. (build_scop_loop_nests): Iterate over all the blocks of the function instead of relying on the incomplete information from SCOP_BBS. Return the success of the operation. (find_params_in_bb): Use the data from GBB_DATA_REFS. (add_bb_domains): Removed. (build_loop_iteration_domains): Don't call add_bb_domains. Add the iteration domain only to the basic blocks that have been translated to graphite. (build_scop_conditions_1): Add constraints only if the basic block have been translated to graphite. (build_scop_data_accesses): Completely disabled until data dependence is correctly implemented. (debug_rename_elt, debug_rename_map_1, debug_rename_map): New. (remove_all_edges_1, remove_all_edges): Removed. (get_new_name_from_old_name): New. (graphite_rename_variables_in_stmt): Renamed rename_variables_in_stmt. Call get_new_name_from_old_name. Use replace_exp and update_stmt. (is_old_iv): Renamed is_iv. (expand_scalar_variables_stmt): Extra parameter for renaming map. Use replace_exp and update_stmt. (expand_scalar_variables_expr): Same. Use the map to get the new names for the renaming of induction variables and for the renaming of variables after a basic block has been copied. (expand_scalar_variables): Same. (graphite_rename_variables): Renamed rename_variables. (move_phi_nodes): Removed. (get_false_edge_from_guard_bb): New. (build_iv_mapping): Do not insert the induction variable of a loop in the renaming iv map if the basic block does not belong to that loop. (register_old_new_names, graphite_copy_stmts_from_block, copy_bb_and_scalar_dependences): New. (translate_clast): Heavily reimplemented: copy basic blocks, do not move them. Finally, in call cleanup_tree_cfg in gloog. At each translation step call graphite_verify ensuring the consistency of the SSA, loops and dominators information. (collect_virtual_phis, find_vdef_for_var_in_bb, find_vdef_for_var_1, find_vdef_for_var, patch_phis_for_virtual_defs): Removed huge hack. (mark_old_loops, remove_dead_loops, skip_phi_defs, collect_scop_exit_phi_args, patch_scop_exit_phi_args, gbb_can_be_ignored, scop_remove_ignoreable_gbbs, ): Removed. (remove_sese_region, ifsese, if_region_entry, if_region_exit, if_region_get_condition_block, if_region_set_false_region, create_if_region_on_edge, move_sese_in_condition, bb_in_sese_p, sese_find_uses_to_rename_use, sese_f
[Bug middle-end/37883] [graphite] ICE : in scan_tree_for_params, at graphite.c:2274
--- Comment #9 from spop at gcc dot gnu dot org 2008-12-11 07:24 --- Subject: Bug 37883 Author: spop Date: Thu Dec 11 07:23:02 2008 New Revision: 142673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142673 Log: 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Fix testsuite/gfortran.dg/graphite/id-4.f90. * graphite.c (scan_tree_for_params): Do not compute the multiplicand when not needed. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> * graphite.c (build_scops_1): Initialize open_scop.exit and sinfo.last. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR middle-end/37852 PR middle-end/37883 PR middle-end/37928 PR middle-end/37980 PR middle-end/38038 PR middle-end/38039 PR middle-end/38073 PR middle-end/38083 PR middle-end/38125 * tree-phinodes.c (remove_phi_nodes): New, extracted from... * tree-cfg.c (remove_phi_nodes_and_edges_for_unreachable_block): ...here. * tree-flow.h (remove_phi_nodes, canonicalize_loop_ivs): Declared. * Makefile.in (graphite.o): Depend on value-prof.h. (graphite.o-warn): Removed -Wno-error. * tree-parloops.c (canonicalize_loop_ivs): Allow reduction_list to be a NULL pointer. Call update_stmt. Return the newly created cannonical induction variable. * graphite.h (debug_rename_map): Declared. Fix some comments. * graphite.c: Reimplement the code generation from graphite to gimple. Include value-prof.h. (loop_iv_stack_get_iv): Do not return NULL for constant substitutions. (get_old_iv_from_ssa_name): Removed. (graphite_stmt_p): New. (new_graphite_bb): Test for useful statements before building a graphite statement for the basic block. (free_graphite_bb): Do not free GBB_DATA_REFS: this is a bug in free_data_ref that calls BITMAP_FREE (DR_VOPS (dr)) without reason. (recompute_all_dominators, graphite_verify, nb_reductions_in_loop, graphite_loop_normal_form): New. (scop_record_loop): Call graphite_loop_normal_form. (build_scop_loop_nests): Iterate over all the blocks of the function instead of relying on the incomplete information from SCOP_BBS. Return the success of the operation. (find_params_in_bb): Use the data from GBB_DATA_REFS. (add_bb_domains): Removed. (build_loop_iteration_domains): Don't call add_bb_domains. Add the iteration domain only to the basic blocks that have been translated to graphite. (build_scop_conditions_1): Add constraints only if the basic block have been translated to graphite. (build_scop_data_accesses): Completely disabled until data dependence is correctly implemented. (debug_rename_elt, debug_rename_map_1, debug_rename_map): New. (remove_all_edges_1, remove_all_edges): Removed. (get_new_name_from_old_name): New. (graphite_rename_variables_in_stmt): Renamed rename_variables_in_stmt. Call get_new_name_from_old_name. Use replace_exp and update_stmt. (is_old_iv): Renamed is_iv. (expand_scalar_variables_stmt): Extra parameter for renaming map. Use replace_exp and update_stmt. (expand_scalar_variables_expr): Same. Use the map to get the new names for the renaming of induction variables and for the renaming of variables after a basic block has been copied. (expand_scalar_variables): Same. (graphite_rename_variables): Renamed rename_variables. (move_phi_nodes): Removed. (get_false_edge_from_guard_bb): New. (build_iv_mapping): Do not insert the induction variable of a loop in the renaming iv map if the basic block does not belong to that loop. (register_old_new_names, graphite_copy_stmts_from_block, copy_bb_and_scalar_dependences): New. (translate_clast): Heavily reimplemented: copy basic blocks, do not move them. Finally, in call cleanup_tree_cfg in gloog. At each translation step call graphite_verify ensuring the consistency of the SSA, loops and dominators information. (collect_virtual_phis, find_vdef_for_var_in_bb, find_vdef_for_var_1, find_vdef_for_var, patch_phis_for_virtual_defs): Removed huge hack. (mark_old_loops, remove_dead_loops, skip_phi_defs, collect_scop_exit_phi_args, patch_scop_exit_phi_args, gbb_can_be_ignored, scop_remove_ignoreable_gbbs, ): Removed. (remove_sese_region, ifsese, if_region_entry, if_region_exit, if_region_get_condition_block, if_region_set_false_region, create_if_region_on_edge, move_sese_in_condition, bb_in_sese_p, sese_find_uses_to_rename_use, sese_f
[Bug middle-end/38125] [graphite] ICE :Segmentation fault
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-11 07:24 --- Subject: Bug 38125 Author: spop Date: Thu Dec 11 07:23:02 2008 New Revision: 142673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142673 Log: 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Fix testsuite/gfortran.dg/graphite/id-4.f90. * graphite.c (scan_tree_for_params): Do not compute the multiplicand when not needed. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> * graphite.c (build_scops_1): Initialize open_scop.exit and sinfo.last. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR middle-end/37852 PR middle-end/37883 PR middle-end/37928 PR middle-end/37980 PR middle-end/38038 PR middle-end/38039 PR middle-end/38073 PR middle-end/38083 PR middle-end/38125 * tree-phinodes.c (remove_phi_nodes): New, extracted from... * tree-cfg.c (remove_phi_nodes_and_edges_for_unreachable_block): ...here. * tree-flow.h (remove_phi_nodes, canonicalize_loop_ivs): Declared. * Makefile.in (graphite.o): Depend on value-prof.h. (graphite.o-warn): Removed -Wno-error. * tree-parloops.c (canonicalize_loop_ivs): Allow reduction_list to be a NULL pointer. Call update_stmt. Return the newly created cannonical induction variable. * graphite.h (debug_rename_map): Declared. Fix some comments. * graphite.c: Reimplement the code generation from graphite to gimple. Include value-prof.h. (loop_iv_stack_get_iv): Do not return NULL for constant substitutions. (get_old_iv_from_ssa_name): Removed. (graphite_stmt_p): New. (new_graphite_bb): Test for useful statements before building a graphite statement for the basic block. (free_graphite_bb): Do not free GBB_DATA_REFS: this is a bug in free_data_ref that calls BITMAP_FREE (DR_VOPS (dr)) without reason. (recompute_all_dominators, graphite_verify, nb_reductions_in_loop, graphite_loop_normal_form): New. (scop_record_loop): Call graphite_loop_normal_form. (build_scop_loop_nests): Iterate over all the blocks of the function instead of relying on the incomplete information from SCOP_BBS. Return the success of the operation. (find_params_in_bb): Use the data from GBB_DATA_REFS. (add_bb_domains): Removed. (build_loop_iteration_domains): Don't call add_bb_domains. Add the iteration domain only to the basic blocks that have been translated to graphite. (build_scop_conditions_1): Add constraints only if the basic block have been translated to graphite. (build_scop_data_accesses): Completely disabled until data dependence is correctly implemented. (debug_rename_elt, debug_rename_map_1, debug_rename_map): New. (remove_all_edges_1, remove_all_edges): Removed. (get_new_name_from_old_name): New. (graphite_rename_variables_in_stmt): Renamed rename_variables_in_stmt. Call get_new_name_from_old_name. Use replace_exp and update_stmt. (is_old_iv): Renamed is_iv. (expand_scalar_variables_stmt): Extra parameter for renaming map. Use replace_exp and update_stmt. (expand_scalar_variables_expr): Same. Use the map to get the new names for the renaming of induction variables and for the renaming of variables after a basic block has been copied. (expand_scalar_variables): Same. (graphite_rename_variables): Renamed rename_variables. (move_phi_nodes): Removed. (get_false_edge_from_guard_bb): New. (build_iv_mapping): Do not insert the induction variable of a loop in the renaming iv map if the basic block does not belong to that loop. (register_old_new_names, graphite_copy_stmts_from_block, copy_bb_and_scalar_dependences): New. (translate_clast): Heavily reimplemented: copy basic blocks, do not move them. Finally, in call cleanup_tree_cfg in gloog. At each translation step call graphite_verify ensuring the consistency of the SSA, loops and dominators information. (collect_virtual_phis, find_vdef_for_var_in_bb, find_vdef_for_var_1, find_vdef_for_var, patch_phis_for_virtual_defs): Removed huge hack. (mark_old_loops, remove_dead_loops, skip_phi_defs, collect_scop_exit_phi_args, patch_scop_exit_phi_args, gbb_can_be_ignored, scop_remove_ignoreable_gbbs, ): Removed. (remove_sese_region, ifsese, if_region_entry, if_region_exit, if_region_get_condition_block, if_region_set_false_region, create_if_region_on_edge, move_sese_in_condition, bb_in_sese_p, sese_find_uses_to_rename_use, sese_f
[Bug middle-end/37852] [graphite] ICE in gbb_loop_index, at graphite.h:252
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-11 07:24 --- Subject: Bug 37852 Author: spop Date: Thu Dec 11 07:23:02 2008 New Revision: 142673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142673 Log: 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Fix testsuite/gfortran.dg/graphite/id-4.f90. * graphite.c (scan_tree_for_params): Do not compute the multiplicand when not needed. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> * graphite.c (build_scops_1): Initialize open_scop.exit and sinfo.last. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR middle-end/37852 PR middle-end/37883 PR middle-end/37928 PR middle-end/37980 PR middle-end/38038 PR middle-end/38039 PR middle-end/38073 PR middle-end/38083 PR middle-end/38125 * tree-phinodes.c (remove_phi_nodes): New, extracted from... * tree-cfg.c (remove_phi_nodes_and_edges_for_unreachable_block): ...here. * tree-flow.h (remove_phi_nodes, canonicalize_loop_ivs): Declared. * Makefile.in (graphite.o): Depend on value-prof.h. (graphite.o-warn): Removed -Wno-error. * tree-parloops.c (canonicalize_loop_ivs): Allow reduction_list to be a NULL pointer. Call update_stmt. Return the newly created cannonical induction variable. * graphite.h (debug_rename_map): Declared. Fix some comments. * graphite.c: Reimplement the code generation from graphite to gimple. Include value-prof.h. (loop_iv_stack_get_iv): Do not return NULL for constant substitutions. (get_old_iv_from_ssa_name): Removed. (graphite_stmt_p): New. (new_graphite_bb): Test for useful statements before building a graphite statement for the basic block. (free_graphite_bb): Do not free GBB_DATA_REFS: this is a bug in free_data_ref that calls BITMAP_FREE (DR_VOPS (dr)) without reason. (recompute_all_dominators, graphite_verify, nb_reductions_in_loop, graphite_loop_normal_form): New. (scop_record_loop): Call graphite_loop_normal_form. (build_scop_loop_nests): Iterate over all the blocks of the function instead of relying on the incomplete information from SCOP_BBS. Return the success of the operation. (find_params_in_bb): Use the data from GBB_DATA_REFS. (add_bb_domains): Removed. (build_loop_iteration_domains): Don't call add_bb_domains. Add the iteration domain only to the basic blocks that have been translated to graphite. (build_scop_conditions_1): Add constraints only if the basic block have been translated to graphite. (build_scop_data_accesses): Completely disabled until data dependence is correctly implemented. (debug_rename_elt, debug_rename_map_1, debug_rename_map): New. (remove_all_edges_1, remove_all_edges): Removed. (get_new_name_from_old_name): New. (graphite_rename_variables_in_stmt): Renamed rename_variables_in_stmt. Call get_new_name_from_old_name. Use replace_exp and update_stmt. (is_old_iv): Renamed is_iv. (expand_scalar_variables_stmt): Extra parameter for renaming map. Use replace_exp and update_stmt. (expand_scalar_variables_expr): Same. Use the map to get the new names for the renaming of induction variables and for the renaming of variables after a basic block has been copied. (expand_scalar_variables): Same. (graphite_rename_variables): Renamed rename_variables. (move_phi_nodes): Removed. (get_false_edge_from_guard_bb): New. (build_iv_mapping): Do not insert the induction variable of a loop in the renaming iv map if the basic block does not belong to that loop. (register_old_new_names, graphite_copy_stmts_from_block, copy_bb_and_scalar_dependences): New. (translate_clast): Heavily reimplemented: copy basic blocks, do not move them. Finally, in call cleanup_tree_cfg in gloog. At each translation step call graphite_verify ensuring the consistency of the SSA, loops and dominators information. (collect_virtual_phis, find_vdef_for_var_in_bb, find_vdef_for_var_1, find_vdef_for_var, patch_phis_for_virtual_defs): Removed huge hack. (mark_old_loops, remove_dead_loops, skip_phi_defs, collect_scop_exit_phi_args, patch_scop_exit_phi_args, gbb_can_be_ignored, scop_remove_ignoreable_gbbs, ): Removed. (remove_sese_region, ifsese, if_region_entry, if_region_exit, if_region_get_condition_block, if_region_set_false_region, create_if_region_on_edge, move_sese_in_condition, bb_in_sese_p, sese_find_uses_to_rename_use, sese_f
[Bug middle-end/38039] [graphite] -02/O3 -fgraphite-identity causes ICE when compiling aermod.f90 Polyhedron 2005 benchmark
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-11 07:24 --- Subject: Bug 38039 Author: spop Date: Thu Dec 11 07:23:02 2008 New Revision: 142673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142673 Log: 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Fix testsuite/gfortran.dg/graphite/id-4.f90. * graphite.c (scan_tree_for_params): Do not compute the multiplicand when not needed. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> * graphite.c (build_scops_1): Initialize open_scop.exit and sinfo.last. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR middle-end/37852 PR middle-end/37883 PR middle-end/37928 PR middle-end/37980 PR middle-end/38038 PR middle-end/38039 PR middle-end/38073 PR middle-end/38083 PR middle-end/38125 * tree-phinodes.c (remove_phi_nodes): New, extracted from... * tree-cfg.c (remove_phi_nodes_and_edges_for_unreachable_block): ...here. * tree-flow.h (remove_phi_nodes, canonicalize_loop_ivs): Declared. * Makefile.in (graphite.o): Depend on value-prof.h. (graphite.o-warn): Removed -Wno-error. * tree-parloops.c (canonicalize_loop_ivs): Allow reduction_list to be a NULL pointer. Call update_stmt. Return the newly created cannonical induction variable. * graphite.h (debug_rename_map): Declared. Fix some comments. * graphite.c: Reimplement the code generation from graphite to gimple. Include value-prof.h. (loop_iv_stack_get_iv): Do not return NULL for constant substitutions. (get_old_iv_from_ssa_name): Removed. (graphite_stmt_p): New. (new_graphite_bb): Test for useful statements before building a graphite statement for the basic block. (free_graphite_bb): Do not free GBB_DATA_REFS: this is a bug in free_data_ref that calls BITMAP_FREE (DR_VOPS (dr)) without reason. (recompute_all_dominators, graphite_verify, nb_reductions_in_loop, graphite_loop_normal_form): New. (scop_record_loop): Call graphite_loop_normal_form. (build_scop_loop_nests): Iterate over all the blocks of the function instead of relying on the incomplete information from SCOP_BBS. Return the success of the operation. (find_params_in_bb): Use the data from GBB_DATA_REFS. (add_bb_domains): Removed. (build_loop_iteration_domains): Don't call add_bb_domains. Add the iteration domain only to the basic blocks that have been translated to graphite. (build_scop_conditions_1): Add constraints only if the basic block have been translated to graphite. (build_scop_data_accesses): Completely disabled until data dependence is correctly implemented. (debug_rename_elt, debug_rename_map_1, debug_rename_map): New. (remove_all_edges_1, remove_all_edges): Removed. (get_new_name_from_old_name): New. (graphite_rename_variables_in_stmt): Renamed rename_variables_in_stmt. Call get_new_name_from_old_name. Use replace_exp and update_stmt. (is_old_iv): Renamed is_iv. (expand_scalar_variables_stmt): Extra parameter for renaming map. Use replace_exp and update_stmt. (expand_scalar_variables_expr): Same. Use the map to get the new names for the renaming of induction variables and for the renaming of variables after a basic block has been copied. (expand_scalar_variables): Same. (graphite_rename_variables): Renamed rename_variables. (move_phi_nodes): Removed. (get_false_edge_from_guard_bb): New. (build_iv_mapping): Do not insert the induction variable of a loop in the renaming iv map if the basic block does not belong to that loop. (register_old_new_names, graphite_copy_stmts_from_block, copy_bb_and_scalar_dependences): New. (translate_clast): Heavily reimplemented: copy basic blocks, do not move them. Finally, in call cleanup_tree_cfg in gloog. At each translation step call graphite_verify ensuring the consistency of the SSA, loops and dominators information. (collect_virtual_phis, find_vdef_for_var_in_bb, find_vdef_for_var_1, find_vdef_for_var, patch_phis_for_virtual_defs): Removed huge hack. (mark_old_loops, remove_dead_loops, skip_phi_defs, collect_scop_exit_phi_args, patch_scop_exit_phi_args, gbb_can_be_ignored, scop_remove_ignoreable_gbbs, ): Removed. (remove_sese_region, ifsese, if_region_entry, if_region_exit, if_region_get_condition_block, if_region_set_false_region, create_if_region_on_edge, move_sese_in_condition, bb_in_sese_p, sese_find_uses_to_rename_use, sese_f
[Bug middle-end/37928] [graphite] ICE :Segmentation fault
--- Comment #5 from spop at gcc dot gnu dot org 2008-12-11 07:24 --- Subject: Bug 37928 Author: spop Date: Thu Dec 11 07:23:02 2008 New Revision: 142673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142673 Log: 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Fix testsuite/gfortran.dg/graphite/id-4.f90. * graphite.c (scan_tree_for_params): Do not compute the multiplicand when not needed. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> * graphite.c (build_scops_1): Initialize open_scop.exit and sinfo.last. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR middle-end/37852 PR middle-end/37883 PR middle-end/37928 PR middle-end/37980 PR middle-end/38038 PR middle-end/38039 PR middle-end/38073 PR middle-end/38083 PR middle-end/38125 * tree-phinodes.c (remove_phi_nodes): New, extracted from... * tree-cfg.c (remove_phi_nodes_and_edges_for_unreachable_block): ...here. * tree-flow.h (remove_phi_nodes, canonicalize_loop_ivs): Declared. * Makefile.in (graphite.o): Depend on value-prof.h. (graphite.o-warn): Removed -Wno-error. * tree-parloops.c (canonicalize_loop_ivs): Allow reduction_list to be a NULL pointer. Call update_stmt. Return the newly created cannonical induction variable. * graphite.h (debug_rename_map): Declared. Fix some comments. * graphite.c: Reimplement the code generation from graphite to gimple. Include value-prof.h. (loop_iv_stack_get_iv): Do not return NULL for constant substitutions. (get_old_iv_from_ssa_name): Removed. (graphite_stmt_p): New. (new_graphite_bb): Test for useful statements before building a graphite statement for the basic block. (free_graphite_bb): Do not free GBB_DATA_REFS: this is a bug in free_data_ref that calls BITMAP_FREE (DR_VOPS (dr)) without reason. (recompute_all_dominators, graphite_verify, nb_reductions_in_loop, graphite_loop_normal_form): New. (scop_record_loop): Call graphite_loop_normal_form. (build_scop_loop_nests): Iterate over all the blocks of the function instead of relying on the incomplete information from SCOP_BBS. Return the success of the operation. (find_params_in_bb): Use the data from GBB_DATA_REFS. (add_bb_domains): Removed. (build_loop_iteration_domains): Don't call add_bb_domains. Add the iteration domain only to the basic blocks that have been translated to graphite. (build_scop_conditions_1): Add constraints only if the basic block have been translated to graphite. (build_scop_data_accesses): Completely disabled until data dependence is correctly implemented. (debug_rename_elt, debug_rename_map_1, debug_rename_map): New. (remove_all_edges_1, remove_all_edges): Removed. (get_new_name_from_old_name): New. (graphite_rename_variables_in_stmt): Renamed rename_variables_in_stmt. Call get_new_name_from_old_name. Use replace_exp and update_stmt. (is_old_iv): Renamed is_iv. (expand_scalar_variables_stmt): Extra parameter for renaming map. Use replace_exp and update_stmt. (expand_scalar_variables_expr): Same. Use the map to get the new names for the renaming of induction variables and for the renaming of variables after a basic block has been copied. (expand_scalar_variables): Same. (graphite_rename_variables): Renamed rename_variables. (move_phi_nodes): Removed. (get_false_edge_from_guard_bb): New. (build_iv_mapping): Do not insert the induction variable of a loop in the renaming iv map if the basic block does not belong to that loop. (register_old_new_names, graphite_copy_stmts_from_block, copy_bb_and_scalar_dependences): New. (translate_clast): Heavily reimplemented: copy basic blocks, do not move them. Finally, in call cleanup_tree_cfg in gloog. At each translation step call graphite_verify ensuring the consistency of the SSA, loops and dominators information. (collect_virtual_phis, find_vdef_for_var_in_bb, find_vdef_for_var_1, find_vdef_for_var, patch_phis_for_virtual_defs): Removed huge hack. (mark_old_loops, remove_dead_loops, skip_phi_defs, collect_scop_exit_phi_args, patch_scop_exit_phi_args, gbb_can_be_ignored, scop_remove_ignoreable_gbbs, ): Removed. (remove_sese_region, ifsese, if_region_entry, if_region_exit, if_region_get_condition_block, if_region_set_false_region, create_if_region_on_edge, move_sese_in_condition, bb_in_sese_p, sese_find_uses_to_rename_use, sese_f
[Bug middle-end/37980] [graphite] ICE : verify_ssa failed
--- Comment #6 from spop at gcc dot gnu dot org 2008-12-11 07:24 --- Subject: Bug 37980 Author: spop Date: Thu Dec 11 07:23:02 2008 New Revision: 142673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142673 Log: 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Fix testsuite/gfortran.dg/graphite/id-4.f90. * graphite.c (scan_tree_for_params): Do not compute the multiplicand when not needed. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> * graphite.c (build_scops_1): Initialize open_scop.exit and sinfo.last. 2008-12-11 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR middle-end/37852 PR middle-end/37883 PR middle-end/37928 PR middle-end/37980 PR middle-end/38038 PR middle-end/38039 PR middle-end/38073 PR middle-end/38083 PR middle-end/38125 * tree-phinodes.c (remove_phi_nodes): New, extracted from... * tree-cfg.c (remove_phi_nodes_and_edges_for_unreachable_block): ...here. * tree-flow.h (remove_phi_nodes, canonicalize_loop_ivs): Declared. * Makefile.in (graphite.o): Depend on value-prof.h. (graphite.o-warn): Removed -Wno-error. * tree-parloops.c (canonicalize_loop_ivs): Allow reduction_list to be a NULL pointer. Call update_stmt. Return the newly created cannonical induction variable. * graphite.h (debug_rename_map): Declared. Fix some comments. * graphite.c: Reimplement the code generation from graphite to gimple. Include value-prof.h. (loop_iv_stack_get_iv): Do not return NULL for constant substitutions. (get_old_iv_from_ssa_name): Removed. (graphite_stmt_p): New. (new_graphite_bb): Test for useful statements before building a graphite statement for the basic block. (free_graphite_bb): Do not free GBB_DATA_REFS: this is a bug in free_data_ref that calls BITMAP_FREE (DR_VOPS (dr)) without reason. (recompute_all_dominators, graphite_verify, nb_reductions_in_loop, graphite_loop_normal_form): New. (scop_record_loop): Call graphite_loop_normal_form. (build_scop_loop_nests): Iterate over all the blocks of the function instead of relying on the incomplete information from SCOP_BBS. Return the success of the operation. (find_params_in_bb): Use the data from GBB_DATA_REFS. (add_bb_domains): Removed. (build_loop_iteration_domains): Don't call add_bb_domains. Add the iteration domain only to the basic blocks that have been translated to graphite. (build_scop_conditions_1): Add constraints only if the basic block have been translated to graphite. (build_scop_data_accesses): Completely disabled until data dependence is correctly implemented. (debug_rename_elt, debug_rename_map_1, debug_rename_map): New. (remove_all_edges_1, remove_all_edges): Removed. (get_new_name_from_old_name): New. (graphite_rename_variables_in_stmt): Renamed rename_variables_in_stmt. Call get_new_name_from_old_name. Use replace_exp and update_stmt. (is_old_iv): Renamed is_iv. (expand_scalar_variables_stmt): Extra parameter for renaming map. Use replace_exp and update_stmt. (expand_scalar_variables_expr): Same. Use the map to get the new names for the renaming of induction variables and for the renaming of variables after a basic block has been copied. (expand_scalar_variables): Same. (graphite_rename_variables): Renamed rename_variables. (move_phi_nodes): Removed. (get_false_edge_from_guard_bb): New. (build_iv_mapping): Do not insert the induction variable of a loop in the renaming iv map if the basic block does not belong to that loop. (register_old_new_names, graphite_copy_stmts_from_block, copy_bb_and_scalar_dependences): New. (translate_clast): Heavily reimplemented: copy basic blocks, do not move them. Finally, in call cleanup_tree_cfg in gloog. At each translation step call graphite_verify ensuring the consistency of the SSA, loops and dominators information. (collect_virtual_phis, find_vdef_for_var_in_bb, find_vdef_for_var_1, find_vdef_for_var, patch_phis_for_virtual_defs): Removed huge hack. (mark_old_loops, remove_dead_loops, skip_phi_defs, collect_scop_exit_phi_args, patch_scop_exit_phi_args, gbb_can_be_ignored, scop_remove_ignoreable_gbbs, ): Removed. (remove_sese_region, ifsese, if_region_entry, if_region_exit, if_region_get_condition_block, if_region_set_false_region, create_if_region_on_edge, move_sese_in_condition, bb_in_sese_p, sese_find_uses_to_rename_use, sese_f
[Bug tree-optimization/38464] [4.4 Regression] vect/costmodel/ppc/costmodel-slp-12.c fails to vectorize
--- Comment #1 from irar at gcc dot gnu dot org 2008-12-11 07:15 --- Subject: Bug 38464 Author: irar Date: Thu Dec 11 07:13:47 2008 New Revision: 142672 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142672 Log: PR tree-optimization/38464 * gcc.dg/vect/costmodel/ppc/costmodel-slp-12.c: Check that three loops are vectorized. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-slp-12.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38464
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #63 from steven at gcc dot gnu dot org 2008-12-11 07:03 --- Re. comment #62: Transforming the code and adding notes to allow the compiler to undo the transformation is not an option with the available infrastructure in GCC. You'd have to add some kind of note (something like REG_EQUAL) to GIMPLE, and then, maybe it is possible -- but still only when profile information is available (i.e. practically never for -Os or for the kernel). I agree with Zdenek that the best solution for now, to fix this regression, is to honor the user's decision to use a loop. For anything more fancy than that, patches welcome ;-) You also have to keep in mind that the issue in this problem report is that GCC introduces a div. That is the regression here, and the only thing we should be addressing in this PR, IMHO. The issue is *not* that GCC could do better at recognizing situations where divmod could be used. GCC has never been able to do that, so there is no regression in that regard. If someone wishes to add some kind of idiom recognition for divmod to GCC, and/or optimization hints from GIMPLE to RTL via a GIMPLE-equivalent of REG_EQUAL, then he/she should open new PRs for that, marked "enhancement". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-11 04:42 --- So the problem with the stores here is that the base is arg_pointer_rtx which is still a frame pointer related offset. I think the same can be said is true of stack_pointer_rtx too. We only set frame_related for frame_pointer_rtx and hard_frame_pointer_rtx but arg_pointer_rtx will become a frame pointer later one too. The only issue is that there might not be correct dependencies with respect of arg_pointer_rtx. Kenny, Do you agree? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug c/38483] New: generated aborts lose previous side-effects
When the compiler generates an abort for runtime-undefined code, the abort
can be executed too soon when side-effects before the undefined behavior
might have caused the undefined behavior not to happen after all.
For calls to functions cast to incompatible types, the undefined behavior
happens when the call does, which is after all the arguments (and the function
designator) have been evaluated. So they need to be evaluated for their
side-effects before the abort is evaluated. The following testcase illustrates
this; it should exit successfully but instead aborts.
extern void exit (int);
extern void abort (void);
int
foo (void)
{
exit (0);
return 0;
}
void
bar (void)
{
}
int
main (void)
{
((long (*)(int))bar) (foo ());
abort ();
}
Much the same applies to va_arg, although the validity of the programs in this
case is less clear (because the argument passed to va_arg isn't actually
an object declared by the calling function).
#include
extern void exit (int);
extern void abort (void);
va_list ap;
float f;
va_list *
foo (void)
{
exit (0);
return ≈
}
void
bar (int i, ...)
{
va_start (ap, i);
f = va_arg (*foo (), float);
va_end (ap);
}
int
main (void)
{
bar (1, 0);
abort ();
}
--
Summary: generated aborts lose previous side-effects
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
OtherBugsDependingO 16620,16989
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38483
[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)
--- Comment #45 from amylaar at gcc dot gnu dot org 2008-12-11 02:07 --- (In reply to comment #44) > Subject: Re: [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts > not understanding autoincrement) > > Joern, can you attach the updated patch? I still wait for confirmation from the FSF that our Copyright assignment has been filed. In the meantime, I'll send you the patch by personal email. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug testsuite/35677] Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-12-11 02:02 --- This patch appears to solve the issue on i686-apple-darwin9 from the couple testsuite runs I have done in libgomp. === libgomp Summary for unix/-m32 === # of expected passes2071 # of unsupported tests 128 === libgomp Summary for unix/-m64 === # of expected passes2071 # of unsupported tests 128 === libgomp Summary === # of expected passes4142 # of unsupported tests 256 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #12 from hjl dot tools at gmail dot com 2008-12-11 01:17
---
This program shows the problem:
[EMAIL PROTECTED] 37144]$ cat x.cc
#include
#include
struct T1
{
int i;
T1 () { i = 0; }
T1 (int x) { i = x; }
T1 (const T1 &x) { i = x.i; }
T1&
operator=(T1 & __p)
{
i = __p.i;
return *this;
}
};
struct pair
{
T1 first;
T1 second;
pair() : first(), second() { }
pair(const T1 & __a, const T1 & __b) : first(__a), second(__b) { }
pair&
operator=(pair& __p)
{
first = __p.first;
second = __p.second;
return *this;
}
};
typedef const T1& const_T1_reference;
typedef const pair & const_pair_reference;
const_T1_reference
extract_key_imp(const_pair_reference r_val)
{ return r_val.first; }
const_T1_reference
extract_key_imp(const_T1_reference r_val)
{ return r_val; }
int
main ()
{
T1 t1 (21), t2 (3);
pair p (t1, t2);
const_T1_reference x = extract_key_imp (p);
const_T1_reference y = extract_key_imp (t1);
if (y.i != t1.i)
abort ();
if (&y.i != &t1.i)
abort ();
if (x.i != t1.i)
abort ();
if (&x.i != &t1.i)
{
printf ("&x.i != &t1.i\n");
abort ();
}
return 0;
}
[EMAIL PROTECTED] 37144]$ g++ x.cc
[EMAIL PROTECTED] 37144]$ ./a.out
&x.i != &t1.i
Aborted
[EMAIL PROTECTED] 37144]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libgcj/10353] [4.2/4.3/4.4 regression] Java testsuite failures
--- Comment #32 from ghazi at gcc dot gnu dot org 2008-12-11 01:10 --- (In reply to comment #31) > How can this be a regression bug if there's not a single known-to-work > revision? When I originally opened this PR, my opening comment noted that the java failures I encountered were regressions from the 3.2.x series. Annoyingly my comment doesn't actually list the testcases that were failing. That doesn't seem like something I would normally leave out. :-) After some digging I realized that's because the PR originally listed them in the Summary: field. Somewhere along the line this PR got renamed to a generic "java testsuite failures", I think it was Eric in comment#14. You can see the original summary here from the gcc-bugs mailing list: http://gcc.gnu.org/ml/gcc-bugs/2003-04/msg00378.html For the record, those failing testcases were: Array_3, TLtest, Thread_Join, Thread_Wait_Interrupt & Throw_2. Here is my testsuite results from the 3.2.3 release where the testcases pass: http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg01566.html Here is a 3.3.x result from around the same time showing the failures: http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg01574.html Anyway, I no longer have access to solaris boxes. I looked for recent testsuite results to see if those testcases are still failing. It was hard because many people seem to post solaris2 results without java enabled. (You know who you are!) Here's a couple from 4.4 trunk on solaris2.10 and 2.11 that shows they aren't failing. In fact the results actually look pretty good: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01758.html http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg00647.html I originally reported the bugs against solaris2.7, so I don't know if the testcases got "fixed" by the OS upgrade or something done in GCC. Someone with an older solaris would have to double check. Maybe Joe Buck who has solaris2.8 could help with that. If Joe's tests show that the specific failures I mentioned don't appear in solaris2.8, then I would say it's fair to either close this PR and note the remaining solaris failures in their own PRs, or at least no longer call this PR a "regression". I would lean towards the former, i.e. close this PR once we verify an older solaris release and track any remaining failures in new PRs. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||joe dot buck at synopsys dot ||com Known to work||3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #11 from hjl dot tools at gmail dot com 2008-12-11 00:46
---
testsuite/util/regression/trait/assoc/type_trait.hpp has
static const_key_reference
extract_key_imp(pair_type_const_reference r_val)
{ return r_val.first; }
It may create a temporary on stack and return a reference to
the stack temporary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug testsuite/35677] Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-11 00:44 --- The patch is correct if not obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug testsuite/35677] Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-11 00:40 --- Subject: Re: Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90" > I'll try a build of current gcc trunk with your patch and see if it helps. Problem looks the same. You can do a quick check without a full rebuild by removing the emultls* files from the libgcc directories, apply patch, do make in top libgcc directory, then rerun libgomp testsuite. The failures occur because multiple threads read an offset value of 0. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #62 from mmitchel at gcc dot gnu dot org 2008-12-11 00:42 --- I take Zdenek's point about the transformation from division to a loop being profitable only if x is small. But, that might argue that if we see the loop, we still transform it into the division form -- but with a note that allows the value-profiling code to turn it back. The advantage to that is we can then take advantage of the fact that it's division otherwise; for example, CSE it with a manually written division, or eliminate it if multiplied by the same value we divided by, etc. There are a bunch of issues somewhat tangled up in here. In any case, I am also concerned about the fact that if the user writes division and modulus manually, we're not taking advantage of the ABI divmod function. IIUC, it sounds like we could fix that by having the ARM back end always use the divmod function as on x86. Is that right? -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug c/25314] [4.2/4.3/4.4 Regression] Unreachable code at beginning of switch statement is not reported anymore
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-11 00:35:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314
[Bug testsuite/35677] Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-12-11 00:28 --- On i686-apple-darwin9, configured as... Using built-in specs. Target: i686-apple-darwin9 Configured with: ../gcc-4.4-20081209/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.4.0 20081210 (experimental) (GCC) I get... rogram received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x [Switching to process 560 thread 0x313] 0x1ae9 in MAIN__.omp_fn.0 () (gdb) bt #0 0x1ae9 in MAIN__.omp_fn.0 () #1 0x0001a204 in gomp_thread_start (xdata=0xbfffe7f0) at ../../../gcc-4.4-20081209/libgomp/team.c:118 #2 0x910c4095 in _pthread_start () #3 0x910c3f52 in thread_start () I assume I am using emutls since I see... nm crayptr2.exe | grep emut 1cd0 t ___emutls_get_address 1c90 t ___emutls_register_common 2014 d ___emutls_v.ip.1499 1f10 t _emutls_destroy 1ed0 t _emutls_init 2090 b _emutls_key 2040 d _emutls_mutex 2094 b _emutls_size I'll try a build of current gcc trunk with your patch and see if it helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #61 from rakdver at kam dot mff dot cuni dot cz 2008-12-11 00:28 --- Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns > Furthermore, if we want to generate the loop instead, are the alternatives > you're considering sufficient to change code like: > > ... x / 45 ... > > into the loop form? Although I think this is somewhat unrelated, we actually already do this (see value-prof.c). > The style: > > a = x / N; > b = x % N; > > is pretty common; recognizing that pattern and generating a loop, or libcall > to > __aeabi_divmod, seems like a good thing. One could argue that __aeabi_divmod > itself should be responsible for noticing divisors that more profitably use > repeated subtraction than other methods, on CPUs that don't have a hardware > divide instruction. The problem is that "profitably" depends on how large x is (i.e., using the loop is only profitable when x is small). As mentioned, we already do the transformation in profile-driven optimizer, when we have this information. > Do we need a divmod optab? Or, should we expect that if we provide an > appropriate pattern in the ARM back end, combine will be able to smush the > division and remainder operations together? I think it should be able to (IIRC, we do so on x86). > I guess where I'm going with this line of thinking is to argue that the > transformation to division is fine, and that we should treat that as canonical > -- but that we need a way to change divisions into repeated divisions if > appropriate. Users usually use this pattern (division by repeated subtraction) only if the result is small; so transforming to actual division makes the code worse (and understandably, the user angry :-) Unless profiling is used, compiler does not have enough information to determine which form is better, so I think we should prefer to keep whatever form was originally in the program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #60 from steven at gcc dot gnu dot org 2008-12-11 00:27 --- IMHO I the transformation to division is not fine. I would argue this is the core issue in this problem report. You are right that a combination of div and mod is quite common in real-world code. Right now, GCC can catch that when the port emits a divmod libcall by default instead of just a div and/or a mod. However, I consider this a separate issue. GCC currently does not recognize div/mod or mod/div as patterns, because at the tree level this would show up as two separate expressions (possibly with statements between the div and mod expresssions), and expand works one statement at a time. Some targets (e.g. x86) call a divmod libcall by default for a div or a mod instruction. If there is a div/mod or mod/div sequence in the code, GCC optimizes away one of the libcalls via the REG_EQUAL notes, IIRC. But our concern now should be to avoid this situation where gcc "invents" a div or mod instruction in the first place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug fortran/32715] improve diagnostics of attempted allocation of non-array
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-11 00:16 --- The patch I submitted, here: http://gcc.gnu.org/ml/fortran/2008-12/msg00167.html gives troutmask:sgk[224] gfc4x -o z k.f90 k.f90:2.10: ALLOCATE(i(3)) 1 Error: Allocate-object at (1) is not a nonprocedure pointer or an allocatable variable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32715
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #59 from mmitchel at gcc dot gnu dot org 2008-12-11 00:14 --- Steven, Zdenek -- Is there any way to teach the compiler to use the ARM __aeabi_divmod routine, which provides both the quotient and remainder? At least with -Os, that is probably optimal. In other words, once we get to: prop0 = D.1286 % 45; propsRes->pb = [plus_expr] (propsRes->pb + 1) + (int) (D.1286 / 45); can we notice that we have both "D.1286 % 45" and "D.1286 / 45" and use the divmod routine? Furthermore, if we want to generate the loop instead, are the alternatives you're considering sufficient to change code like: ... x / 45 ... into the loop form? In other words, rather than just considering this a problem of transforming the hand-written loop into a division operation, shouldn't we also be considering the problem of transforming division into the loop form? The style: a = x / N; b = x % N; is pretty common; recognizing that pattern and generating a loop, or libcall to __aeabi_divmod, seems like a good thing. One could argue that __aeabi_divmod itself should be responsible for noticing divisors that more profitably use repeated subtraction than other methods, on CPUs that don't have a hardware divide instruction. Do we need a divmod optab? Or, should we expect that if we provide an appropriate pattern in the ARM back end, combine will be able to smush the division and remainder operations together? I guess where I'm going with this line of thinking is to argue that the transformation to division is fine, and that we should treat that as canonical -- but that we need a way to change divisions into repeated divisions if appropriate. -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug c/25314] [4.2/4.3/4.4 Regression] Unreachable code at beginning of switch statement is not reported anymore
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-11 00:10 --- Created an attachment (id=16882) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16882&action=view) proposed patch Looking for comments in this patch... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314
[Bug libgcj/10353] [4.2/4.3/4.4 regression] Java testsuite failures
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-12-10 23:31 --- How can this be a regression bug if there's not a single known-to-work revision? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
[Bug libstdc++/38128] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
--- Comment #5 from danglin at gcc dot gnu dot org 2008-12-10 23:27 --- The bug in the CFI directives turned out to be a GAS bug. Two patches were applied to fix the problem (one be Jakub and one by myself). A configure test was added to detect broken versions of GAS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38128
[Bug java/37900] [4.4 Regression] StringBuffer_1 failures
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-10 23:20 --- Fixed as of revision 142637. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37900
[Bug libgcj/10353] [4.2/4.3/4.4 regression] Java testsuite failures
--- Comment #30 from steven at gcc dot gnu dot org 2008-12-10 23:18 --- This one is just dragged along with the Summary changes every time a new GCC is released. I'd say WONTFIX for this bug. Eric, you would "add a blurb about that in the platform-specific installation notes" (comment #25). Did that happen? What do you, as a SPARC port maintainer, think what should happen with this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
[Bug libstdc++/17789] [4.2/4.3/4.4 Regression] Cannot 'make check' inside libstdc++-v3
--- Comment #13 from hjl dot tools at gmail dot com 2008-12-10 23:16 --- (In reply to comment #12) > This one is really old. HJ, do you know if this is still an issue? What > happened with your patch? > I don't know. All my machines have libunwind.so.7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17789
[Bug ada/36939] Build Failure Ada SH2e
--- Comment #10 from laurent at guerby dot net 2008-12-10 23:09 --- Ok I'll try to come up with a real patch. -- laurent at guerby dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |laurent at guerby dot net |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939
[Bug java/37900] [4.4 Regression] StringBuffer_1 failures
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-10 23:09 --- Seen in r141389 (http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01966.html) Not seen anymore in r141405 (http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg02014.html) HJ, looks fixed to me...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37900
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #10 from hjl dot tools at gmail dot com 2008-12-10 23:07 --- (gdb) f 0 #0 __gnu_pbds::test::detail::container_rand_regression_test<__gnu_pbds::trie<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_pbds::string_trie_e_access_traits<__gnu_pbds::test::basic_type, (char)97, (char)100, false, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::pat_trie_tag, __gnu_pbds::null_trie_node_update, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> > >::insert (this=0x7fffc990) at /export/gnu/src/gcc-work/gcc/libstdc++-v3/testsuite/util/regression/rand/assoc/container_rand_regression_test.tcc:1086 1086 typename cntnr::const_point_iterator found_it = m_p_c->find(r_k); (gdb) p/x $rsp $14 = 0x7fffc710 (gdb) p/x &r_k $15 = 0x7fffc6c0 (gdb) p &v $16 = ( std::pair *) 0x7fffc750 (gdb) p r_k._M_dataplus._M_p $17 = 0x7e2d28 "dbcabab" (gdb) p v.first._M_dataplus._M_p $18 = 0x7e2d28 "dbcabab" (gdb) r_k references a value on deallocated stack. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC|danglin at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #7 from jv244 at cam dot ac dot uk 2008-12-10 22:57 --- (In reply to comment #6) > Created an attachment (id=16881) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16881&action=view) [edit] > memory measurement tool > > Of course! Try the attached with just > > ~/bin/maxmem2.sh gfortan ... > ugh how intuitive... but very useful. Will try to run it tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #58 from rakdver at gcc dot gnu dot org 2008-12-10 22:55 --- (In reply to comment #56) > Re. comment #52: > > I've pasted the test case in the audit trail here as plain text -- it's pretty > small and it shows the problem nicely. The issue is that with -Os, on all > targets, the line, > > propsRes->lc = prop0; > > is replaced with: > > propsRes->lc = (int) (int) (prop0.24 % 45); // with prop0.24 = propsData[0]; > > so there is no div/mod instruction in the original code, but one appears as a > result of the final value replacement optimization. With -O2 there is also a > div instruction, but I am not sure where it comes from (I suspect loop header > copying, but it's inconsequential for this issue anyway). actually, the div instruction also comes from the final value replacement. We eliminate the loop completely and replace it with the following: D.1286 = prop0 + 211; prop0 = D.1286 % 45; propsRes->pb = [plus_expr] (propsRes->pb + 1) + (int) (D.1286 / 45); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-12-10 22:48 --- Created an attachment (id=16881) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16881&action=view) memory measurement tool Of course! Try the attached with just ~/bin/maxmem2.sh gfortan ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #9 from hjl dot tools at gmail dot com 2008-12-10 22:44 --- testsuite/util/regression/rand/assoc/container_rand_regression_test.tcc has value_type v = test_traits::generate_value(m_g, m_m); m_alloc.set_throw_prob(m_tp); const_key_reference r_k = test_traits::extract_key(v); typename cntnr::const_point_iterator found_it = m_p_c->find(r_k); It looks like test_traits::extract_key returns something on stack and r_k references a value on deallocated stack. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug middle-end/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
--- Comment #4 from sebpop at gmail dot com 2008-12-10 22:37 --- Subject: Re: [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop. On Wed, Dec 10, 2008 at 4:34 PM, hjagasia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #3 from hjagasia at gcc dot gnu dot org 2008-12-10 22:34 > --- > Created an attachment (id=16880) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16880&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16880&action=view) > Updated patch reviewed by Sebastian This looks better thanks. Ok for graphite branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
Re: [Bug middle-end/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
On Wed, Dec 10, 2008 at 4:34 PM, hjagasia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #3 from hjagasia at gcc dot gnu dot org 2008-12-10 22:34 > --- > Created an attachment (id=16880) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16880&action=view) > Updated patch reviewed by Sebastian This looks better thanks. Ok for graphite branch.
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #5 from jv244 at cam dot ac dot uk 2008-12-10 22:34 --- (In reply to comment #4) > Could you capture the memory requirements on the 4.3 branch? I watched top (for 4.3.1), but can't recall anything more than 3Gb. It's a bit boring to watch top for 45min any better approach? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug middle-end/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
--- Comment #3 from hjagasia at gcc dot gnu dot org 2008-12-10 22:34 --- Created an attachment (id=16880) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16880&action=view) Updated patch reviewed by Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)
--- Comment #7 from jv244 at cam dot ac dot uk 2008-12-10 22:33 --- with current graphite, i see 4 files failing with -fgraphite -fgraphite-identity: lebedev.F, colvar_types.F, qs_linres_nmr_shift.F, constraint_clv.F I'm assuming that these are all incarnations of PR38461, but can look into more detail if that's considered useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)
--- Comment #44 from stevenb dot gcc at gmail dot com 2008-12-10 22:30 --- Subject: Re: [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement) Joern, can you attach the updated patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-12-10 22:18 --- Subject: Bug 36792 Author: rguenth Date: Wed Dec 10 22:17:05 2008 New Revision: 142662 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142662 Log: 2008-12-10 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/36792 * tree-ssa-pre.c (compute_avail): Handle tcc_comparison like tcc_binary. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-12-10 22:17 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug c++/35319] [4.3/4.4 regression] ICE throwing fixed-point types
--- Comment #6 from jason at gcc dot gnu dot org 2008-12-10 22:13 --- Subject: Bug 35319 Author: jason Date: Wed Dec 10 22:11:44 2008 New Revision: 142661 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142661 Log: PR c++/35319 * mangle.c (write_builtin_type): Add mangling for decimal floating point and fixed point types. (write_type): Pass FIXED_POINT_TYPE along. * cp-demangle.c (cplus_demangle_type): Support fixed-point types. (d_print_comp, d_dump): Likewise. Added: trunk/gcc/testsuite/g++.dg/ext/fixed2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
[Bug middle-end/38463] [graphite] double free or corruption
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-10 22:04 --- (In reply to comment #3) > Hi, I can not reproduce this Bug on FreeBSD. May be it is just not detected. > > Can you try with current graphite branch to see it was a duplicate of > Bug3845384599. > Otherwise I will have to try it on Linux with valgrind again. > I think it is a dup of PR38459, since it is gone after updating to the current graphite branch. Great! I'm closing it as fixed. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38463
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #57 from rakdver at kam dot mff dot cuni dot cz 2008-12-10 22:02 --- Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns > I think Zdenek is right in comment #54: We should reincarnate > expression_expensive_p in some form such that it takes into account (or makes > a > reasonable guess about) which instructions are particularly expensive. > Apparently, the old cost check was too conservative (it tested the expression > cost against spill cost, ignoring further optimization opportunities). So we > need to test for something else than before. > > Maybe we should not replace if the final value is not a constant? That is way too conservative (replacing the final values like say "n + 1" should usually be profitable). > Or if it is an expression involving div/mod? That is what I currently plan to do. > Can we test somehow how many insns the final > value replacement computation would take I think that has the same problems as the original solution (it is not possible to find a bound that would both prevent expensive things to be moved out and to allow the non-expensive ones, as the exact costs are target-specific and we are not estimating them precisely enough). > (maybe re-use the inliner heuristics)? That would be difficult, as estimate_num_insns works on gimple statements, not on expressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug testsuite/35677] Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-10 22:01 --- Subject: Re: Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90" On Wed, 10 Dec 2008, howarth at nitro dot med dot uc dot edu wrote: I need to do some more testing but I believe the attached patch fixes the failure on hppa*-*-hpux*. Dave --- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-10 22:01 --- Created an attachment (id=16879) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16879&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #56 from steven at gcc dot gnu dot org 2008-12-10 21:44 --- Re. comment #52: I've pasted the test case in the audit trail here as plain text -- it's pretty small and it shows the problem nicely. The issue is that with -Os, on all targets, the line, propsRes->lc = prop0; is replaced with: propsRes->lc = (int) (int) (prop0.24 % 45); // with prop0.24 = propsData[0]; so there is no div/mod instruction in the original code, but one appears as a result of the final value replacement optimization. With -O2 there is also a div instruction, but I am not sure where it comes from (I suspect loop header copying, but it's inconsequential for this issue anyway). The problem is not that we don't give CSE enough information. The problem is reported for a GCC 4.3 based compiler, which still has libcall notes. So at least in theory, CSE in GCC 4.3 should have all the information available to optimize away the mod instruction. Apparently the result is just not available. The bottom line, then, is still that the final value replacement has introduced an operation at the tree level that doesn't have a matching RTL instruction. In this case a mod insn that makes gcc produce a libcall to umodsi. I think Zdenek is right in comment #54: We should reincarnate expression_expensive_p in some form such that it takes into account (or makes a reasonable guess about) which instructions are particularly expensive. Apparently, the old cost check was too conservative (it tested the expression cost against spill cost, ignoring further optimization opportunities). So we need to test for something else than before. Maybe we should not replace if the final value is not a constant? Or if it is an expression involving div/mod? Can we test somehow how many insns the final value replacement computation would take (maybe re-use the inliner heuristics)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-12-10 11:42:50 |2008-12-10 21:31:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #55 from steven at gcc dot gnu dot org 2008-12-10 21:27 ---
// This is the test case from PR38453.
// See comment #0 of that bug for further information:
// http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38453#c0
typedef struct
{
int lc;
int pb;
} bar;
void foo(bar *propsRes, const unsigned char *propsData)
{
unsigned char prop0;
prop0 = propsData[0];
while (prop0 >= 45) {
propsRes->pb++;
prop0-=45;
}
propsRes->lc = prop0;
}
int main(int argc, char **argv)
{
bar propsRes;
unsigned char propsData[1024];
foo(&propsRes, propsData);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
fwrite bug in gcc 4.4.0.
2008-12-10
[EMAIL PROTECTED]
The following report demonstrates a bug in fwrite():
when attempting to write 8GB, it silently only writes 3.7GB yet
issues no errors. There is plenty of disk space and free memory.
Platform:
Mac OS X 10.5.5, gcc version 4.4.0, compiled -m64 for 64-bit (x86_64).
/*
fwrite_bug.c - Show bug in fwrite: silently only writes 3.7GB instead of 8GB.
2008-12-10 [EMAIL PROTECTED]
/usr/local/bin/gcc -v -m64 -g -o fwrite_bug fwrite_bug.c
file fwrite_bug
fwrite_bug
ls -l junk
*/
#include /* For malloc(), free(). */
#include /* For memset(). */
#include /* For FILE, printf(), perror(). */
int main( void ) {
const size_t bytes = 80UL; /* 8GB file. */
int ok = 0;
char* array = malloc( bytes );
printf( "sizeof (size_t) = %lu, bytes = %lu, array = %p\n",
sizeof (size_t), bytes, array );
if ( array ) {
FILE* file = fopen( "junk", "wb" );
memset( array, 0, bytes );
if ( file ) {
const size_t bytes_written = fwrite( array, 1, bytes, file );
int fclose_result = 0;
printf( "Bytes written = %lu\n", bytes_written );
if ( bytes_written == bytes ) {
const int flush_result = fflush( file );
ok = flush_result == 0;
}
printf( "ferror = %d\n", ferror( file ) );
fclose_result = fclose( file );
ok = ok && fclose_result == 0;
file = 0;
}
free( array );
array = 0;
}
if ( ! ok ) {
perror( "Failed because " );
}
return ! ok;
}
$/usr/local/bin/gcc -v -m64 -g -o fwrite_bug fwrite_bug.c
Using built-in specs.
Target: i386-apple-darwin9.4.0
Configured with: ../gcc-4.4-20080801/configure --enable-languages=fortran,c++
Thread model: posix
gcc version 4.4.0 20080801 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.5' '-v' '-m64' '-g' '-o'
'fwrite_bug' '-mtune=generic'
/usr/local/libexec/gcc/i386-apple-darwin9.4.0/4.4.0/cc1 -quiet -v -imultilib
x86_64 -D__DYNAMIC__ fwrite_bug.c -fPIC -feliminate-unused-debug-symbols -quiet
-dumpbase fwrite_bug.c -mmacosx-version-min=10.5.5 -m64 -mtune=generic -auxbase
fwrite_bug -g -version -o /var/tmp//ccbd2VJl.s
ignoring nonexistent directory
"/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/../../../../i386-apple-darwin9.4.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/include
/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
GNU C (GCC) version 4.4.0 20080801 (experimental) (i386-apple-darwin9.4.0)
compiled by GNU C version 4.4.0 20080801 (experimental), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e18605928a7028ba0647a6828b0edd07
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.5' '-v' '-m64' '-g' '-o'
'fwrite_bug' '-mtune=generic'
as -arch x86_64 -force_cpusubtype_ALL -o /var/tmp//ccq6skQ8.o
/var/tmp//ccbd2VJl.s
COMPILER_PATH=/usr/local/libexec/gcc/i386-apple-darwin9.4.0/4.4.0/:/usr/local/libexec/gcc/i386-apple-darwin9.4.0/4.4.0/:/usr/local/libexec/gcc/i386-apple-darwin9.4.0/:/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/:/usr/local/lib/gcc/i386-apple-darwin9.4.0/
LIBRARY_PATH=/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/x86_64/:/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/../../../x86_64/:/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/:/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.5' '-v' '-m64' '-g' '-o'
'fwrite_bug' '-mtune=generic'
/usr/local/libexec/gcc/i386-apple-darwin9.4.0/4.4.0/collect2 -dynamic -arch
x86_64 -macosx_version_min 10.5.5 -weak_reference_mismatches non-weak -o
fwrite_bug -lcrt1.10.5.o
-L/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/x86_64
-L/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/../../../x86_64
-L/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0
-L/usr/local/lib/gcc/i386-apple-darwin9.4.0/4.4.0/../../.. /var/tmp//ccq6skQ8.o
-lgcc_s.10.5 -lgcc -lSystem
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.5' '-v' '-m64' '-g' '-o'
'fwrite_bug' '-mtune=generic'
dsymutil fwrite_bug
$file fwrite_bug
fwrite_bug: Mach-O 64-bit executable x86_64
$fwrite_bug
sizeof (size_t) = 8, bytes = 80, array = 0x10020
Bytes written = 80
ferror = 0
$ls -l junk
-rw-rw-r-- 1 plessel staff 3705032704 Dec 10 15:12 junk
Note how the call to fwrite() reports that it wrote 8GB and
fflush() did not fail and ferror() reports no problems and
fclose() did not fail
yet the file is only 3.7GB instead of 8GB!
What is the fix?
[EMAIL PROTECTED]
[Bug middle-end/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
--- Comment #2 from hjagasia at gcc dot gnu dot org 2008-12-10 21:09 --- Created an attachment (id=16877) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16877&action=view) This patch fixes PR38446 by explicitly checking if bb belongs to sese region by looking at all bbs in scop instead of using dominator/post-dominator information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38446
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-12-10 20:56 --- Which is not vectorized because PRE doesn't move the invariant D.2067_11 = a_9(D) == b_10(D); out of the loop. If you make LIM do it (--param lim-expensive=1) the loop is vectorized again. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2008-07-10 14:59:59 |2008-12-10 20:56:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-12-10 20:38 --- All fixed now apart from FAIL: gcc.dg/vect/vect-67.c scan-tree-dump-times vect "vectorized 1 loops" 1 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords|xfail | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug testsuite/29071] gcc.dg/20020919-1.c compilation test fails on powerpc-apple-darwin8 at -m64
--- Comment #8 from dominiq at lps dot ens dot fr 2008-12-10 20:31 --- PING! see comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29071
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #12 from dberlin at gcc dot gnu dot org 2008-12-10 20:15 --- Subject: Bug 36792 Author: dberlin Date: Wed Dec 10 20:13:39 2008 New Revision: 142659 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142659 Log: 2008-12-10 Daniel Berlin <[EMAIL PROTECTED]> PR tree-optimization/36792 * tree-ssa-pre.c (compute_avail): Don't insert defs into maximal set. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-10.c trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug fortran/35937] Wrong type for charlength of function
--- Comment #15 from dominiq at lps dot ens dot fr 2008-12-10 19:15 --- No regression also on powerpc-apple-darwin9 (patch in comment#4). If I understand the two proposed patches, the only difference is that the FX's one create a temporary if CONSTANT_CLASS_P (se.expr) is not true. Is this really necessary? For what "se.expr" will CONSTANT_CLASS_P return false? -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug ada/36939] Build Failure Ada SH2e
--- Comment #9 from joel at gcc dot gnu dot org 2008-12-10 19:14 --- ACATS look surprisingly good with the fix in: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01013.html sh-rtems4.10-gcc (GCC) 4.4.0 20081210 (experimental) [trunk revision 142643] === acats Summary === # of expected passes 2307 # of unexpected failures 5 # of unsupported tests 3 ce2108f - simulator does not have persistent files ce2108h - simulator does not have persistent files ce3112d - simulator does not have persistent files c380004 c953002 c974013 cxg2018 cxg2021 were Memory exception at 44000 (illegal address) the last time I checked on them according to my notes. === Logs for failed tests == -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939
[Bug tree-optimization/38478] [4.3 Regression] incorrect results for polynomial evaluation with optimisation/inline functions
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-10 18:43 --- Fixed for 4.3.3. (and dup of PR38051) *** This bug has been marked as a duplicate of 38051 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38478
[Bug tree-optimization/38051] [4.4 Regression] Miscompilation of glibc's memcmp
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-12-10 18:43 --- *** Bug 38478 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bjg at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38051
[Bug tree-optimization/38478] [4.3 Regression] incorrect results for polynomial evaluation with optimisation/inline functions
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-12-10 18:44 --- Subject: Bug 38478 Author: rguenth Date: Wed Dec 10 18:42:36 2008 New Revision: 142655 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142655 Log: 2008-12-10 Richard Guenther <[EMAIL PROTECTED]> Backport from trunk the fix for PR38051. PR tree-optimization/38478 * tree-ssa-structalias.c (update_alias_info): Manually find written variables. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38478
[Bug tree-optimization/38478] [4.3 Regression] incorrect results for polynomial evaluation with optimisation/inline functions
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-10 18:35 ---
This looks the same as PR37868 (or more specifically it matches PR38048, a dup
of that). Indeed, on the branch with -O2 it works. But it seems to be still
broken with -O --param max-fields-for-field-sensitive=100 (but we shouldn't
care too much about that - this setting may be broken anyway).
optimized dump difference reveals that we remove initializations over-eagerly:
:
- c[0] = 1.0e+0;
- c[1] = 5.0e-1;
- c[2] = 2.99988897769753748434595763683319092e-1;
- D.3671 = (c[1] + 1.49994448884876874217297881841659546e-1) *
5.0e
-1;
- gsl_test_rel (c[0] + D.3671,
1.3249555910790149937383830547332763
7e+0, 2.220446049250313080847263336181640625e-14, &"gsl_poly_eval({1, 0.5,
0.3},
0.5)"[0]);
+ D.3656 = (c[1] + 1.49994448884876874217297881841659546e-1) *
5.0e-1;
+ gsl_test_rel (c[0] + D.3656,
1.32495559107901499373838305473327637e+0,
2.220446049250313080847263336181640625e-14, &"gsl_poly_eval({1, 0.5, 0.3},
0.5)"[0]);
so, this may be related to PR38051 / PR38169. I'm checking the backport
I have around. Yup, that fixes it fully. Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-12-10 18:35:39
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38478
[Bug fortran/38471] [4.3/4.4 Regression] ICE with subreference pointer where pointer is a DUMMY argument
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-10 18:25 ---
OK. I found it, though I'm not sure yet how to solve it best (maybe something
else needs to be moved up as well?) - and I won't have time to work on this the
next day(s?).
gfc_get_symbol_decl (gfc_symbol * sym)
[...]
if ((sym->attr.dummy && ! sym->attr.function) || (sym->attr.result && byref))
{
// We enter here as the POINTER is a DUMMY
[...]
return sym->backend_decl;
}
[...]
if (sym->attr.subref_array_pointer)
{
tree span;
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3/4.4 Regression] ICE|[4.3/4.4 Regression] ICE
|with subreference pointer |with subreference pointer
||where pointer is a DUMMY
||argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #54 from rakdver at kam dot mff dot cuni dot cz 2008-12-10 18:23 --- Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns > Zdenek, it would certainly be helpful to have the original justification for > your change available. Unfortunately, I do not remember the exact problems (it is almost two years since that change was made). Adding back expression_expensive_p in some conservative form (e.g., checking that the computation involves division, perhaps excluding divisions by a power of two) seems like the easiest way to fix this problem now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug tree-optimization/38478] [4.3 Regression] incorrect results for polynomial evaluation with optimisation/inline functions
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-10 18:14 --- field-sensitive PTA is the trigger. Fails also at -O --param max-fields-for-field-sensitive=100. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|regression |tree-optimization Keywords||wrong-code Known to fail||4.3.2 Known to work||4.2.4 4.4.0 Summary|incorrect results for |[4.3 Regression] incorrect |polynomial evaluation with |results for polynomial |optimisation/inline |evaluation with |functions |optimisation/inline ||functions Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38478
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #53 from rakdver at kam dot mff dot cuni dot cz 2008-12-10 18:15 --- Subject: Re: [4.3/4.4 regression] udivdi3 counterproductive, unwarranted use Hi, > Re. comment #16: > Zdenek, do you remember which revision / patch removed the cost check? rev. 122896 > And do > you recall (or can you recover) some of the missed-optimization bug report > numbers? I tried to find them with a Bugzilla query, but failed. No; the PRs addressed by that patch seem unrelated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug testsuite/35677] Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"
--- Comment #6 from danglin at gcc dot gnu dot org 2008-12-10 18:10 --- On hppa64, I see a "random" segfault in crayptr2.f90 compiled at -O0: (gdb) r Starting program: /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/libgomp/testsuite/crayptr2.xg0 warning: Private mapping of shared library text was not specified by the executable; setting a breakpoint in a shared library which is not privately mapped will not work. See the HP-UX 11i v3 chatr manpage for methods to privately map shared library text. warning: Loadable segment ".tbss" outside of ELF segments warning: Loadable segment ".tbss" outside of ELF segments warning: Loadable segment ".tbss" outside of ELF segments [New process 28502, lwp 2270431] [process 28502, lwp 2270431 exited] [New process 28502, lwp 2270432] [process 28502, lwp 2270432 exited] [New process 28502, lwp 2270433] [process 28502, lwp 2270433 exited] [New process 28502, lwp 2270434] [New process 28502, lwp 2270435] [New process 28502, lwp 2270436] Program received signal SIGSEGV, Segmentation fault. [Switching to process 28502, lwp 2270435] 0x40002d08 in MAIN__.omp_fn.0 (.omp_data_i=Cannot access memory at address 0x0 ) at /mnt/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/crayptr2.f90:23 23l = p .ne. omp_get_thread_num () + 1 Current language: auto; currently fortran (gdb) p/x $pc $1 = 0x40002d08 (gdb) disass 0x40002cf8 0x40002d18 Dump of assembler code from 0x40002cf8 to 0x40002d18: 0x40002cf8 : b,l 0x40002b2c <.stub+60>,rp 0x40002cfc : nop 0x40002d00 : copy r4,dp 0x40002d04 : ldd 0(ret0),ret0 0x40002d08 : ldw 0(ret0),ret0 0x40002d0c : extrd,s ret0,63,32,ret0 0x40002d10 : stw r0,18(r3) 0x40002d14 : cmpb,=,n ret0,r5,0x40002d20 End of assembler dump. (gdb) p/x $ret0 $2 = 0x0 This results from the code loading indirectly data with a the pointer returned from a call to __emutls_get_address: addil LT'__emutls_v.ip.565,%r27 copy %r1,%r28 ldd RT'__emutls_v.ip.565(%r28),%r28 copy %r28,%r26 ldo -48(%r30),%r29 copy %r27,%r4 b,l __emutls_get_address,%r2 nop copy %r4,%r27 ldd 0(%r28),%r28 ldw 0(%r28),%r28 Is darwin also using EMUTLS? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug fortran/38471] [4.3/4.4 Regression] ICE with subreference pointer
--- Comment #2 from burnus at gcc dot gnu dot org 2008-12-10 18:08 ---
Paul, do you have an idea?
span is set in trans-decl.c's gfc_get_symbol_decl:
if (sym->attr.subref_array_pointer)
{
[...]
GFC_DECL_SPAN (decl) = span;
I wondered whether in gfc_check_pointer_assign the attr.subref_array_pointer is
set, but I indeed see:
(gdb) p lvalue->symtree->n.sym->attr.subref_array_pointer
$7 = 1
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
Summary|[4.3/4.4 Regression] ICE on |[4.3/4.4 Regression] ICE
|pointer assignment of nested|with subreference pointer
|derived-type component |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug c/38481] New: Add attribute for custom sentinels
Would be useful to have the sentinel attribute functionalities but for things other than a NULL pointer. Something like: __attribute__(sentinel_custom((int*) -1)) -- Summary: Add attribute for custom sentinels Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38481
[Bug ada/36939] Build Failure Ada SH2e
--- Comment #8 from joel at gcc dot gnu dot org 2008-12-10 18:08 --- Created an attachment (id=16876) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16876&action=view) working s-scaval.adb Not much. Just an empty version of s-scaval.adb that lets the build proceed past this point. I also had to remove the with/use statement. Otherwise an obvious change per your suggestion. Build completed successfully. Now try to running ACATS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939
[Bug c/38480] New: bogus warning with -O3 -Wall: "array subscript is above array bounds"
# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
Bug 37861 looks related, but I'm not sure if the fix is the same; if so, this
can be marked as a duplicate.
Here is the code (foo.c):
unsigned short foobar;
int array[100];
void g(unsigned short j) {
if (j < 100)
array[j]++;
}
void f() {
int i = foobar;
if (i >= 100)
g(foobar);
}
And here is the gcc call and output:
# gcc -O3 -Wall -c foo.c
foo.c: In function f:
foo.c:7: warning: array subscript is above array bounds
foo.c:7: warning: array subscript is above array bounds
Since j is unsigned and the array access only occurs for j < 100, this can
never be out of bounds. The warning message is also somewhat fragile; e.g. it
disappears with any of the following changes:
1. Declaring foobar as volatile.
2. Replacing "if (i >= 100)" by "if (foobar >= 100)"
3. Replacing either of the unsigned shorts by an int or short.
4. Removing the call to g.
--
Summary: bogus warning with -O3 -Wall: "array subscript is above
array bounds"
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: helmert at informatik dot uni-freiburg dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38480
[Bug c/38479] New: Incorrect dwarf generated for function with parameters greater 4 words in length
The following code:
int foo(int p1, int p2, int p3, long long int p4)
{
return 0;
}
Compiled with:
arm-unknown-elf-gcc -c -g foo.c
Using built-in specs.
Target: arm-unknown-elf
Configured with: /home/products/build/gcc/gnu-4.3.2/sources/gcc-4.3.2/configure
--build i686-pc-linux-gnu --host i686-pc-linux-gnu --target arm-unknown-elf
--prefix=/home/products/build/gcc/gnu-4.3.2/i686-pc-linux-gnu/install
--enable-languages=c++,c
--with-gmp=/home/products/build/gcc/gnu-4.3.2/i686-pc-linux-gnu/install
--with-mpfr=/home/products/build/gcc/gnu-4.3.2/i686-pc-linux-gnu/install
--with-included-gettext
Thread model: single
gcc version 4.3.2 (GCC)
Generates the following:
foo.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e1a0c00dmov ip, sp
4: e24dd004sub sp, sp, #4 ; 0x4
8: e92dd800push{fp, ip, lr, pc}
c: e24cb008sub fp, ip, #8 ; 0x8
10: e24dd00csub sp, sp, #12 ; 0xc
14: e50b0010str r0, [fp, #-16]
18: e50b1014str r1, [fp, #-20]
1c: e50b2018str r2, [fp, #-24]
20: e58b3004str r3, [fp, #4]
24: e3a03000mov r3, #0 ; 0x0
28: e1a3mov r0, r3
2c: e24bd00csub sp, fp, #12 ; 0xc
30: e89da800ldm sp, {fp, sp, pc}
Contents of the .debug_abbrev section:
Number TAG
1 DW_TAG_compile_unit[has children]
DW_AT_producer DW_FORM_strp
DW_AT_language DW_FORM_data1
DW_AT_name DW_FORM_strp
DW_AT_comp_dir DW_FORM_strp
DW_AT_low_pc DW_FORM_addr
DW_AT_high_pc DW_FORM_addr
DW_AT_stmt_listDW_FORM_data4
2 DW_TAG_subprogram[has children]
DW_AT_external DW_FORM_flag
DW_AT_name DW_FORM_string
DW_AT_decl_fileDW_FORM_data1
DW_AT_decl_lineDW_FORM_data1
DW_AT_prototyped DW_FORM_flag
DW_AT_type DW_FORM_ref4
DW_AT_low_pc DW_FORM_addr
DW_AT_high_pc DW_FORM_addr
DW_AT_frame_base DW_FORM_data4
DW_AT_sibling DW_FORM_ref4
3 DW_TAG_formal_parameter[no children]
DW_AT_name DW_FORM_string
DW_AT_decl_fileDW_FORM_data1
DW_AT_decl_lineDW_FORM_data1
DW_AT_type DW_FORM_ref4
DW_AT_location DW_FORM_block1
4 DW_TAG_base_type[no children]
DW_AT_byte_sizeDW_FORM_data1
DW_AT_encoding DW_FORM_data1
DW_AT_name DW_FORM_string
5 DW_TAG_base_type[no children]
DW_AT_byte_sizeDW_FORM_data1
DW_AT_encoding DW_FORM_data1
DW_AT_name DW_FORM_strp
The section .debug_info contains:
Compilation Unit @ offset 0x0:
Length:0x82 (32-bit)
Version: 2
Abbrev Offset: 0
Pointer Size: 4
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
< c> DW_AT_producer: (indirect string, offset: 0x17): GNU C 4.3.2
<10> DW_AT_language: 1(ANSI C)
<11> DW_AT_name: (indirect string, offset: 0x31): foo.c
<15> DW_AT_comp_dir: (indirect string, offset: 0x0):
/home/products/tmp/gcc
<19> DW_AT_low_pc : 0x0
<1d> DW_AT_high_pc : 0x34
<21> DW_AT_stmt_list : 0x0
<1><25>: Abbrev Number: 2 (DW_TAG_subprogram)
<26> DW_AT_external: 1
<27> DW_AT_name: foo
<2b> DW_AT_decl_file : 1
<2c> DW_AT_decl_line : 2
<2d> DW_AT_prototyped : 1
<2e> DW_AT_type: <0x77>
<32> DW_AT_low_pc : 0x0
<36> DW_AT_high_pc : 0x34
<3a> DW_AT_frame_base : 0x0 (location list)
<3e> DW_AT_sibling : <0x77>
<2><42>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<43> DW_AT_name: p1
<46> DW_AT_decl_file : 1
<47> DW_AT_decl_line : 1
<48> DW_AT_type: <0x77>
<4c> DW_AT_location: 2 byte block: 91 6c (DW_OP_fbreg: -20)
<2><4f>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<50> DW_AT_name: p2
<53> DW_AT_decl_file : 1
<54> DW_AT_decl_line : 1
<55> DW_AT_type: <0x77>
<59> DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24)
<2><5c>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<5d> DW_AT_name: p3
<60> DW_AT_decl_file : 1
<61> DW_AT_decl_line : 1
<62> DW_AT_type: <0x77>
<66> DW_AT_location: 2 byte block: 91 64 (DW_OP_fbreg: -28)
<2><69>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<6a> DW_AT_name: p4
<6d> DW_AT_decl_file : 1
<6e> DW_AT_decl_line : 1
<6f> DW_AT_type: <0x7e>
<73> DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0)
<1><77>: Abbrev Number: 4 (DW_TAG_base_type)
<78> DW_AT_byte_size : 4
<79> DW_AT_encoding: 5(signed)
<7a> DW_AT_name: int
<1><7e>: Abbrev Number: 5 (DW_TAG_base_type)
<7f> DW_AT_b
[Bug tree-optimization/38458] copy-propagation doesn't handle cycles
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-10 17:53 --- Subject: Bug 38458 Author: rguenth Date: Wed Dec 10 17:51:52 2008 New Revision: 142654 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142654 Log: 2008-12-10 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/38458 * tree-ssa-copy.c (copy_prop_visit_phi_node): For the first argument use the arguments copy-of value. Modified: branches/alias-improvements/gcc/ChangeLog.alias branches/alias-improvements/gcc/tree-ssa-copy.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38458
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-10 17:44 --- The relevant path through the CFG is struct test ctx; : # ctx_108 = VDEF # SMT.120_109 = VDEF # SMT.121_110 = VDEF # SMT.122_111 = VDEF # SMT.123_112 = VDEF __comp_ctor (&ctx); # VUSE D.10437_5 = ci_1(D)->_M_node; D.10438_6 = (struct _List_node *) D.10437_5; # VUSE D.10494_9 = ctx.foo._M_t._M_impl._M_header._M_parent; __y_10 = (struct _Rb_tree_node *) D.10494_9; __y_12 = (struct _Rb_tree_node *) &ctx.foo._M_t._M_impl._M_header; ... : # __y_21 = PHI <__y_56(6), __y_12(2)> ... : D.10504_36 = &__y_21->D.9518; ... ... : __x.13_77 = (const struct _Rb_tree_node *) D.10504_36; # VUSE D.11044_78 = D.10438_6->_M_data.pair_ptr; # VUSE D.11045_79 = __x.13_77->_M_value_field.pair_ptr; (it's not clear to me what &__y_21->D.9518 accesses - this seems to be a magic, anonymous thing. The constraints tell me its at offset zero though.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create
--- Comment #11 from grosser at gcc dot gnu dot org 2008-12-10 17:36 --- The last commit fixed that bug -- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38459
[Bug middle-end/38463] [graphite] double free or corruption
--- Comment #3 from grosser at gcc dot gnu dot org 2008-12-10 17:39 --- Hi, I can not reproduce this Bug on FreeBSD. May be it is just not detected. Can you try with current graphite branch to see it was a duplicate of Bug38459. Otherwise I will have to try it on Linux with valgrind again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38463
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-10 17:37 ---
Note that the reason the diagnostic happens is either a bug in libstdc++ or
the points-to solver or the TBAA pruning in the points-to solver.
In the end we access the object 'ctx' via a pointer of type
const struct _Rb_tree_node *. So the question is if anywhere in 'ctx' there
is such a struct.
It seems to access the _M_t._M_impl._M_header field which is a
_Rb_tree_node_base
but I cannot see a _Rb_tree_node object in it. Instead _Rb_tree_node is
derived
from _Rb_tree_node_base and adds a _M_value_field. But accessing this via
this path in
struct _Rb_tree_impl : public _Node_allocator
{
_Key_compare _M_key_compare;
_Rb_tree_node_base_M_header;
size_type _M_node_count;
certainly violates aliasing rules. I do not see what _Rb_tree_impl::_S_value
wants to access. There seems to be nothing there?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |libstdc++
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug target/37033] [4.4 Regression] Revision 138733 breaks -g vs -g0 for PCH
--- Comment #12 from aoliva at gcc dot gnu dot org 2008-12-10 17:31 --- Fixed. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37033
[Bug middle-end/38271] [4.4 Regression] Spurious / missing "... used uninitialized in this function" warning
--- Comment #10 from aoliva at gcc dot gnu dot org 2008-12-10 17:30 --- Fixed. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
[Bug middle-end/38459] [graphite] SEGFAULT in cloog_clast_create
--- Comment #10 from grosser at gcc dot gnu dot org 2008-12-10 17:35 --- Subject: Bug 38459 Author: grosser Date: Wed Dec 10 17:33:58 2008 New Revision: 142653 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142653 Log: 2008-12-10 Tobias Grosser <[EMAIL PROTECTED]> PR middle-end/38459 * graphite.c (new_scop): Initialize SCOP_ADD_PARAMS. (param_index): Assert if parameter is not know after parameter detection. (find_params_in_bb): Detect params directly in GBB_CONDITIONS. (find_scop_parameters): Mark, that we have finished parameter detection. (graphite_transform_loops): Move condition detection before parameter detection. * graphite.h (struct scop): Add SCOP_ADD_PARAMS. * testsuite/gfortran.dg/graphite/pr38459.f90: New. Added: branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr38459.f90 Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c branches/graphite/gcc/graphite.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38459
[Bug target/37033] [4.4 Regression] Revision 138733 breaks -g vs -g0 for PCH
--- Comment #13 from aoliva at gcc dot gnu dot org 2008-12-10 17:32 --- Subject: Bug 37033 Author: aoliva Date: Wed Dec 10 17:31:07 2008 New Revision: 142652 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142652 Log: gcc/ChangeLog: PR target/37033 * dwarf2out.c (saved_do_cfi_asm): New. (dwarf2out_do_frame): Take it into account. (dwarf2out_d_cfi_asm): Likewise. Set it when appropriate. libcpp/ChangeLog: PR target/37033 * pch.c (cpp_valid_state): Improve message for poisoned symbols. Allow for differences in __GCC_HAVE_DWARF2_CFI_ASM. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/libcpp/ChangeLog trunk/libcpp/pch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37033
[Bug regression/38478] incorrect results for polynomial evaluation with optimisation/inline functions
--- Comment #1 from bjg at gnu dot org 2008-12-10 17:22 --- Created an attachment (id=16875) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16875&action=view) example program (preprocessed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38478
[Bug middle-end/38271] [4.4 Regression] Spurious / missing "... used uninitialized in this function" warning
--- Comment #9 from aoliva at gcc dot gnu dot org 2008-12-10 17:22 --- Subject: Bug 38271 Author: aoliva Date: Wed Dec 10 17:20:50 2008 New Revision: 142651 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142651 Log: gcc/ChangeLog: PR middle-end/38271 * tree-sra.c (sra_build_bf_assignment): Avoid warnings for variables initialized from SRAed bit fields. gcc/testsuite/ChangeLog: PR middle-end/38271 * gcc.dg/torture/pr38271.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/pr38271.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
[Bug regression/38478] New: incorrect results for polynomial evaluation with optimisation/inline functions
The attached program produces incorrect results in gcc-4.3.2 with -O2. (The
results are correct at -O0 when inline functions are not used).
The code evaluates a complex polynomial in Horner form via an inline function.
It is part of the test suite of gsl-1.11 (GNU Scientific Library). I have
examined the code and believe it is numerically correct. For comparison, the
problem does not occur in gcc-4.3.0.
$ /opt/gcc-4.3.2/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/bjg/ftp/gcc-4.3.2/configure --prefix=/opt/gcc-4.3.2
Thread model: posix
gcc version 4.3.2 (GCC)
$ /opt/gcc-4.3.2/bin/gcc -O0 -Wall testcase.c
$ ./a.out
Completed [10/10]
$ /opt/gcc-4.3.2/bin/gcc -O2 -Wall testcase.c
$ ./a.out
FAIL: y.real, gsl_complex_poly_complex_eval ({-2.31 + 0.44i, 4.21 - 3.19i, 0.93
+ 1.04i, -0.42 + 0.68i}, 0.49 + 0.95i) (-2.31005 observed vs
1.824620127 expected) [9]
FAIL: y.imag, gsl_complex_poly_complex_eval ({-2.31 + 0.44i, 4.21 - 3.19i, 0.93
+ 1.04i, -0.42 + 0.68i}, 0.49 + 0.95i) (0.440002 observed vs
2.3038941199982 expected) [10]
--
Summary: incorrect results for polynomial evaluation with
optimisation/inline functions
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjg at gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38478
[Bug c++/38477] New: [strict-aliasing] warning message contains compiler-generated symbols
[EMAIL PROTECTED] gcc_err]# g++ -Wall -c -O3 test.cpp
test.cpp: In member function 'void
test::bar(std::_List_iterator >&)':
test.cpp:14: warning: dereferencing pointer '__x.13' does break
strict-aliasing rules
/usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530:
note: initialized from here
test.cpp:14: warning: dereferencing pointer '__x.13' does break
strict-aliasing rules
/usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530:
note: initialized from here
[EMAIL PROTECTED] gcc_err]# g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++ :
(reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion : (reconfigured) ../gcc_current/configure
--prefix=/usr/local/gcc_current --enable-shared --enable-threads=posix
--enable-checking=release --enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20081210 (experimental) [trunk revision 142645] (GCC)
[EMAIL PROTECTED] gcc_err]# uname -a
Linux localhost.localdomain 2.6.26.6-49.fc8 #1 SMP Fri Oct 17 15:59:36
EDT 2008 i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] gcc_err]# cat test.cpp
#include
#include
template
class KeyPairPtr
{
public:
typedef typename std::pair< const Key, Info > Pair;
Pair *pair_ptr;
};
template
bool operator <( const KeyPairPtr &left, const
KeyPairPtr &right ) {
return left.pair_ptr < right.pair_ptr;
}
typedef KeyPairPtr key_val;
class test
{
test();
void bar( std::list::iterator &ci );
std::set foo;
};
void test::bar( std::list::iterator &ci )
{
test ctx;
ctx.foo.insert( *ci );
}
--
Summary: [strict-aliasing] warning message contains compiler-
generated symbols
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dimhen at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
