Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
Attached a fix for this PR. I will regstrap and submit for review.
Sebastian
2009-01-14 Sebastian Pop sebastian@amd.com
PR middle-end/38431
* graphite.c (get_vdef_before_scop, scop_adjust_vphi): New.
(scop_adjust_phis_for_liveouts): Call scop_adjust_vphi.
(gloog): Do not call cleanup_tree_cfg.
(graphite_transform_loops): Call cleanup_tree_cfg after all
scops have been code generated.
Index: graphite.c
===
--- graphite.c (revision 143346)
+++ graphite.c (working copy)
@@ -5188,6 +5188,82 @@ scop_insert_phis_for_liveouts (sese regi
update_ssa (TODO_update_ssa);
}
+/* Get the definition of NAME before the SCOP. Keep track of the
+ basic blocks that have been VISITED in a bitmap. */
+
+static tree
+get_vdef_before_scop (scop_p scop, tree name, sbitmap visited)
+{
+ unsigned i;
+ gimple def_stmt = SSA_NAME_DEF_STMT (name);
+ basic_block def_bb = gimple_bb (def_stmt);
+
+ if (!bb_in_scop_p (def_bb, scop))
+return name;
+
+ if (TEST_BIT (visited, def_bb-index))
+return NULL_TREE;
+
+ SET_BIT (visited, def_bb-index);
+
+ switch (gimple_code (def_stmt))
+{
+case GIMPLE_PHI:
+ for (i = 0; i gimple_phi_num_args (def_stmt); i++)
+ {
+ tree arg = gimple_phi_arg_def (def_stmt, i);
+ tree res = get_vdef_before_scop (scop, arg, visited);
+ if (res)
+ return res;
+ }
+ return NULL_TREE;
+
+default:
+ return NULL_TREE;
+}
+}
+
+/* Adjust a virtual phi node PHI that is placed at the end of the
+ generated code for SCOP:
+
+ | if (1)
+ | generated code from REGION;
+ | else
+ | REGION;
+
+ The FALSE_E edge comes from the original code, TRUE_E edge comes
+ from the code generated for the SCOP. */
+
+static void
+scop_adjust_vphi (scop_p scop, gimple phi, edge true_e)
+{
+ unsigned i;
+
+ gcc_assert (gimple_phi_num_args (phi) == 2);
+
+ for (i = 0; i gimple_phi_num_args (phi); i++)
+if (gimple_phi_arg_edge (phi, i) == true_e)
+ {
+ tree true_arg, false_arg, before_scop_arg;
+ sbitmap visited;
+
+ true_arg = gimple_phi_arg_def (phi, i);
+ if (!SSA_NAME_IS_DEFAULT_DEF (true_arg))
+ return;
+
+ false_arg = gimple_phi_arg_def (phi, i == 0 ? 1 : 0);
+ if (SSA_NAME_IS_DEFAULT_DEF (false_arg))
+ return;
+
+ visited = sbitmap_alloc (last_basic_block);
+ sbitmap_zero (visited);
+ before_scop_arg = get_vdef_before_scop (scop, false_arg, visited);
+ gcc_assert (before_scop_arg != NULL_TREE);
+ SET_PHI_ARG_DEF (phi, i, before_scop_arg);
+ sbitmap_free (visited);
+ }
+}
+
/* Adjusts the phi nodes in the block BB for variables defined in
SCOP_REGION and used outside the SCOP_REGION. The code generation
moves SCOP_REGION in the else clause of an if (1) and generates
@@ -5214,7 +5290,10 @@ scop_adjust_phis_for_liveouts (scop_p sc
gimple phi = gsi_stmt (si);
if (!is_gimple_reg (PHI_RESULT (phi)))
- continue;
+ {
+ scop_adjust_vphi (scop, phi, true_e);
+ continue;
+ }
for (i = 0; i gimple_phi_num_args (phi); i++)
if (gimple_phi_arg_edge (phi, i) == false_e)
@@ -5396,9 +5475,6 @@ gloog (scop_p scop, struct clast_stmt *s
recompute_all_dominators ();
graphite_verify ();
- cleanup_tree_cfg ();
- recompute_all_dominators ();
- graphite_verify ();
}
/* Returns the number of data references in SCOP. */
@@ -6095,6 +6171,7 @@ graphite_transform_loops (void)
}
/* Cleanup. */
+ cleanup_tree_cfg ();
free_scops (current_scops);
cloog_finalize ();
free_original_copy_tables ();
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #33 from sebpop at gmail dot com 2009-01-14 10:20 --- Subject: Re: [graphite] several ICEs with CP2K (summary) Attached a fix for this PR. I will regstrap and submit for review. Sebastian --- Comment #34 from sebpop at gmail dot com 2009-01-14 10:20 --- Created an attachment (id=17097) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17097action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #35 from jv244 at cam dot ac dot uk 2009-01-14 10:51 --- (In reply to comment #33) Attached a fix for this PR. I will regstrap and submit for review. while I'll apply it to current trunk, retest CP2K, and update this PR with the results. Thanks, Joost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #36 from jv244 at cam dot ac dot uk 2009-01-14 12:08 --- (In reply to comment #35) (In reply to comment #33) Attached a fix for this PR. I will regstrap and submit for review. while I'll apply it to current trunk, retest CP2K, and update this PR with the results. Looks like all CP2K tests pass with this patch installed! Many thanks, Joost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #37 from spop at gcc dot gnu dot org 2009-01-14 14:35 --- Subject: Bug 38431 Author: spop Date: Wed Jan 14 14:35:27 2009 New Revision: 143372 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143372 Log: 2009-01-14 Sebastian Pop sebastian@amd.com PR middle-end/38431 * graphite.c (get_vdef_before_scop, scop_adjust_vphi): New. (scop_adjust_phis_for_liveouts): Call scop_adjust_vphi. (gloog): Do not call cleanup_tree_cfg. (graphite_transform_loops): Call cleanup_tree_cfg after all scops have been code generated. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #38 from spop at gcc dot gnu dot org 2009-01-14 14:36 --- 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=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #39 from spop at gcc dot gnu dot org 2009-01-14 21:11 --- Subject: Bug 38431 Author: spop Date: Wed Jan 14 21:11:05 2009 New Revision: 143384 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143384 Log: 2009-01-14 Sebastian Pop sebastian@amd.com PR middle-end/38431 * graphite.c (get_vdef_before_scop, scop_adjust_vphi): New. (scop_adjust_phis_for_liveouts): Call scop_adjust_vphi. (gloog): Do not call cleanup_tree_cfg. (graphite_transform_loops): Call cleanup_tree_cfg after all scops have been code generated. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
Hi, I compiled BLAS and LAPACK with the gfortran compiler of the graphite branch such that I could test the CP2K benchmark. On my laptop, that is an amd64-linux, make test passes with the gfortran compiler from the graphite branch. However I'm not able to run the test that you reported failing: ./cp2k.sopt canonical.inp CP2K: The specified file canonical.inp can not be opened, it does not exist. STOP 1 Could you tell me where I can find the canonical.inp file, or how to reproduce the fail? Thanks, Sebastian
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #28 from sebpop at gmail dot com 2009-01-13 19:52 --- Subject: Re: [graphite] several ICEs with CP2K (summary) Hi, I compiled BLAS and LAPACK with the gfortran compiler of the graphite branch such that I could test the CP2K benchmark. On my laptop, that is an amd64-linux, make test passes with the gfortran compiler from the graphite branch. However I'm not able to run the test that you reported failing: ./cp2k.sopt canonical.inp CP2K: The specified file canonical.inp can not be opened, it does not exist. STOP 1 Could you tell me where I can find the canonical.inp file, or how to reproduce the fail? Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #29 from jv244 at cam dot ac dot uk 2009-01-13 20:33 --- (In reply to comment #28) the graphite branch. However I'm not able to run the test that you reported failing: ./cp2k.sopt canonical.inp CP2K: The specified file canonical.inp can not be opened, it does not exist. STOP 1 Could you tell me where I can find the canonical.inp file, or how to reproduce the fail? you'll have to untar the additional_test.tgz which is attached here to the PR: http://gcc.gnu.org/bugzilla/attachment.cgi?id=17062 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
Thanks for the clarification, I managed to reproduce the fail. The problem comes from the fact that we do not generate code for a scalar reduction that is not detected as a scalar reduction with the variable connection$dim$1$lbound. In the attached output from debug_loops (3) I selected the region of code containing both the original loops: loop_3 and loop_4 and the code generated by graphite with -fgraphite-identity: loop_22, loop_23. In loop_22 the computation on connection$dim$1$lbound disappears. I wonder what this variable stands for: it is not used elsewhere in the debug_loops (3) output of change_bond_length function, and I suspect that this is a global variable whose value is needed elsewhere outside the change_bond_length function. The bug is in the detection of scalar reductions. Sebastian 2 Description: Binary data
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #30 from sebpop at gmail dot com 2009-01-13 21:57 --- Subject: Re: [graphite] several ICEs with CP2K (summary) Thanks for the clarification, I managed to reproduce the fail. The problem comes from the fact that we do not generate code for a scalar reduction that is not detected as a scalar reduction with the variable connection$dim$1$lbound. In the attached output from debug_loops (3) I selected the region of code containing both the original loops: loop_3 and loop_4 and the code generated by graphite with -fgraphite-identity: loop_22, loop_23. In loop_22 the computation on connection$dim$1$lbound disappears. I wonder what this variable stands for: it is not used elsewhere in the debug_loops (3) output of change_bond_length function, and I suspect that this is a global variable whose value is needed elsewhere outside the change_bond_length function. The bug is in the detection of scalar reductions. Sebastian --- Comment #31 from sebpop at gmail dot com 2009-01-13 21:57 --- Created an attachment (id=17095) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17095action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #32 from jv244 at cam dot ac dot uk 2009-01-14 06:49 --- (In reply to comment #30) Subject: Re: [graphite] several ICEs with CP2K (summary) Thanks for the clarification, I managed to reproduce the fail. The problem comes from the fact that we do not generate code for a scalar reduction that is not detected as a scalar reduction with the variable connection$dim$1$lbound. In the attached output from debug_loops (3) I selected the region of code containing both the original loops: loop_3 and loop_4 and the code generated by graphite with -fgraphite-identity: loop_22, loop_23. In loop_22 the computation on connection$dim$1$lbound disappears. I wonder what this variable stands for: it is not used elsewhere in the debug_loops (3) output of change_bond_length function, and I suspect that this is a global variable whose value is needed elsewhere outside the change_bond_length function. This variable is a local, I believe, it is part of the array descriptor of the (local variable): INTEGER, ALLOCATABLE, DIMENSION(:, :):: connection The bug is in the detection of scalar reductions. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #25 from jv244 at cam dot ac dot uk 2009-01-11 12:30 --- (In reply to comment #22) Program received signal SIGSEGV, Segmentation fault. __mc_moves_MOD_change_bond_length () at /scratch/vondele/clean/cp2k/src/../src/mc_moves.F:1434 1434 atom_b(:)=0 I had a further look into this. It is sufficient to compile the file mc_moves.F without graphite to avoid the segfault, while compiling it with '-fgraphite -fgraphite-identity' is enough to get the segfault. I would therefore guess this is unrelated to blocking and local to the file mc_moves.F. I'll see if I can narrow down the problem to the single subroutine (change_bond_length) which I suspect is the issue. [all of this with trunk 143207] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #26 from jv244 at cam dot ac dot uk 2009-01-11 12:58 --- (In reply to comment #25) I'll see if I can narrow down the problem to the single subroutine (change_bond_length) which I suspect is the issue. [all of this with trunk 143207] yes, just looking at change_bond_length should be enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #27 from sebpop at gmail dot com 2009-01-11 13:42 --- Subject: Re: [graphite] several ICEs with CP2K (summary) On Sun, Jan 11, 2009 at 6:58 AM, jv244 at cam dot ac dot uk gcc-bugzi...@gcc.gnu.org wrote: I'll see if I can narrow down the problem to the single subroutine (change_bond_length) which I suspect is the issue. [all of this with trunk 143207] yes, just looking at change_bond_length should be enough. I'm looking at the code generated for this function. Thanks for the detailed analysis. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #19 from spop at gcc dot gnu dot org 2009-01-08 17:10 --- Hi, With the latest trunk CP2K compiles with -O2 -floop-block. I tried to run CP2K with -floop-block but I got an error due to the libblas installation on my system (missing symbols in libblas that uses the libgfortran of gcc 4.2 of my system). I would have to install libblas manually with current gcc trunk. Could you try to run again the make test and report the status of CP2K? Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #20 from jv244 at cam dot ac dot uk 2009-01-08 19:30 --- (In reply to comment #19) Could you try to run again the make test and report the status of CP2K? Hi Sebastian, the testcase provide runs fine (AFAICT) with current trunk. I'll run the full CP2K testsuite to test somewhat better. Thanks, Joost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #21 from sebpop at gmail dot com 2009-01-08 19:53 --- Subject: Re: [graphite] several ICEs with CP2K (summary) the testcase provide runs fine (AFAICT) with current trunk. I'll run the full CP2K testsuite to test somewhat better. Thanks for testing. Can you close the bug after the CP2K testsuite passes? Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #22 from jv244 at cam dot ac dot uk 2009-01-09 05:38 --- (In reply to comment #21) Thanks for testing. Can you close the bug after the CP2K testsuite passes? unfortunately, there is still one runtime segfault, I have no reduced testcase so far, but this is the backtrace: Program received signal SIGSEGV, Segmentation fault. __mc_moves_MOD_change_bond_length () at /scratch/vondele/clean/cp2k/src/../src/mc_moves.F:1434 1434 atom_b(:)=0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #23 from jv244 at cam dot ac dot uk 2009-01-09 06:16 --- Created an attachment (id=17062) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17062action=view) additional cp2k input With this CP2K testcase the segfault can be reproduced. After building cp2k, just run: cp2k.sopt canonical.inp the segfault is almost immediate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #24 from jv244 at cam dot ac dot uk 2009-01-09 06:18 --- (In reply to comment #22) Program received signal SIGSEGV, Segmentation fault. __mc_moves_MOD_change_bond_length () at /scratch/vondele/clean/cp2k/src/../src/mc_moves.F:1434 1434 atom_b(:)=0 additional valgrind info: ==4525== Use of uninitialised value of size 8 ==4525==at 0xB93AFB: __mc_moves_MOD_change_bond_length (mc_moves.F:1434) ==4525==by 0xB9C478: __mc_moves_MOD_mc_conformation_change (mc_moves.F:273) ==4525==by 0xB68830: __mc_ensembles_MOD_mc_run_ensemble (mc_ensembles.F:754) ==4525==by 0xBA4623: __mc_run_MOD_do_mon_car (mc_run.F:328) ==4525==by 0x562C3F: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:335) ==4525==by 0x565B36: __cp2k_runs_MOD_run_input (cp2k_runs.F:1079) ==4525==by 0x1456510: MAIN__ (cp2k.F:272) ==4525==by 0x14575E9: main (fmain.c:21) ==4525== ==4525== Invalid write of size 4 ==4525==at 0xB93AFB: __mc_moves_MOD_change_bond_length (mc_moves.F:1434) ==4525==by 0xB9C478: __mc_moves_MOD_mc_conformation_change (mc_moves.F:273) ==4525==by 0xB68830: __mc_ensembles_MOD_mc_run_ensemble (mc_ensembles.F:754) ==4525==by 0xBA4623: __mc_run_MOD_do_mon_car (mc_run.F:328) ==4525==by 0x562C3F: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:335) ==4525==by 0x565B36: __cp2k_runs_MOD_run_input (cp2k_runs.F:1079) ==4525==by 0x1456510: MAIN__ (cp2k.F:272) ==4525==by 0x14575E9: main (fmain.c:21) ==4525== Address 0x4 is not stack'd, malloc'd or (recently) free'd ==4525== ==4525== Process terminating with default action of signal 11 (SIGSEGV) ==4525== Access not within mapped region at address 0x4 ==4525==at 0xB93AFB: __mc_moves_MOD_change_bond_length (mc_moves.F:1434) ==4525==by 0xB9C478: __mc_moves_MOD_mc_conformation_change (mc_moves.F:273) ==4525==by 0xB68830: __mc_ensembles_MOD_mc_run_ensemble (mc_ensembles.F:754) ==4525==by 0xBA4623: __mc_run_MOD_do_mon_car (mc_run.F:328) ==4525==by 0x562C3F: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:335) ==4525==by 0x565B36: __cp2k_runs_MOD_run_input (cp2k_runs.F:1079) ==4525==by 0x1456510: MAIN__ (cp2k.F:272) ==4525==by 0x14575E9: main (fmain.c:21) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #16 from jv244 at cam dot ac dot uk 2009-01-07 19:07 --- I checked that current trunk (i.e. not graphite branch) still generates a segfaulting executable with FCFLAGS = -g -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form -fgraphite -fgraphite-identity -floop-block -floop-strip-mine -floop-interchange with a bt Program received signal SIGSEGV, Segmentation fault. __fist_neighbor_lists_MOD_give_ijk_subcell () at fist_neighbor_lists.F:634 634 r_pbc = r Current language: auto; currently fortran (gdb) bt #0 __fist_neighbor_lists_MOD_give_ijk_subcell () at fist_neighbor_lists.F:634 #1 0x007568b8 in __fist_neighbor_lists_MOD_build_neighbor_lists () at fist_neighbor_lists.F:418 #2 0x0075c37c in __fist_neighbor_lists_MOD_build_fist_neighbor_lists () at fist_neighbor_lists.F:189 #3 0x0124e132 in __topology_generate_util_MOD_topology_generate_bond () at topology_generate_util.F:660 #4 0x0120031c in __topology_MOD_connectivity_control () at topology.F:421 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #17 from sebpop at gmail dot com 2009-01-07 19:23 --- Subject: Re: [graphite] several ICEs with CP2K (summary) I checked that current trunk (i.e. not graphite branch) still generates a segfaulting executable with FCFLAGS = -g -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form -fgraphite -fgraphite-identity -floop-block -floop-strip-mine -floop-interchange Thanks for the update. I suspect that this is due to -floop-block. There are two more bugs 38559 and 38499 that we're looking at for fixing -floop-block. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #18 from jv244 at cam dot ac dot uk 2009-01-07 20:52 --- (In reply to comment #17) Thanks for the update. I suspect that this is due to -floop-block. There are two more bugs 38559 and 38499 that we're looking at for fixing -floop-block. yes, I was able to derive a small testcase for this problem (PR38760), and it requires floop-block to trigger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #13 from jv244 at cam dot ac dot uk 2008-12-15 17:31 --- (In reply to comment #12) Could you try with the addition of -fno-strict-aliasing -fno-strict-overflow? See pr38520. The testcase in PR38492 indeed works if I use: gfortran -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -fgraphite -fgraphite-identity -cpp -D__FFTSG -fno-strict-overflow test.f90 (i.e. no need for -fno-strict-aliasing) I'll give it a try on the full code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #14 from jv244 at cam dot ac dot uk 2008-12-15 19:06 --- (In reply to comment #13) (i.e. no need for -fno-strict-aliasing) I'll give it a try on the full code. OK, full code compiles runs the test example with -fgraphite -fgraphite-identity -fno-strict-overflow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #15 from jv244 at cam dot ac dot uk 2008-12-15 19:44 --- (In reply to comment #14) OK, full code compiles runs the test example with -fgraphite -fgraphite-identity -fno-strict-overflow compiling with -g -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form -fgraphite -fgraphite-identity -fno-strict-overflow -floop-block -floop-strip-mine -floop-interchang it segfaults again :-) 0x00672bd1 in __distribution_optimize_MOD_compute_cost_cpu () at distribution_optimize.F:286 286 cost_cpu(local_rows(i),local_cols(j))=cost_cpu(local_rows(i),local_cols(j))+cost_ele_pair(i,j) Current language: auto; currently fortran (gdb) bt #0 0x00672bd1 in __distribution_optimize_MOD_compute_cost_cpu () at distribution_optimize.F:286 #1 0x006753da in __distribution_optimize_MOD_distribute_2d_monte_carlo () at distribution_optimize.F:247 #2 0x006706b7 in __distribution_methods_MOD_distribute_molecules_2d () at distribution_methods.F:582 #3 0x00e5822c in __qs_environment_methods_MOD_qs_env_setup () at qs_environment_methods.F:191 #4 0x00e501ba in __qs_environment_MOD_qs_init_subsys () at qs_environment.F:992 #5 0x00e55515 in __qs_environment_MOD_qs_init () at qs_environment.F:322 #6 0x00f7e66a in __qs_main_MOD_quickstep_create_force_env () at qs_main.F:87 #7 0x00715bfd in __f77_interface_MOD_create_force_env () at f77_interface.F:734 #8 0x00561abe in __cp2k_runs_MOD_cp2k_run () at cp2k_runs.F:281 #9 0x005652f7 in __cp2k_runs_MOD_run_input () at cp2k_runs.F:1079 #10 0x01463571 in cp2k () at cp2k.F:272 #11 0x0146467a in main (argc=2, argv=0x79cc5928) at /scratch/vondele/gcc/graphite/libgfortran/fmain.c:21 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #12 from dominiq at lps dot ens dot fr 2008-12-14 15:54 --- Could you try with the addition of -fno-strict-aliasing -fno-strict-overflow? See pr38520. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-13 08:39 --- (In reply to comment #10) (In reply to comment #9) Unfortunately, '-fgraphite -fgraphite-identity -floop-block -floop-strip-mine -floop-interchang' goes generate an executable, but it is miscompiled and segfaults. reduced testcase in PR38492 After Sebastian Pop's fix for PR38492 the test run goes a bit further but segfaults again, now with a different trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b0112f77440 (LWP 18589)] 0x00df557b in __fist_neighbor_lists_MOD_give_ijk_subcell () (gdb) bt #0 0x00df557b in __fist_neighbor_lists_MOD_give_ijk_subcell () #1 0x00df7742 in __fist_neighbor_lists_MOD_build_neighbor_lists () #2 0x00dfd0de in __fist_neighbor_lists_MOD_build_fist_neighbor_lists () #3 0x0126f50a in __topology_generate_util_MOD_topology_generate_bond () #4 0x01223746 in __topology_MOD_connectivity_control () #5 0x012247db in __topology_MOD_topology_control () #6 0x0113cf43 in __qs_environment_MOD_qs_init () #7 0x007facaa in __qs_main_MOD_quickstep_create_force_env () #8 0x00434416 in __f77_interface_MOD_create_force_env () #9 0x0040a40e in __cp2k_runs_MOD_cp2k_run () #10 0x0040dc47 in __cp2k_runs_MOD_run_input () #11 0x00403c01 in MAIN__ () #12 0x014483ba in main (argc=2, argv=0x7fff99be3828) at /scratch/vondele/gcc/graphite/libgfortran/fmain.c:21 There is an earlier error by valgrind: ==18647== Conditional jump or move depends on uninitialised value(s) ==18647==at 0xDF69A3: __fist_neighbor_lists_MOD_build_neighbor_lists (in /scratch/vondele/clean/cp2k/exe/Linux-x86-6 4-gfortran/cp2k.sopt) ==18647==by 0xDFD0DD: __fist_neighbor_lists_MOD_build_fist_neighbor_lists (in /scratch/vondele/clean/cp2k/exe/Linux- x86-64-gfortran/cp2k.sopt) ==18647==by 0x126F509: __topology_generate_util_MOD_topology_generate_bond (in /scratch/vondele/clean/cp2k/exe/Linux -x86-64-gfortran/cp2k.sopt) ==18647==by 0x1223745: __topology_MOD_connectivity_control (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran /cp2k.sopt) ==18647==by 0x12247DA: __topology_MOD_topology_control (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2 k.sopt) ==18647==by 0x113CF42: __qs_environment_MOD_qs_init (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.s opt) ==18647==by 0x7FACA9: __qs_main_MOD_quickstep_create_force_env (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfor tran/cp2k.sopt) ==18647==by 0x434415: __f77_interface_MOD_create_force_env (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran /cp2k.sopt) ==18647==by 0x40A40D: __cp2k_runs_MOD_cp2k_run (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==18647==by 0x40DC46: __cp2k_runs_MOD_run_input (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==18647==by 0x403C00: MAIN__ (in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt) ==18647==by 0x14483B9: main (fmain.c:21) (obviously absent if compiled without graphite). build_neighbor_lists (fist_neighbor_lists.F) is pretty loopy code, so well.. even though the routine is not so long, it wont be easy to reduce it, as it depends on quite a few types defined elsewhere (it would be nice if the fortran frontend could generate 'preprocessed' source without module dependencies, they're similar to C header files.). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #9 from jv244 at cam dot ac dot uk 2008-12-11 20:17 --- Unfortunately, '-fgraphite -fgraphite-identity -floop-block -floop-strip-mine -floop-interchang' goes generate an executable, but it is miscompiled and segfaults. It can be reproduced with the testcase in the initial comment, adjusting the FCFLAGS in the makefile and make clean make make test -- jv244 at cam dot ac dot uk changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #10 from jv244 at cam dot ac dot uk 2008-12-11 21:41 --- (In reply to comment #9) Unfortunately, '-fgraphite -fgraphite-identity -floop-block -floop-strip-mine -floop-interchang' goes generate an executable, but it is miscompiled and segfaults. reduced testcase in PR38492 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
