--- 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, p
--- 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 #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
S
--- 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
Status|RESO
--- 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, b
--- 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
--
http://gcc.gnu.org/bugz
--- 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 #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:
/data03/vondele/clean/cp2k/src/../src/realspace_grid_types.
--- 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 nai
--- 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 a
--- 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 org
--- 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 fr
--- 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
--- 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 #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 '"
--- 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 0
--- 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 #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: Symbol
--- 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 #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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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 #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 #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 wr
--- 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 4.
--- 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 in
--- 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 qs_neig
--- 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 miscom
--- 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 #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.
--
http://gcc.gnu.org/bugzilla/show
--- 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 #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 b
--- 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
--- 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 vecto
--- 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 #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 #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 Ja
--- 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 build2_st
--- 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
--
http://gcc.gnu.org
--- 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 #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 #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 ver
--- 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
--
http://gcc.gnu.org/bugz
--- 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:
/scratch/vondele/clean/cp2k/src/../src/pw_types.F
--- 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 #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:
/scratch/vondele/clean/cp2k/src/../src/pw_types.F:37
--- 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 si
--- 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 commen
--- 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 int_cst_valu
--- 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.
--
http://gcc.gnu.org/bugzi
--- 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 #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 #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 #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 #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 #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 #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
/scratc
--- 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 d
--- 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
Bu
--- 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 funct
--- 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 qs_c
--- 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 #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 c
--- 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 #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 #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
--- 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
--- 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 corre
--- 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 a
--- 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
--- 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
a
--- 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
g
--- 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
>
--- 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
--- 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
ad
--- 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 i
--- 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
/tmp/ccNk6D7G.s
--- 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 i
--- 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 #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 th
--- 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 #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 op
--- 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 #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 op
--- 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: I
--- 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 #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 ver
--- 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 y
--- 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?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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 all_cp2k_gfo
--- 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 co
--- 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 bein
--- 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 #59 from pault at gcc dot gnu dot org 2007-02-13 06:56 ---
(In reply to comment #58)
> Subject: Re: [meta-bugs] ICEs with CP2K
>
> jv244 at cam dot ac dot uk wrote:
> > --- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18
> > ---
> >
> >
> >> Yes, t
--- Comment #58 from paulthomas2 at wanadoo dot fr 2007-02-12 22:55 ---
Subject: Re: [meta-bugs] ICEs with CP2K
jv244 at cam dot ac dot uk wrote:
> --- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18 ---
>
>
>> Yes, that's the one: http://gcc.gnu.org/ml/fortran
--- Comment #57 from jv244 at cam dot ac dot uk 2007-02-12 19:18 ---
> Yes, that's the one: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html
>
for people reducing the bug, I found that it is in the module cp_fm_pool_types.
This indicates the the line number indicated in the segfaul
--- Comment #56 from fxcoudert at gcc dot gnu dot org 2007-02-12 18:30
---
(In reply to comment #55)
> Program received signal SIGSEGV, Segmentation fault.
> gfc_insert_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0 )
> at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:137
> 137
--- Comment #55 from jv244 at cam dot ac dot uk 2007-02-12 18:26 ---
> Nonetheless, I do not see it being associated with my doo-doo in module.c, do
> you?
I'm not an expert, but this is a traceback, leading to module.c:
Program received signal SIGSEGV, Segmentation fault.
gfc_insert_b
--- Comment #54 from pault at gcc dot gnu dot org 2007-02-12 18:02 ---
(In reply to comment #53)
> (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
1 - 100 of 138 matches
Mail list logo
