--- Comment #151 from jv244 at cam dot ac dot uk 2008-05-03 18:17 ---
New ICE PR36119, reopening.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #152 from kargl at gcc dot gnu dot org 2008-05-03 18:42 ---
(In reply to comment #151)
New ICE PR36119, reopening.
Why do you re-open this bug report for an regression? A few years
ago when cp2k revealed several bugs at one time, it made sense to have a
meta-bug. But,
--- Comment #153 from jvdelisle at gcc dot gnu dot org 2008-05-03 19:15
---
After some discussion on IRC the team recommends that we retire this PR. No
need to track bugs in two places and these latter bugs are regressions. The
latest not even related to gfortran.
So in the future,
--- Comment #150 from fxcoudert at gcc dot gnu dot org 2008-05-01 08:28
---
Apparently fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #149 from jv244 at cam dot ac dot uk 2008-04-28 12:45 ---
new ICE, PR36071.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #148 from jv244 at cam dot ac dot uk 2008-02-18 08:10 ---
(In reply to comment #147)
(In reply to comment #146)
(In reply to comment #145)
current gfortran trunk seems to fail on CVS sources of CP2K with:
PR34946
Joost - can this be closed again?
Done, but I hope
--- Comment #147 from pault at gcc dot gnu dot org 2008-02-16 18:54 ---
(In reply to comment #146)
(In reply to comment #145)
current gfortran trunk seems to fail on CVS sources of CP2K with:
PR34946
Joost - can this be closed again?
Cheers
Paul
--
--- Comment #145 from jv244 at cam dot ac dot uk 2008-01-23 19:02 ---
current gfortran trunk seems to fail on CVS sources of CP2K with:
/data03/vondele/clean/cp2k/src/../src/realspace_grid_types.F: In function
rs_grid_create:
--- Comment #146 from jv244 at cam dot ac dot uk 2008-01-23 19:30 ---
(In reply to comment #145)
current gfortran trunk seems to fail on CVS sources of CP2K with:
PR34946
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #144 from pault at gcc dot gnu dot org 2007-12-06 08:17 ---
(In reply to comment #143)
CP2K fails again to compile
Joost,
It's me again! I had naively thought that all the simple combinations of USE
statements were covered in the testsuite. Evidently, I was not just
--- Comment #143 from jv244 at cam dot ac dot uk 2007-12-05 10:12 ---
CP2K fails again to compile
all.f90:51639.23:
TYPE(cp_error_type), INTENT(inout) :: error
1
Error: Derived type 'cp_error_type' at (1) is being used before it is defined
--
jv244
--- Comment #142 from fxcoudert at gcc dot gnu dot org 2007-08-15 10:44
---
As there's only one bug left here, and it's been worked on, I'm closing this
PR. Hopefully, with the inclusion of cp2k into regression-testers, we won't
need to REOPEN it!
--
fxcoudert at gcc dot gnu dot
--- Comment #137 from pault at gcc dot gnu dot org 2007-07-24 06:18 ---
Joost,
Are you seeing this on bench01 and bench02? - this is on yesterday's tree
Program received signal SIGSEGV, Segmentation fault.
0x00c67e4a in __topology_util_MOD_topology_set_atm_mass ()
(gdb) backtrace
#0
--- Comment #138 from jv244 at cam dot ac dot uk 2007-07-24 06:31 ---
(In reply to comment #137)
Joost,
Are you seeing this on bench01 and bench02? - this is on yesterday's tree
By chance I ran a test yesterday evening (rev. 126856) which ran OK. This was
on an opteron with '-O3
--- Comment #139 from jv244 at cam dot ac dot uk 2007-07-24 07:22 ---
(In reply to comment #138)
I'll
start a new test with current trunk.
Tue Jul 24 06:32:19 UTC 2007 (revision 126866) is also passing the test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #140 from pault at gcc dot gnu dot org 2007-07-24 07:45 ---
(In reply to comment #139)
(In reply to comment #138)
I'll
start a new test with current trunk.
Tue Jul 24 06:32:19 UTC 2007 (revision 126866) is also passing the test.
You were right about the options: -O3
--- Comment #141 from jv244 at cam dot ac dot uk 2007-07-24 08:44 ---
(In reply to comment #140)
You were right about the options: -O3 -ffast-math -march=native triggers the
crash on PIV/Cygwin_NT, whereas -O1 does not. I'll retry latter with
-march=native, which I suspect from
--- Comment #135 from jv244 at cam dot ac dot uk 2007-07-10 07:05 ---
new bogus errors compiling all.f90 ... FX, how's the nightly tester setup
going?
cat out
all.f90:23538.44:
USE util,ONLY: sort
1
Error:
--- Comment #136 from jv244 at cam dot ac dot uk 2007-07-11 05:48 ---
(In reply to comment #135)
new bogus errors compiling all.f90 ...
filed as PR 32727
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #133 from fxcoudert at gcc dot gnu dot org 2007-07-06 12:18
---
I've made a first try to an automatic nightly tester of CP2K (thanks Joost for
the input files provided), I'll post full details when I'm sure it's working
OK.
--
--- Comment #134 from jv244 at cam dot ac dot uk 2007-07-06 14:52 ---
(In reply to comment #133)
I've made a first try to an automatic nightly tester of CP2K (thanks Joost for
the input files provided), I'll post full details when I'm sure it's working
OK.
that's great...
--
--- Comment #132 from jv244 at cam dot ac dot uk 2007-07-05 14:39 ---
new bogus gfortran error on CP2K : PR 32633
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #130 from ubizjak at gmail dot com 2007-07-03 07:11 ---
(In reply to comment #129)
current gfortran trunk seems to miscompile CP2K at -O2. The affected test is
regtest-ot/C2H4.inp, and the file that is being miscompiled is mulliken.F.
This
is a regression wrt to
--- Comment #131 from jv244 at cam dot ac dot uk 2007-07-03 07:22 ---
(In reply to comment #130)
(In reply to comment #129)
Could you use bisection to isolate the patch that introduced regression?
unfortunately, I don't have the setup to do so. However, I've filed a simple
testcase
--- Comment #128 from jv244 at cam dot ac dot uk 2007-07-02 21:36 ---
current gfortran trunk seems to miscompile CP2K at -O2. The affected test is
regtest-ot/C2H4.inp, and the file that is being miscompiled is mulliken.F. This
is a regression wrt to 4.2.0, but I'm not sure when it was
--- Comment #129 from jv244 at cam dot ac dot uk 2007-07-02 21:42 ---
(In reply to comment #128)
current gfortran trunk seems to miscompile CP2K at -O2. The affected test is
regtest-ot/C2H4.inp, and the file that is being miscompiled is mulliken.F.
This
is a regression wrt to
--- Comment #127 from jv244 at cam dot ac dot uk 2007-06-28 06:08 ---
(In reply to comment #126)
As Andrew pointed out in PR 32521 the valgrind warning was fixed in 4.2.1
(prerelease). I've now built the 4.2_branch, and the warning is indeed gone,
but unfortunately the same
--- Comment #119 from jv244 at cam dot ac dot uk 2007-06-27 08:24 ---
Testing gcc 4.2.0 I unfortunately found that it miscompiles CP2K.
The following testcase:
tests/DFTB/regtest-scc/h2o-1.inp
yields incorrect results. Should be similar to:
Total energy:
--- Comment #120 from pinskia at gmail dot com 2007-06-27 09:37 ---
Subject: Re: [meta-bugs] ICEs with CP2K
On 27 Jun 2007 08:24:46 -, jv244 at cam dot ac dot uk
[EMAIL PROTECTED] wrote:
# BUG
FCFLAGS = -O3 -ffast-math -ftree-vectorize -march=native
So -ffast-math with
--- Comment #121 from jv244 at cam dot ac dot uk 2007-06-27 12:47 ---
(In reply to comment #119)
I might try to find out which module gets miscompiled, but this could be a bit
of a slow process.
miscompilation happens with the module qs_neighbor_lists. It is a module with
lots of
--- Comment #122 from jv244 at cam dot ac dot uk 2007-06-27 12:51 ---
(In reply to comment #120)
I bet this is due to reduction which is done for -ffast-math with
-ftree-vectorize. Which case it might not be a bug. Yes 3 out of 130
is actually huge but if the values are huge to
--- Comment #123 from jv244 at cam dot ac dot uk 2007-06-27 13:54 ---
(In reply to comment #121)
(In reply to comment #119)
I might try to find out which module gets miscompiled, but this could be a
bit
of a slow process.
miscompilation happens with the module
--- Comment #124 from jv244 at cam dot ac dot uk 2007-06-27 14:21 ---
(In reply to comment #123)
and there is no valgrind error if I remove -ftree-vectorize from the options.
Which, I guess, explains why things get compiled correctly in that case.
--
--- Comment #125 from jv244 at cam dot ac dot uk 2007-06-27 14:45 ---
(In reply to comment #119)
Testing gcc 4.2.0 I unfortunately found that it miscompiles CP2K.
filed as PR 32521
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #126 from jv244 at cam dot ac dot uk 2007-06-27 19:55 ---
As Andrew pointed out in PR 32521 the valgrind warning was fixed in 4.2.1
(prerelease). I've now built the 4.2_branch, and the warning is indeed gone,
but unfortunately the same qs_neighbor_lists module is still
--- Comment #117 from pinskia at gcc dot gnu dot org 2007-06-22 07:24
---
(In reply to comment #116)
There is currently a new ICE
If you can reproduce it still, please CC me on the bug (as I caused this bug).
I might already have a fix for this bug already too (though the trip to
--- Comment #118 from jv244 at cam dot ac dot uk 2007-06-22 07:34 ---
(In reply to comment #117)
(In reply to comment #116)
There is currently a new ICE
If you can reproduce it still, please CC me on the bug (as I caused this
bug).
I might already have a fix for this bug
--- Comment #115 from jv244 at cam dot ac dot uk 2007-06-21 09:05 ---
trying to investigate the culprit of the slowdown mentioned in comment 112 I
found out that adding -pg to the compile flags leads to a miscompiled code.
I've filed PR 32450 to track the issue
--
--- Comment #116 from jv244 at cam dot ac dot uk 2007-06-22 05:56 ---
There is currently a new ICE
[EMAIL PROTECTED]:/scratch/vondele/gcc_test/gfortran/test/src gfortran -Os
all.f90
all.f90: In function compute_screening_matrices:
all.f90:305498: internal compiler error: in
--- Comment #112 from jv244 at cam dot ac dot uk 2007-06-20 20:25 ---
after the fix for PR 32140 gfortran compiles CP2K correctly on x86_64 using
'-O3 -ffast-math -ftree-vectorize -funroll-loops -march=native' . Thanks !
I've made a new tar file available that contains a more recent
--- Comment #113 from fxcoudert at gcc dot gnu dot org 2007-06-20 20:41
---
(In reply to comment #112)
after the fix for PR 32140 gfortran compiles CP2K correctly on x86_64 using
'-O3 -ffast-math -ftree-vectorize -funroll-loops -march=native' . Thanks !
Great. I hope we can get it
--- Comment #114 from jv244 at cam dot ac dot uk 2007-06-21 03:41 ---
(In reply to comment #113)
Great. I hope we can get it working with MPI (should probably already work)
I suspect that will be no real problem, but I do not have an MPI/gfortran setup
to check.
this seems quite
--- Comment #106 from tbm at cyrius dot com 2007-06-07 07:21 ---
(In reply to comment #101)
current gcc (i.e. after the fix for PR32018) still ICEs as described in
comment
#100
I independently reported a bug yesterday that has a very similar traceback as
what you posted in comment
--- Comment #107 from jv244 at cam dot ac dot uk 2007-06-07 09:25 ---
(In reply to comment #106)
(In reply to comment #101)
current gcc (i.e. after the fix for PR32018) still ICEs as described in
comment
#100
I independently reported a bug yesterday that has a very similar
--- Comment #108 from jv244 at cam dot ac dot uk 2007-06-07 09:34 ---
Unfortunately the newly updated compiler ICEs now at -O0
gfortran -O0 pw_types.f90
/scratch/vondele/clean/cp2k/src/../src/pw_types.F: In function
pw_integral_a2b:
--- Comment #109 from jv244 at cam dot ac dot uk 2007-06-07 11:56 ---
(In reply to comment #108)
Unfortunately the newly updated compiler ICEs now at -O0
this is now PR 32242
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #110 from jv244 at cam dot ac dot uk 2007-06-07 19:26 ---
After commenting the code leading to PR 32242 compilation leads to the
following ICE:
/scratch/vondele/clean/cp2k/src/../src/pw_types.F: In function
pw_integral_a2b:
--- Comment #111 from jv244 at cam dot ac dot uk 2007-06-07 19:36 ---
(In reply to comment #110)
/scratch/vondele/clean/cp2k/src/../src/pw_types.F:2647: internal compiler
error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877
filed as PR 32248
--
--- Comment #105 from jv244 at cam dot ac dot uk 2007-06-01 07:08 ---
Another ICE has been filed as PR 32176
gfortran -fprefetch-loop-arrays -O2 test.f90
test.f90: In function polint:
test.f90:1: internal compiler error: tree check: expected integer_cst, have
plus_expr in
--- Comment #104 from jv244 at cam dot ac dot uk 2007-05-29 15:07 ---
Even at optimisations levels lower than the one needed to generate the ICE of
PR 32096 (thanks tobias burnus), CP2K seems miscompiled. One possible testcase
has been added as PR 32140.
--
--- Comment #101 from jv244 at cam dot ac dot uk 2007-05-26 08:45 ---
current gcc (i.e. after the fix for PR32018) still ICEs as described in comment
#100
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #102 from jv244 at cam dot ac dot uk 2007-05-26 09:02 ---
(In reply to comment #101)
current gcc (i.e. after the fix for PR32018) still ICEs as described in
comment
#100
the compiler options '-c -O3 -ftree-vectorize -ffast-math' seem to be needed,
it also fails with
--- Comment #103 from jv244 at cam dot ac dot uk 2007-05-26 10:06 ---
(In reply to comment #101)
current gcc (i.e. after the fix for PR32018) still ICEs as described in
comment
#100
the compiler options '-c -O3 -ftree-vectorize -ffast-math' seem to be needed,
it also fails with
--- Comment #97 from jv244 at cam dot ac dot uk 2007-05-21 08:30 ---
This morning's mainline gives a new ICE on the CVS version of CP2K (the file in
question is not in the tarbal of comment #0)
gfortran -c -O3 -ftree-vectorize -ffast-math -march=native
semi_empirical_int_ana.f90
--- Comment #98 from dfranke at gcc dot gnu dot org 2007-05-21 12:38
---
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #99 from jv244 at cam dot ac dot uk 2007-05-21 15:40 ---
(In reply to comment #98)
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
thanks for adding this PR.
Looking at PR32018, I notice that the
--- Comment #100 from jv244 at cam dot ac dot uk 2007-05-21 15:58 ---
(In reply to comment #99)
(In reply to comment #98)
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
equivalent and got the ICE described in PR32018.
thanks for adding this PR.
--- Comment #96 from jv244 at cam dot ac dot uk 2007-05-04 09:15 ---
(In reply to comment #91)
current (i.e. this morning) mainline seems to miscompile CP2K (tested current
CVS of CP2K).
Current SVN gfortran compiles CP2K again correctly. Closing the bug again
--
jv244 at cam
--- Comment #91 from jv244 at cam dot ac dot uk 2007-04-24 13:37 ---
current (i.e. this morning) mainline seems to miscompile CP2K (tested current
CVS of CP2K). The code compiled with '-O3 -ftree-vectorize -ffast-math
-march=native' on an opteron segfaults on several regtests. The same
--- Comment #92 from jv244 at cam dot ac dot uk 2007-04-24 14:31 ---
(In reply to comment #91)
/QS/regtest-gpw-1/NO2_lsd.inp.out
I'll see if I can reduce the number of optimization options.
the above testcase also fails at a plain '-O2' so I suspect it won't happen
only on opteron.
--- Comment #93 from jv244 at cam dot ac dot uk 2007-04-24 15:11 ---
(In reply to comment #91)
I checked that the miscompilation at '-O2' also happens for the sources in the
initial comment, so it is definitely a gfortran regression. Furthermore, by
recompiling ai_overlap_new.F and
--- Comment #94 from jv244 at cam dot ac dot uk 2007-04-24 15:27 ---
In fact, gfortran gives a hint here. The file that gets miscompiled produces
the following warnings:
cp2k/obj/Linux-x86-64-gfortran/sdbg gfortran -c -O2 -g -Wall -Wextra
ai_overlap_new.f90
ai_overlap_new.f90: In
--- Comment #95 from jv244 at cam dot ac dot uk 2007-04-24 15:42 ---
added PR 31683 with a reduced testcase
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #90 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:24
---
Closing as fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #83 from jv244 at cam dot ac dot uk 2007-03-16 11:11 ---
I upgraded trunk, and now the code compiles again with -march=native, but
crashes as follows:
Program received signal SIGILL, Illegal instruction.
0x00afa307 in __qs_resp__resp_fit ()
objdump -d gives me
--- Comment #84 from ubizjak at gmail dot com 2007-03-16 11:21 ---
(In reply to comment #83)
I upgraded trunk, and now the code compiles again with -march=native, but
crashes as follows:
Program received signal SIGILL, Illegal instruction.
0x00afa307 in __qs_resp__resp_fit
--- Comment #85 from jv244 at cam dot ac dot uk 2007-03-16 11:52 ---
(In reply to comment #84)
Could you post your cpuflags? There should be lahf_lm flag present for
opterons.
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts
--- Comment #86 from jv244 at cam dot ac dot uk 2007-03-16 12:07 ---
(In reply to comment #85)
(In reply to comment #84)
Could you post your cpuflags? There should be lahf_lm flag present for
opterons.
sorry, the previous post was of the wrong machine... these are the correct
--- Comment #87 from ubizjak at gmail dot com 2007-03-16 12:16 ---
(In reply to comment #86)
sorry, the previous post was of the wrong machine... these are the correct
flags and no (lahf_lm):
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 840
--- Comment #88 from ubizjak at gmail dot com 2007-03-16 12:43 ---
(In reply to comment #83)
I upgraded trunk, and now the code compiles again with -march=native, but
crashes as follows:
Program received signal SIGILL, Illegal instruction.
0x00afa307 in __qs_resp__resp_fit
--- Comment #89 from jv244 at cam dot ac dot uk 2007-03-16 14:16 ---
Thanks for your reports!
and you for your fixes... things are back to working now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #77 from jv244 at cam dot ac dot uk 2007-03-14 14:48 ---
Currently
GNU Fortran (GCC) 4.3.0 20070313 (experimental)
there seems to be a new gcc error on CP2K:
gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
-msse2 fparser.f90
--- Comment #78 from ubizjak at gmail dot com 2007-03-14 15:01 ---
(In reply to comment #77)
gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
-msse2 fparser.f90
/tmp/ccNk6D7G.s: Assembler messages:
/tmp/ccNk6D7G.s:820: Error: suffix or operands
--- Comment #79 from jv244 at cam dot ac dot uk 2007-03-14 15:14 ---
(In reply to comment #78)
Could you post the temporary asm (only lines around line 820 will be enough)
to
check what is going wrong?
.L157:
movslq %r13d,%rax
imulq %rsi, %rax
addq
--- Comment #80 from burnus at gcc dot gnu dot org 2007-03-14 15:15 ---
(In reply to comment #76)
One issue with OpenMP is that it is very easy to break an OpenMP
code (it is just comments),
This is a complaint I've heard before. I wonder if you have any suggestions
to make it more
--- Comment #81 from ubizjak at gmail dot com 2007-03-14 15:30 ---
(In reply to comment #79)
movsd %xmm2, (%rsp)
fldl(%rsp)
movsd %xmm1, (%rsp)
fldl(%rsp)
fxch%st(1)
.L120:
fprem
fnstsw %ax
sahf
--- Comment #82 from jv244 at cam dot ac dot uk 2007-03-14 16:29 ---
Huh, I somehow misread opteron for athlon. Your code is OK for x86_64, but it
looks to me that you will have to upgrade binutils.
upgrading binutils is not much of an option for me, but with -march=x86-64 I
get
--- Comment #76 from steven at gcc dot gnu dot org 2007-03-12 23:24 ---
Joost,
You wrote in comment #75:
One issue with OpenMP is that it is very easy to break an OpenMP
code (it is just comments),
This is a complaint I've heard before. I wonder if you have any suggestions to
make it
--- Comment #74 from fxcoudert at gcc dot gnu dot org 2007-03-03 08:52
---
(In reply to comment #73)
I've added PR 31021 to track some performance issue with gfortran on one of
CP2K's kernels.
Thanks for your work, Joost. I wonder if you have done OpenMP testing, also (I
imagine
--- Comment #75 from jv244 at cam dot ac dot uk 2007-03-03 10:12 ---
Joost. I wonder if you have done OpenMP testing, also (I
imagine that, OpenMP being frequently broken on cp2k and gfortran being a free
compiler OpenMP-capable, you might have tried it :)
No, haven't tried it yet.
--- Comment #73 from jv244 at cam dot ac dot uk 2007-03-02 08:41 ---
I've added PR 31021 to track some performance issue with gfortran on one of
CP2K's kernels.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #72 from jv244 at cam dot ac dot uk 2007-02-19 19:51 ---
I checked that gfortran yields correct results for the CP2K testsuite with the
options:
-O0 -g -fbounds-check
and
-O3 -ffast-math -funroll-loops -ftree-vectorize -fomit-frame-pointer -msse2
-march=native
I've added the
--- Comment #69 from jv244 at cam dot ac dot uk 2007-02-17 09:17 ---
(In reply to comment #68)
Current gfortran compiles the code with the standard -OX switches, however,
still ICEs with '-O2 -fbounds-check -ftree-vectorize -ftree-loop-linear
-ffast-math -O2 -msse3' on our local
--- Comment #70 from steven at gcc dot gnu dot org 2007-02-17 16:01 ---
The -ftree-loop-linear work is still too buggy at this time to be taken
seriously. I would strongly recommend against even considering the use of it.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #71 from jv244 at cam dot ac dot uk 2007-02-17 16:17 ---
(In reply to comment #68)
Current gfortran compiles the code with the standard -OX switches, however,
still ICEs with '-O2 -fbounds-check -ftree-vectorize -ftree-loop-linear
-ffast-math -O2 -msse3' on our local
--- Comment #68 from jv244 at cam dot ac dot uk 2007-02-17 07:50 ---
Current gfortran compiles the code with the standard -OX switches, however,
still ICEs with '-O2 -fbounds-check -ftree-vectorize -ftree-loop-linear
-ffast-math -O2 -msse3' on our local opteron.
all_cp2k_gfortran.f90:
--- Comment #64 from jvdelisle at gcc dot gnu dot org 2007-02-16 02:50
---
I now have a machine at home here running i686-pc-gnu-linux that I plan to set
up daily compile test on. Joost, does that link in coment #63 get updated
daily?
--
--- Comment #65 from jv244 at cam dot ac dot uk 2007-02-16 05:57 ---
(In reply to comment #64)
I now have a machine at home here running i686-pc-gnu-linux that I plan to set
up daily compile test on. Joost, does that link in coment #63 get updated
daily?
No, the idea is that you
--- Comment #66 from jvdelisle at gcc dot gnu dot org 2007-02-16 06:33
---
With todays trunk:
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr
--enable-languages=c,fortran --disable-libmudflap --enable-libgomp
Thread model: posix
gcc
--- Comment #67 from fxcoudert at gcc dot gnu dot org 2007-02-16 06:50
---
PR 30391 is fixed with rev. 122030, so we should close this PR. Please reopen
if we regress.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #60 from jv244 at cam dot ac dot uk 2007-02-13 09:20 ---
When you have a moment, could you confirm that all is now well with trunk,
please? Once again, I am sorry about the breakage. Now I see Daniel's
testcase, I realise that I could easily have devised a test... with
--- Comment #61 from pault at gcc dot gnu dot org 2007-02-13 13:51 ---
(In reply to comment #60)
Yes, current trunk compiles CP2K again at -O0
Great!
to time. It is very annoying to have to fight compilers, after the computer
center upgraded a machine. My hope is that CP2K being
--- Comment #62 from kargl at gcc dot gnu dot org 2007-02-13 19:50 ---
(In reply to comment #48)
Currently, there is a new ICE on CP2K (see initial comment) that happens at
any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal compiler
--- Comment #63 from jv244 at cam dot ac dot uk 2007-02-13 20:04 ---
Well, I'd add it to my testsuite if weren't a PITA to figure out how to
make it build.
wget http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz
gunzip all_cp2k_gfortran.f90.gz
gfortran -c
--- Comment #48 from jv244 at cam dot ac dot uk 2007-02-12 15:56 ---
Currently, there is a new ICE on CP2K (see initial comment) that happens at any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal compiler error: Segmentation fault
Please
--- Comment #49 from fxcoudert at gcc dot gnu dot org 2007-02-12 16:16
---
(In reply to comment #48)
Currently, there is a new ICE on CP2K (see initial comment) that happens at
any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal
--- Comment #50 from jv244 at cam dot ac dot uk 2007-02-12 17:09 ---
I really think CP2K should be added to some nightly
tester somewhere by gfortran developers...
Well, I second that, but we first need to get it working (like, the middle-end
people have to move on PR30391).
--- Comment #51 from jv244 at cam dot ac dot uk 2007-02-12 17:12 ---
I'm pretty sure it's the same problem that was already reported here:
http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html
Of course, a confirmation wouldn't hurt, but I don't have time right now. If
you manage
--- Comment #52 from pinskia at gcc dot gnu dot org 2007-02-12 17:20
---
I don't know if this triggers something, looks like a simple statement.
Yes that triggers my memory of PR 30391.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #53 from jv244 at cam dot ac dot uk 2007-02-12 17:52 ---
(In reply to comment #52)
I don't know if this triggers something, looks like a simple statement.
Yes that triggers my memory of PR 30391.
No, that one only happens at -O1 and above, the current ICE is at -O0
1 - 100 of 138 matches
Mail list logo
