This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
- From: "fxcoudert at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Jun 2007 20:41:20 -0000
- Subject: [Bug fortran/29975] [meta-bugs] ICEs with CP2K
- References: <bug-29975-6642@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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 working with MPI (should probably already work) and
OpenMP!
> http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz
Thanks! The GCC compile farm is under rearrangement, but I hope to get it
running nightly as part of an "extended testsuite" when the service is
established again.
> this seems quite good (despite being 10-15% slower)
Indeed, this is not so bad. Do you use external libraries?
> For the first benchmark
> most of the slowdown seems to be in one part of the code (core_hamiltonian),
> for which gfortran is about 35% slower (I suspect the difference comes from one
> subroutine ai_overlap_new).
Is that related to PR31021 or PR31079?
> There is one more issue, for which I will file a PR shortly. Compilation fails
> with an out of memory error at '-O1 -fbounds-check'.
Yup, -fbounds-check for code with lots of array access has a high cost, because
each array access generates an IF and a function call. Is that with a single
cp2k source file, or your "all-in-one package"?
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn|32439 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975