--- Comment #3 from pault at gcc dot gnu dot org 2006-11-27 22:21 ---
Joost,
all_cp2k_gfortran.f90:128714: internal compiler error: in build_int_cst_wide,
at tree.c:852
Is this the same as PR29976 by any chance?
Paul
PS I should change your email address on testcases!
--
http://
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-11-27 22:24
---
(In reply to comment #3)
> Is this the same as PR29976 by any chance?
Hi Paul,
This PR is a metabug for CP2K issues; PR29976 is one of those (I'm in a middle
of a workshop frenzy right now, so I don't have time
--- Comment #5 from jv244 at cam dot ac dot uk 2006-11-28 15:36 ---
after the fix for 29976 I get with current mainline :
all_cp2k_gfortran.f90:347635: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gn
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-28 18:04 ---
Reduced testcase:
PROGRAM fparser
IMPLICIT NONE
CHARACTER (LEN=1), DIMENSION(3:7), PARAMETER :: Ops = &
(/ '+', '-', '*', '/', '^' /)
CHARACTER (LEN=3) :: F = "ABC"
IF (ANY(F(2:2) == Ops(5:6))) STOP
END
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-29 22:15 ---
Joost,
Do you happen to know at what revision things went bad?
As the likely author of the regression, I would be interested to know, so that
I can dig us out again.
Regards
Paul
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from jv244 at cam dot ac dot uk 2006-11-29 22:26 ---
(In reply to comment #7)
> Joost,
>
> Do you happen to know at what revision things went bad?
I'm afraid I don't...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #9 from burnus at gcc dot gnu dot org 2006-11-30 07:36 ---
(In reply to comment #7)
> Do you happen to know at what revision things went bad?
The example program, I extracted (comment #6), actually crashes here with
- gfortran 4.1.2 20061115
- gcc-Version 4.2.0 20061006
- gc
--- Comment #10 from pault at gcc dot gnu dot org 2006-12-01 13:16 ---
Created an attachment (id=12722)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12722&action=view)
This patch fixes the testcase of #6 and regtests on Cygwin_NT/PIV
Joost,
I am not sure that I see how the test
--- Comment #11 from burnus at gcc dot gnu dot org 2006-12-01 17:20 ---
Created an attachment (id=12724)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12724&action=view)
test case for interface "bl_copy"
(In reply to comment #10)
> This patch fixes the testcase of #6 and regtests
--- Comment #12 from jv244 at cam dot ac dot uk 2006-12-02 13:37 ---
> I am not sure that I see how the test case in #6 can ever have worked; if it
> is
> indeed representative of the code in CP2K, I do not see how that can have
> worked either.
fparser is a relatively new addition
--- Comment #13 from jv244 at cam dot ac dot uk 2006-12-02 13:55 ---
(In reply to comment #11)
> Created an attachment (id=12724)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12724&action=view) [edit]
> test case for interface "bl_copy"
> all_cp2k_gfortran.f90:418697.22:
> USE
--- Comment #14 from jv244 at cam dot ac dot uk 2006-12-02 14:00 ---
> Are you in a position to try the patch on CP2K?
no quite so easy right now, but I'll be svn updating as soon as it is in. Looks
like tobias anyway tested it OK.
> your PRs have given me something absorbing
... th
--- Comment #15 from pault at gcc dot gnu dot org 2006-12-02 17:50 ---
> I don't think this is an error... you can add further compilers to the list of
> 'believers' xlf90 / pgf90.
There is no need to add any more compilers to the list - it's manifestly a
gfortran bug. Whilst the gene
--- Comment #16 from pault at gcc dot gnu dot org 2006-12-03 13:38 ---
Created an attachment (id=12730)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12730&action=view)
This fixes the INTERFACE part of the problem.
I have not regtested the full suite yet; just gfortran.dg/i*
The
--- Comment #17 from burnus at gcc dot gnu dot org 2006-12-03 14:44 ---
> This fixes the INTERFACE part of the problem.
> I have not regtested the full suite yet; just gfortran.dg/i*
I just regression tested it on x86_64-unknown-linux-gnu.
I also tried to compile all_cp2k_gfortran.f90 -
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-12-03 17:42 ---
Subject: Re: [meta-bugs] ICEs with CP2K
Tobias,
>
> The patch looks good -- and the test cases as well.
>
Great!
> Just for completeness, the relevant part of the standard is:
> "C1209 (R1206) A procedure-name s
--- Comment #19 from paulthomas2 at wanadoo dot fr 2006-12-03 19:41 ---
Subject: Re: [meta-bugs] ICEs with CP2K
Tobias,
> Note that this does not fix everything as gfortran rejects also
> interface_y.f90
> if I comment the "call bl_copy(1.0, chr)"; if I understand the standard
> corre
--- Comment #20 from pault at gcc dot gnu dot org 2006-12-03 21:01 ---
Created an attachment (id=12733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12733&action=view)
A further development of the patch
This version now behaves in the same way as other compilers; the testcase
int
--- Comment #21 from burnus at gcc dot gnu dot org 2006-12-03 21:50 ---
> Do you think that the error in gfortran.dg/interface_1.f90 is correct?
> I have fix for the above that also stops the doubling of the error
> message. However, it breaks interface_1.f90 because there is no
> r
--- Comment #22 from burnus at gcc dot gnu dot org 2006-12-03 22:07 ---
And here is the relevant part of the standard Fortran 2003, Section 11.2.1
("USE") [cf. also F95, Sec 11.3.2]:
"Two or more accessible entities, other than generic interfaces or defined
operators, may have the same
--- Comment #23 from burnus at gcc dot gnu dot org 2006-12-03 22:49 ---
(In reply to comment #20)
> now gives a warning in interface_1.f90, rather than an error.
I think one can live with this - Lahey also gives only a warning. (ifort a
warning; Richard says it is invalid.)
However, on
--- Comment #24 from pault at gcc dot gnu dot org 2006-12-04 20:55 ---
OK, I'll put this in the pipeline for clean-up and submission.
Paul
> However, one gets neither a warning nor an error for the following test case,
> which can be found in the Fortran 2003 standard, Section C.11.2:
--- Comment #25 from burnus at gcc dot gnu dot org 2006-12-04 21:15 ---
> OK, I'll put this in the pipeline for clean-up and submission.
Thanks. At least the generic interface patch should be completely ok; for the
other one, I'll try to dream up something which is not correctly covered
--- Comment #26 from patchapp at dberlin dot org 2006-12-05 19:15 ---
Subject: Bug number PR29975
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00336.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #27 from patchapp at dberlin dot org 2006-12-08 19:50 ---
Subject: Bug number PR29975
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00560.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #28 from pault at gcc dot gnu dot org 2006-12-09 21:13 ---
Subject: Bug 29975
Author: pault
Date: Sat Dec 9 21:13:29 2006
New Revision: 119697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119697
Log:
2006-12-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #42 from burnus at gcc dot gnu dot org 2006-12-21 16:09 ---
I'm in faviour of closing this bug.
The patch associated to this PR is checked in into 4.3 and 4.2
And all the dependend bugs are either fixed or at least check into 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #43 from steven at gcc dot gnu dot org 2006-12-23 14:51 ---
Fixed in GCC 4.3.0
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #44 from jv244 at cam dot ac dot uk 2007-01-06 06:30 ---
Current gcc ICEs again on CP2K:
gfortran -c -O3 -ftree-vectorize -ffast-math -march=opteron -fopenmp
mc_coordinates.f90
mc_coordinates.f90: In function check_for_overlap:
mc_coordinates.f90:192: internal compiler e
--- Comment #45 from pinskia at gcc dot gnu dot org 2007-01-06 06:41
---
(In reply to comment #44)
> gfortran -c -O3 -ftree-vectorize -ffast-math -march=opteron -fopenmp
> mc_coordinates.f90
> mc_coordinates.f90: In function check_for_overlap:
> mc_coordinates.f90:192: internal compil
--- Comment #46 from burnus at gcc dot gnu dot org 2007-01-06 09:22 ---
(In reply to comment #44)
> Current gcc ICEs again on CP2K
I tried to reproduce this with gfortran (trunk) of yesterday with CP2k of today
- and I failed to get an ICE. I tried then to directly use gfortran-4.2 (als
--- Comment #47 from fxcoudert at gcc dot gnu dot org 2007-01-06 10:43
---
(In reply to comment #44)
> Current gcc ICEs again on CP2K:
Reduced testcase reported as PR 30391. I appeared between 20070104 and today,
and happens on both i686-linux and x86-64 linux; I pinged the person that
--- 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 s
--- 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: intern
--- 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 PR3039
--- 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 mana
--- 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 -
--- 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
--- 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 #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 #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 #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 #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 #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 bein
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 op
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 qs_c
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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:
/scratch/vondele/clean/cp2k/src/../src/pw_types.F
--- 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 #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 #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 #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
1 - 100 of 138 matches
Mail list logo
