[Bug middle-end/38431] New: [graphite] several ICEs with CP2K

[Bug middle-end/38431] New: [graphite] several ICEs with CP2K

[jv244 at cam dot ac dot uk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

the current graphite branch segfaults & ICEs on several files from CP2K.
Compiling with '-O2 -ffast-math -funroll-loops -ftree-vectorize -march=native
-fgraphite -fgraphite-identity'

To reproduce get 

http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2008_12_03.tgz

untar and type make

at least on the following files:

mltfftsg.F
mltfftsg_tools.F
harris_force_types.F
ai_moments.F
cp_units.F
ps_wavelet_util.F
cp_fm_basic_linalg.F
ps_wavelet_kernel.F
ai_angmom.F
distribution_optimize.F
qs_util.F
atom_fit.F
atom_operators.F
dynamical_coeff_types.F
pw_spline_utils.F
pw_poisson_types.F
xc_derivative_set_types.F
cp_ddapc_methods.F
qs_all_potential.F
qs_operators_ao.F

I have ICEs.

The first one is:
ai_moments.F: In function ‘cossin’:
ai_moments.F:44: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [ai_moments.o] Error

The same files compile fine with '-O0 -fgraphite -fgraphite-identity' so I
guess it is related to applying graphite to optimized code (or the other way
around).


-- 
           Summary: [graphite] several ICEs with CP2K
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jv244 at cam dot ac dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38431] [graphite] several ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #1 from jv244 at cam dot ac dot uk  2008-12-09 08:42 -------
Tobias, 

you might be interested to check if your recent patch also fixed these bugs.
Otherwise I should be able to give it a round of testing before the weekend.


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |grosser at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38431] [graphite] several ICEs with CP2K

[jv244 at cam dot ac dot uk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]



------- Comment #2 from jv244 at cam dot ac dot uk  2008-12-09 19:41 -------
This is a simple testcase for one of the first segfaults, observed with current
graphite branch:

gfortran -c -O2 -ffree-form -fgraphite -fgraphite-identity test.f90
test.f90: In function ‘matmov’:
test.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

> cat test.f90
  SUBROUTINE matmov ( n, m, a, lda, b, ldb )
    INTEGER, PARAMETER :: dbl=KIND(0.0D0)
    INTEGER                                  :: n, m, lda
    COMPLEX(dbl)                             :: a( lda, * )
    INTEGER                                  :: ldb
    COMPLEX(dbl)                             :: b( ldb, * )

    b ( 1:n , 1:m ) = a ( 1:n, 1:m )
  END SUBROUTINE matmov


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

[grosser at gcc dot gnu dot org]

------- Comment #3 from grosser at gcc dot gnu dot org  2008-12-09 20:10 -------
Thanks for these test cases.

My commit fixed at least one failure, but there are more.

To help us it would be great to get a little bit structure in the failures.
Just get for every failing test a backtrace and create for every different bug
a new bugreport.

A little bit like Bub37894 for polyhedron.

It would be awesome, if you also could add one reduced test case and one
backtrace to every bugreport.


-- 

grosser at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-12-09 20:10:27
               date|                            |
            Summary|[graphite] several ICEs with|[graphite] several ICEs with
                   |CP2K                        |CP2K (summery)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

[grosser at gcc dot gnu dot org]

------- Comment #4 from grosser at gcc dot gnu dot org  2008-12-09 20:24 -------
mltfftsg.F fails on Bug38459


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

[jv244 at cam dot ac dot uk]

------- Comment #5 from jv244 at cam dot ac dot uk  2008-12-09 21:02 -------
lebedev.F on PR38461


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

[jv244 at cam dot ac dot uk]

------- Comment #6 from jv244 at cam dot ac dot uk  2008-12-09 21:11 -------
ps_wavelet_util.F is now PR38463 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summery)

[jv244 at cam dot ac dot uk]

------- 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 middle-end/38431] [graphite] several ICEs with CP2K (summery)

[jv244 at cam dot ac dot uk]

------- Comment #8 from jv244 at cam dot ac dot uk  2008-12-11 19:19 -------
(In reply to comment #7)
> 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
> 

all fixed with current graphite branch. The full CP2K sources now compile with
-fgraphite -fgraphite-identity

I'm adding -floop-block -floop-strip-mine -floop-interchange to the list of
options and will close this PR as fixed if this goes fine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[jv244 at cam dot ac dot uk]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[jv244 at cam dot ac dot uk]

------- 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)]
0x0000000000df557b in __fist_neighbor_lists_MOD_give_ijk_subcell ()
(gdb) bt
#0  0x0000000000df557b in __fist_neighbor_lists_MOD_give_ijk_subcell ()
#1  0x0000000000df7742 in __fist_neighbor_lists_MOD_build_neighbor_lists ()
#2  0x0000000000dfd0de in __fist_neighbor_lists_MOD_build_fist_neighbor_lists
()
#3  0x000000000126f50a in __topology_generate_util_MOD_topology_generate_bond
()
#4  0x0000000001223746 in __topology_MOD_connectivity_control ()
#5  0x00000000012247db in __topology_MOD_topology_control ()
#6  0x000000000113cf43 in __qs_environment_MOD_qs_init ()
#7  0x00000000007facaa in __qs_main_MOD_quickstep_create_force_env ()
#8  0x0000000000434416 in __f77_interface_MOD_create_force_env ()
#9  0x000000000040a40e in __cp2k_runs_MOD_cp2k_run ()
#10 0x000000000040dc47 in __cp2k_runs_MOD_run_input ()
#11 0x0000000000403c01 in MAIN__ ()
#12 0x00000000014483ba 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)

[dominiq at lps dot ens dot fr]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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 :-)

0x0000000000672bd1 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  0x0000000000672bd1 in __distribution_optimize_MOD_compute_cost_cpu () at
distribution_optimize.F:286
#1  0x00000000006753da in __distribution_optimize_MOD_distribute_2d_monte_carlo
() at distribution_optimize.F:247
#2  0x00000000006706b7 in __distribution_methods_MOD_distribute_molecules_2d ()
at distribution_methods.F:582
#3  0x0000000000e5822c in __qs_environment_methods_MOD_qs_env_setup () at
qs_environment_methods.F:191
#4  0x0000000000e501ba in __qs_environment_MOD_qs_init_subsys () at
qs_environment.F:992
#5  0x0000000000e55515 in __qs_environment_MOD_qs_init () at
qs_environment.F:322
#6  0x0000000000f7e66a in __qs_main_MOD_quickstep_create_force_env () at
qs_main.F:87
#7  0x0000000000715bfd in __f77_interface_MOD_create_force_env () at
f77_interface.F:734
#8  0x0000000000561abe in __cp2k_runs_MOD_cp2k_run () at cp2k_runs.F:281
#9  0x00000000005652f7 in __cp2k_runs_MOD_run_input () at cp2k_runs.F:1079
#10 0x0000000001463571 in cp2k () at cp2k.F:272
#11 0x000000000146467a in main (argc=2, argv=0x7ffff9cc5928) 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)

[jv244 at cam dot ac dot uk]

------- 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  0x00000000007568b8 in __fist_neighbor_lists_MOD_build_neighbor_lists ()
    at fist_neighbor_lists.F:418
#2  0x000000000075c37c in __fist_neighbor_lists_MOD_build_fist_neighbor_lists
()
    at fist_neighbor_lists.F:189
#3  0x000000000124e132 in __topology_generate_util_MOD_topology_generate_bond
()
    at topology_generate_util.F:660
#4  0x000000000120031c 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)

[sebpop at gmail dot com]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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)

[spop at gcc dot gnu dot org]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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)

[sebpop at gmail dot com]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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=17062&action=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)

[jv244 at cam dot ac dot uk]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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)

[sebpop at gmail dot com]

------- 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-bugzilla@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

Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[Sebastian Pop]

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)

[sebpop at gmail dot com]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[sebpop at gmail dot com]

------- 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=17095&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[Sebastian Pop]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

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

[-- Attachment #2: 2 --]
[-- Type: application/octet-stream, Size: 6792 bytes --]

  bb_181 (preds = {bb_183 }, succs = {bb_53 })
  {
  <bb 181>:
Invalid sum of outgoing probabilities 50.0%
    goto <bb 53>;

  }
  bb_53 (preds = {bb_181 }, succs = {bb_63 bb_54 })
  {
  <bb 53>:
    # VUSE <MPT.1986_1463> { MPT.1986 }
    D.8925_286 = connectivity.data;
    D.8734_287 = (integer(kind=4)[0:] *) D.8925_286;
    # VUSE <MPT.1986_1463> { MPT.1986 }
    D.8735_288 = connectivity.offset;
    # VUSE <MPT.1986_1463> { MPT.1986 }
    S.280_289 = connectivity.dim[0].lbound;
    # VUSE <MPT.1986_1463> { MPT.1986 }
    D.8737_290 = connectivity.dim[0].ubound;
    # VUSE <MPT.1986_1463> { MPT.1986 }
    S.279_291 = connectivity.dim[1].lbound;
    # VUSE <MPT.1986_1463> { MPT.1986 }
    D.8739_292 = connectivity.dim[1].ubound;
    # VUSE <MPT.1986_1463> { MPT.1986 }
    D.8741_293 = connectivity.dim[0].stride;
    if (S.279_291 > D.8739_292)
      goto <bb 63>;
    else
      goto <bb 54>;

  }
  bb_182 (preds = {bb_157 }, succs = {bb_186 bb_46 })
  {
  <bb 182>:
Invalid sum of outgoing probabilities 200.0%
    if (1 != 0)
      goto <bb 186>;
    else
      goto <bb 46>;

  }
  bb_185 (preds = {bb_51 }, succs = {bb_183 })
  {
  <bb 185>:
    goto <bb 183>;

  }
  bb_186 (preds = {bb_182 }, succs = {bb_190 bb_189 })
  {
  <bb 186>:
    D.13554_1465 = natom.309_142 > 0;
    if (D.13554_1465 != 0)
      goto <bb 190>;
    else
      goto <bb 189>;

  }
  bb_189 (preds = {bb_186 }, succs = {bb_187 })
  {
  <bb 189>:
    goto <bb 187>;

  }
  bb_196 (preds = {bb_190 }, succs = {bb_188 })
  {
  <bb 196>:

  }
  bb_188 (preds = {bb_196 }, succs = {bb_187 })
  {
  <bb 188>:

  }
  bb_187 (preds = {bb_188 bb_189 }, succs = {bb_184 })
  {
  <bb 187>:
    # HEAP.1954_1481 = PHI <HEAP.1954_1482(188), HEAP.1954_1209(189)>

  }
  bb_184 (preds = {bb_187 }, succs = {bb_183 })
  {
  <bb 184>:

  }
  bb_183 (preds = {bb_184 bb_185 }, succs = {bb_181 })
  {
  <bb 183>:
    # MPT.1986_1463 = PHI <MPT.1986_914(D)(184), MPT.1986_477(185)>
    # HEAP.1954_1464 = PHI <HEAP.1954_1481(184), HEAP.1954_1212(185)>

  }
  bb_181 (preds = {bb_183 }, succs = {bb_53 })
  {
  <bb 181>:
Invalid sum of outgoing probabilities 50.0%
    goto <bb 53>;

  }
  loop_3 (header = 46, latch = 52, niter = 1, upper_bound = 2, estimate = 2)
  {
    bb_46 (preds = {bb_52 bb_157 }, succs = {bb_51 bb_47 })
    {
    <bb 46>:
      # MPT.1986_348 = PHI <MPT.1986_477(52), MPT.1986_883(157)>
      # HEAP.1954_1210 = PHI <HEAP.1954_1212(52), HEAP.1954_1209(157)>
      # ivtmp.2096_1406 = PHI <ivtmp.2096_1407(52), 0(157)>
      D.13529_1408 = (integer(kind=8)) ivtmp.2096_1406;
      connection$dim$1$lbound_743 = D.13529_1408 + 1;
      D.9030_279 = connection$dim$1$lbound_743 * D.8665_146;
      D.8731_280 = D.9030_279 + D.8667_148;
      if (D.8892_143 <= 0)
        goto <bb 51>;
      else
        goto <bb 47>;

    }
    bb_47 (preds = {bb_46 }, succs = {bb_48 })
    {
    <bb 47>:
      D.13530_1409 = (<unnamed-unsigned:64>) natom.309_142;
      D.13531_1410 = D.13530_1409 + 0x0ffffffffffffffff;

    }
    bb_50 (preds = {bb_48 }, succs = {bb_51 })
    {
    <bb 50>:
      # MPT.1986_183 = PHI <MPT.1986_476(48)>
      # HEAP.1954_156 = PHI <HEAP.1954_1303(48)>

    }
    bb_51 (preds = {bb_50 bb_46 }, succs = {bb_53 bb_52 })
    {
    <bb 51>:
      # MPT.1986_477 = PHI <MPT.1986_183(50), MPT.1986_348(46)>
      # HEAP.1954_1212 = PHI <HEAP.1954_156(50), HEAP.1954_1210(46)>
      connection$dim$1$lbound_285 = connection$dim$1$lbound_743 + 1;
      if (ivtmp.2096_1406 < 1)
        goto <bb 52>;
      else
        goto <bb 53>;

    }
    bb_52 (preds = {bb_51 }, succs = {bb_46 })
    {
    <bb 52>:
      ivtmp.2096_1407 = ivtmp.2096_1406 + 1;
      goto <bb 46>;

    }
    loop_4 (header = 48, latch = 49, niter = (<unnamed-unsigned:64>) natom.309_142 + 0x0ffffffffffffffff, upper_bound = 9223372036854775806)
    {
      bb_48 (preds = {bb_49 bb_47 }, succs = {bb_50 bb_49 })
      {
      <bb 48>:
        # MPT.1986_476 = PHI <MPT.1986_476(49), MPT.1986_348(47)>
        # HEAP.1954_1211 = PHI <HEAP.1954_1303(49), HEAP.1954_1210(47)>
        # ivtmp.2097_1411 = PHI <ivtmp.2097_1412(49), 0(47)>
        D.13533_1413 = (integer(kind=8)) ivtmp.2097_1411;
        connection$dim$0$lbound_470 = D.13533_1413 + 1;
        D.9034_283 = connection$dim$0$lbound_470 + D.8731_280;
        # HEAP.1954_1303 = VDEF <HEAP.1954_1211> { HEAP.1954 }
        (*prephitmp.2043_606)[D.9034_283] = 0;
        connection$dim$0$lbound_284 = connection$dim$0$lbound_470 + 1;
        if (ivtmp.2097_1411 < D.13531_1410)
          goto <bb 49>;
        else
          goto <bb 50>;

      }
      bb_49 (preds = {bb_48 }, succs = {bb_48 })
      {
      <bb 49>:
        ivtmp.2097_1412 = ivtmp.2097_1411 + 1;
        goto <bb 48>;

      }
    }
  }
  loop_22 (header = 190, latch = 191, niter = )
  {
    bb_190 (preds = {bb_186 bb_191 }, succs = {bb_192 bb_196 })
    {
    <bb 190>:
      # graphiteIV.2105_1466 = PHI <0(186), graphiteIV.2105_1467(191)>
      # HEAP.1954_1482 = PHI <HEAP.1954_1209(186), HEAP.1954_1483(191)>
      if (graphiteIV.2105_1466 <= 1)
        goto <bb 192>;
      else
        goto <bb 196>;

    }
    bb_195 (preds = {bb_192 }, succs = {bb_191 })
    {
    <bb 195>:

    }
    bb_191 (preds = {bb_195 }, succs = {bb_190 })
    {
    <bb 191>:
      graphiteIV.2105_1467 = graphiteIV.2105_1466 + 1;
      goto <bb 190>;

    }
    loop_23 (header = 192, latch = 193, niter = )
    {
      bb_192 (preds = {bb_190 bb_193 }, succs = {bb_194 bb_195 })
      {
      <bb 192>:
        # graphiteIV.2106_1468 = PHI <0(190), graphiteIV.2106_1469(193)>
        # HEAP.1954_1483 = PHI <HEAP.1954_1482(190), HEAP.1954_1484(193)>
        D.13557_1470 = (<unnamed-unsigned:64>) natom.309_142;
        D.13558_1471 = D.13557_1470 + 0xffffffffffffffffffffffffffffffff;
        if (graphiteIV.2106_1468 <= D.13558_1471)
          goto <bb 194>;
        else
          goto <bb 195>;

      }
      bb_194 (preds = {bb_192 }, succs = {bb_193 })
      {
      <bb 194>:
        D.13559_1477 = (integer(kind=8)) graphiteIV.2105_1466;
        D.13560_1478 = D.13559_1477 + 1;
        D.13561_1479 = D.13560_1478 * D.8665_146;
        D.13562_1480 = D.13561_1479 + D.8667_148;
        ivtmp.2097_1472 = graphiteIV.2106_1468;
        D.13533_1473 = (integer(kind=8)) ivtmp.2097_1472;
        connection$dim$0$lbound_1474 = D.13533_1473 + 1;
        D.9034_1475 = connection$dim$0$lbound_1474 + D.13562_1480;
        # HEAP.1954_1484 = VDEF <HEAP.1954_1483> { HEAP.1954 }
        (*prephitmp.2043_606)[D.9034_1475] = 0;
        connection$dim$0$lbound_1476 = connection$dim$0$lbound_1474 + 1;

      }
      bb_193 (preds = {bb_194 }, succs = {bb_192 })
      {
      <bb 193>:
        graphiteIV.2106_1469 = graphiteIV.2106_1468 + 1;
        goto <bb 192>;

      }
    }
  }

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[jv244 at cam dot ac dot uk]

------- 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

Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[Sebastian Pop]

[-- Attachment #1: Type: text/plain, Size: 79 bytes --]

Attached a fix for this PR.  I will regstrap and submit for review.

Sebastian

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 1332_pr38431.diff --]
[-- Type: text/x-patch; name=1332_pr38431.diff, Size: 3482 bytes --]

2009-01-14  Sebastian Pop  <sebastian.pop@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)

[sebpop at gmail dot com]

------- 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=17097&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431

[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)

[jv244 at cam dot ac dot uk]

------- 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)

[jv244 at cam dot ac dot uk]

------- 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)

[spop at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=143372
Log:
2009-01-14  Sebastian Pop  <sebastian.pop@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)

[spop at gcc dot gnu dot org]

------- 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)

[spop at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=143384
Log:
2009-01-14  Sebastian Pop  <sebastian.pop@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