[Bug fortran/29975] New: [metabug] ICEs with CP2K

[Bug fortran/29975] New: [metabug] 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: 1323 bytes --]

I'm trying to compile CP2K with gfortran (yesterday's mainline), but I'm
experiencing ICEs. Since it seems to be happening more often with CP2K I've
added this metabug.

the first one I see is:

gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90: In function âpw_sumupâ:
all_cp2k_gfortran.f90:128714: internal compiler error: in build_int_cst_wide,
at tree.c:852
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

the file is to large to be attached in bugzilla, but I've made it available
(temporarily) for download:

http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz

it might be a good idea to add it to some gfortran testsuite. People that
prefer more managable sources can get it from
http://cp2k.berlios.de/download.html
plus instructions on how to run the CP2K testsuite (all tests should pass with
gfortran, http://cp2k.berlios.de/regtest.html).


-- 
           Summary: [metabug] ICEs with CP2K
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        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=29975

[Bug fortran/29975] [meta] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

------- Comment #1 from fxcoudert at gcc dot gnu dot org  2006-11-25 13:22 -------
Hi Joost,

I'll look into it. I now regularly build cp2k with gfortran (usually 4.2
branch) on i686-linux for my work but I haven't see this ICE yet. Just in case,
what's the platform you're building on?


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |meta-bug
   Last reconfirmed|0000-00-00 00:00:00         |2006-11-25 13:22:11
               date|                            |
            Summary|[metabug] ICEs with CP2K    |[meta] ICEs with CP2K


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

[Bug fortran/29975] [meta] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #2 from jv244 at cam dot ac dot uk  2006-11-25 14:15 -------
(In reply to comment #1)
> Hi Joost,
> I'll look into it. I now regularly build cp2k with gfortran (usually 4.2
> branch) on i686-linux for my work but I haven't see this ICE yet. Just in case,
> what's the platform you're building on?

x86_64-linux. However, I seem to see ICEs that look more like frontend problems
as well, so I don't think it is all platform dependent. Some see to be in files
that have been recently added, e.g.:

gfortran -c -O3 -ftree-vectorize -ffast-math -march=nocona fparser.f90
fparser.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

or a bogus error:

f77_blas.f90:22.22:

  USE f77_blas_generic
                     1
Error: Name 'bl_copy' at (1) is an ambiguous reference to 'bl_copy' from
current program unit

(the last two I get compiling the 'normal' sources)


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|29976                       |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

------- 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 to reduce the other issues
mentionned by Joost, although I can confirm at least the second one (the
segfault)).

I think it's a good thing to have that metabug PR, because CP2K is a very good
test for a Fortran95 compiler, as it heavily uses many F95 features.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 <URL:http://gcc.gnu.org/bugs.html> for instructions.

which is also different from the bugs mentioned in comment 2


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

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

Backtrace:
#0  0x000000000041cd1b in simplify_const_ref (p=0xdee450) at expr.c:1238
#1  0x000000000041d4e5 in gfc_simplify_expr (p=0xdee450, type=0) at expr.c:1546
#2  0x000000000041da97 in simplify_parameter_variable (p=0xdeecb0, type=0) at
expr.c:1421
#3  0x000000000041d4c1 in gfc_simplify_expr (p=0xdefd10, type=0) at expr.c:1517


-- 

burnus at gcc dot gnu dot org changed:

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


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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/show_bug.cgi?id=29975

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- 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
- gcc-Version 4.2.0 20060910


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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 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.  I have been back through the diffs for expr
(find_array_section) since I wrote it to fix PR16206 - it has had this error in
it from the start.  The bright side is that it is a one liner:-)

Are you in a position to try the patch on CP2K?

Regards

Paul

PS I should thank you; your PRs have given me something absorbing to do during
what turned out to be a personally difficult year or so!


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- 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 on Cygwin_NT/PIV
Tested on x86_64-unknown-linux-gnu and I get no ICE for both the test case in
comment 6 as for all_cp2k_gfortran.f90.gz of comment 0.

For all_cp2k_gfortran.f90, however, I get an error (after 2min compiling):

all_cp2k_gfortran.f90:418697.22:
  USE f77_blas_generic
                     1
Error: Name 'bl_copy' at (1) is an ambiguous reference to 'bl_copy' from
current program unit
This is an error (see attachment) since the 'bl_copy' is only enhanced by the
second "interface bl_copy" (happily accepted by ifort, g95 and NAG f95). I
think even if one copies the sdcopy definition from f77_blas_extra to
f77_blas_generic this shouldn't be an error as long as one does not access
'bl_copy' (f95 and ifort accept this; g95 rejects it).

I tried compiling all_cp2k_gfortran.f90.gz with ifort, but I get after 4
minutes using "ifort -O0":
Fatal compilation error: Out of memory asking for 33558536.

And g95 (after using VIRT=3GB of memory for 7m [on a 2GB system]):
virtual memory exhausted: Cannot allocate memory


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 to CP2K, so FX statement might be wrt to
an older version of CP2K. I'm not sure that I can completely agree with FX,
I've never seen a gfortran compiled CP2K pass all our regtests without a
segfault. Of course, CP2K is fairly complex so there could be bugs, but it is
also quite wel tested.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 f77_blas_generic
>                      1
> Error: Name 'bl_copy' at (1) is an ambiguous reference to 'bl_copy' from
> current program unit
> This is an error (see attachment) since the 'bl_copy' is only enhanced by the
> second "interface bl_copy" (happily accepted by ifort, g95 and NAG f95). 

I don't think this is an error... you can add further compilers to the list of
'believers' xlf90 / pgf90.

> 
> And g95 (after using VIRT=3GB of memory for 7m [on a 2GB system]):
> virtual memory exhausted: Cannot allocate memory
> 

compiles fine here. However, that's why I'm hoping that the gfortran crew adds
this somewhere to a nightly tester. A whole list of commercial compilers failed
(in the past years) to compile even single files with either memory explosions
/ infinite loops / ICEs ... this is particularly true if things like IPO are
switched on.

first things first however ...


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

... there are still a few left, as I find time (likely not before next year)
I'll try to add a few more. My personal experience with this is that they can
be a bit too absorbing.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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 generic name might be ambiguous, the ambiguity is
resolved by the specific interfaces.

I'll have look at it tomorrow.

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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 two tests are called interface_x.f90 and interface_y.f90 because I have
some other interface related patches that have already been sumbitted - I just
cannot remember how many there are.  This is one of this afternoon's tasks:-)

Paul 


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- 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 -- and it compiles (gfortran -c)
ok.

The patch looks good -- and the test cases as well.

Just for completeness, the relevant part of the standard is:
"C1209 (R1206) A procedure-name shall not specify a procedure that is specified
previously in any procedure-stmt in any accessible interface with the same
generic identifier."


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
correctly, the ambiguity is ok as long as one does not try to access bl_copy.
(And ifort/NAG f95 and sunf95 agree with me.)

Something which puzzles me is also the error message; one gets *twice*:
interface_y.f90:39.58:

  USE f77_blas_extra ! { dg-error "Ambiguous|interfaces" }
                                                         1
Error: Ambiguous interfaces 'sdcopy' and 'recopy' in generic interface
'bl_copy' at (1)


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[paulthomas2 at wanadoo dot fr]

------- 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 shall not specify a procedure that is specified
> previously in any procedure-stmt in any accessible interface with the same
> generic identifier."
>
>   
Thanks - I realised that there must be something like this because the 
CP2K usage was accepted by other compilers and that it is logical that  
it should be so.
> 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
> correctly, the ambiguity is ok as long as one does not try to access bl_copy.
> (And ifort/NAG f95 and sunf95 agree with me.)
>   
This is equally understandable.  It SHOULD be easy to put this bit right.
> Something which puzzles me is also the error message; one gets *twice*:
> interface_y.f90:39.58:
>
>   USE f77_blas_extra ! { dg-error "Ambiguous|interfaces" }
>                                                          1
>   
....hence the form of the dg-error above; I was less interested to put 
this right than to have it accepting the correct code.  This is not 
unusual in such errors.  Sometimes...., sometimes I succeed in finding 
out why!

Thanks

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[paulthomas2 at wanadoo dot fr]

------- 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
> correctly, the ambiguity is ok as long as one does not try to access bl_copy.
> (And ifort/NAG f95 and sunf95 agree with me.)
>   
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 
refernce to the generic interface 'ambiguous' and so, no error.

Cheers

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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
interface_y.f90 now distinguishes interfaces that are referenced from those
that are not and now gives a warning in interface_1.f90, rather than an error.

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #12730|0                           |1
        is obsolete|                            |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- 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 
> refernce to the generic interface 'ambiguous' and so, no error.

See the explanation of Richard Main in
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/44aa13e0102ec83d

interface_1.f90 *is* invalid. (Which is not detected by sunf95 and NAG f95, by
the way; it is detected by ifort.)


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- 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 identifier only if the identifier is not used to
refer to an entity in the scoping unit. Generic interfaces and defined
operators are handled as described in section 16.2.3. Except for these cases,
the local identifier of any entity given accessibility by a USE statement shall
differ from the local identifiers of all other entities accessible to the
scoping unit through USE statements and otherwise."

I don't see it right way, but Richard Main claims that alreay using 
   use module1, only: ambiguous_symbol
   use module2
is enough to make it invalid (this is not even detected by ifort).


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

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

INTERFACE BAD8 ! this interface is invalid !
  ! despite the fact that it is unambiguous !
  SUBROUTINE S8A(X,Y,Z)
    REAL,OPTIONAL :: X
    INTEGER :: Y
    REAL :: Z
  END SUBROUTINE S8A
  SUBROUTINE S8B(X,Z,Y)
    INTEGER,OPTIONAL :: X
    INTEGER :: Z
    REAL :: Y
  END SUBROUTINE S8B
END INTERFACE BAD8


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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:
> 
Would you raise a PR for BAD8 please, Tobias?  It is quite separate from the
issue with CP2K but it is 'BAD' stuff!  I think that I know how to fix it but
it will have to be another day. 


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- 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 (if
any).


> Would you raise a PR for BAD8 please, Tobias?  It is quite separate from the
> issue with CP2K but it is 'BAD' stuff!  I think that I know how to fix it but
> it will have to be another day. 
Filled as PR30068, I realized it immediately after I hit "submit".


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[patchapp at dberlin dot org]

------- 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/show_bug.cgi?id=29975

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[patchapp at dberlin dot org]

------- 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/show_bug.cgi?id=29975

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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 <pault@gcc.gnu.org>

        PR fortran/29975
        PR fortran/30068
        PR fortran/30096
        * interface.c (compare_type_rank_if): Reject invalid generic
        interfaces.
        (check_interface1): Give a warning for nonreferred to ambiguous
        interfaces.
        (check_sym_interfaces): Check whether an ambiguous interface is
        referred to.  Do not check host associated interfaces since these
        cannot be ambiguous with the local versions.
        (check_uop_interface, gfc_check_interfaces): Update call to
        check_interface1.
        * symbol.c (gfc_get_sym_tree, gfc_get_sym_tree): Allow adding
        unambiguous procedures to generic interfaces.
        * gfortran.h (symbol_attribute): Added use_only and
        ambiguous_interfaces.
        * module.c (load_need): Set the use_only flag, if needed.
        * resolve.c (resolve_fl_procedure): Warn for nonreferred
        interfaces.
        * expr.c (find_array_section): Fix initializer array contructor.


2006-12-09  Paul Thomas <pault@gcc.gnu.org>
            Tobias Burnus <burnus@gcc.gnu.org>

        PR fortran/29975
        PR fortran/30068
        * gfortran.dg/interface_4.f90: Test adding procedure to generic
        interface.
        * gfortran.dg/interface_5.f90: Test warning for not-referenced-to
        ambiguous interfaces.
        * gfortran.dg/interface_6.f90: Test invalid, ambiguous interface.
        * gfortran.dg/interface_7.f90: Test invalid, ambiguous interface.
        * gfortran.dg/interface_8.f90: Test warning for not-referenced-to
        ambiguous interfaces.
        * gfortran.dg/interface_1.f90: Change dg-error into a dg-warning.
        * gfortran.dg/array_initializer_2.f90: Add initializer array
        constructor test.

        PR fortran/30096
        * gfortran.dg/interface_9.f90: Test that host interfaces are
        not checked for ambiguity with the local version.

Added:
    trunk/gcc/testsuite/gfortran.dg/interface_4.f90
    trunk/gcc/testsuite/gfortran.dg/interface_5.f90
    trunk/gcc/testsuite/gfortran.dg/interface_6.f90
    trunk/gcc/testsuite/gfortran.dg/interface_7.f90
    trunk/gcc/testsuite/gfortran.dg/interface_8.f90
    trunk/gcc/testsuite/gfortran.dg/interface_9.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/array_initializer_2.f90
    trunk/gcc/testsuite/gfortran.dg/generic_7.f90
    trunk/gcc/testsuite/gfortran.dg/interface_1.f90


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #29 from jv244 at cam dot ac dot uk  2006-12-10 20:08 -------
Created an attachment (id=12777)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12777&action=view)
CP2K input file that causes segfault

gcc version 4.3.0 20061210 (experimental) now compiles CP2K (tested on
opteron), but unfortunately all CP2K regtests segfault immediately. In order to
reproduce, compile the file from comment #1 and link to blas & lapack to get an
executable. Try './a.out H2O-1-GENPOT.inp' where the latter file is attached.
I'm getting the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000002a95af3f20 in _int_free () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x0000002a95af3f20 in _int_free () from /lib64/tls/libc.so.6
#1  0x0000002a95af4367 in free () from /lib64/tls/libc.so.6
#2  0x0000002a956e5ae4 in fd_close (s=Variable "s" is not available.
) at /scratch/vondele/gcc_trunk/gcc/libgfortran/io/unix.c:751
#3  0x0000002a956e480e in close_unit_1 (u=Variable "u" is not available.
) at /scratch/vondele/gcc_trunk/gcc/libgfortran/io/unit.c:593
#4  0x0000000000439628 in __cp_files__close_file (unit_number=@0x1d51bc8,
file_status=0x0, _file_status=0)
    at all_cp2k_gfortran.f90:7000
#5  0x000000000050aae7 in __cp_parser__parser_release (parser=@0x7fbfffbfa8,
error=@0x7fbfffe0f0)
    at all_cp2k_gfortran.f90:32731
#6  0x0000000000679988 in __input_cp2k__create_cp2k_input_reading
(file_path=@0x7fbfffef10, para_env=@0x7fbfffe788,
    error=@0x7fbfffe0f0, _file_path=80) at all_cp2k_gfortran.f90:87724
#7  0x000000000100fdb2 in __cp2k_runs__cp2k_run (input_file_name=@0x7fbfffef10,
output_unit=@0x7fbfffeabc,
    mpi_comm=@0x1934698, _input_file_name=80) at all_cp2k_gfortran.f90:412339
#8  0x000000000100d0b8 in __cp2k_runs__run_input
(input_file_path=@0x7fbfffef10, output_file_path=@0x7fbfffeec0,
    ierr=@0x7fbfffeffc, mpi_comm=0x0, _input_file_path=80,
_output_file_path=80) at all_cp2k_gfortran.f90:412970
#9  0x000000000103372f in MAIN__ () at all_cp2k_gfortran.f90:421842
#10 0x00000000016373ce in main (argc=Variable "argc" is not available.
) at /scratch/vondele/gcc_trunk/gcc/libgfortran/fmain.c:18


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #30 from jv244 at cam dot ac dot uk  2006-12-11 09:51 -------
(In reply to comment #29)

simple testcase for the segfault:

SUBROUTINE S(unit_number)
character(len=100) :: status_string
integer :: unit_number,istat
status_string="KEEP"
CLOSE (UNIT=unit_number,IOSTAT=istat,STATUS=TRIM(status_string))
END SUBROUTINE

INTEGER :: unit_number
unit_number=100
OPEN(unit_number)
CALL S(unit_number)
END


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- Comment #31 from burnus at gcc dot gnu dot org  2006-12-11 10:07 -------
> > gcc version 4.3.0 20061210 (experimental)
> simple testcase for the segfault:
I tried it with gfortran 4.3 and 4.2 (today's build) and an older 4.1 build and
neither crashes. valgrind also shows no error.

The original program gives here:
  **** **** ******  **  PROGRAM ENDED AT                     20061211
110945.641
i.e. it also seems to work.


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #32 from jv244 at cam dot ac dot uk  2006-12-11 11:29 -------
(In reply to comment #31)
> > > gcc version 4.3.0 20061210 (experimental)
> > simple testcase for the segfault:
> I tried it with gfortran 4.3 and 4.2 (today's build) and an older 4.1 build and
> neither crashes. valgrind also shows no error.


OK, latest svn and a build from scratch resolved that segfault. Could there be
something wrong with the gcc build system ?


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #33 from jv244 at cam dot ac dot uk  2006-12-11 11:54 -------
Running the CP2K regtests now results in:
number of FAILED  tests 24
(these are just the runs that do not complete, I have not checked that the runs
that finish also generate the right numbers. This can be reproduced using the 
do_regtest script mentioned in the initial description). Just for future
reference the current failures are:

     1 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-2/H2-vib.inp.out
     2 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-2/H2O-meta_res1.inp.out
     3 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-2/H2O-meta_res2.inp.out
     4 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-2/H2O-meta_res3.inp.out
     5 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-3/H2O-langevin-2.inp.out
     6 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/water_1_res_3.inp.out
     7 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/H2O-32_SPME_res_4.inp.out
     8 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/H2O-32_NPT_res_2.inp.out
     9 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/H2O-32_NPT_res_3.inp.out
    10 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/H2O-32_NPT_res_4.inp.out
    11 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/silicon_cluster_3.inp.out
    12 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/silicon_cluster_4.inp.out
    13 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/silicon_cluster_5.inp.out
    14 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/silicon_cluster_6.inp.out
    15 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-ot-1/H2O-OT-ASPC-6.inp.out
    16 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QMMM/QS/regtest-3/C4H10-qmmm-gauss-7.inp.out
    17 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/wat_freq.inp.out
    18 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/wat_freq_norot.inp.out
    19 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/wat_freq_freeze.inp.out
    20 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QMMM/QS/regtest-3/C4H10-qmmm-grid-8.inp.out
    21 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/EP/Ar-ep.inp.out
    22 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/EP/Ar2.inp.out
    23 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/EP/3H2O-ep.inp.out
    24 
/scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Pimd/h2o_pint.inp.out


Some of them seem to be caused by the same issue, but there is a number of
distinct problems.


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- Comment #34 from burnus at gcc dot gnu dot org  2006-12-11 15:56 -------
CP2k actually gives here an ICE with -O2 (PR 30147)
at least when I use ./do_regtest (otherwise I didn't saw it). I did not yet
look at why the calculation results are wrong.


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] 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: 799 bytes --]



------- Comment #35 from jv244 at cam dot ac dot uk  2006-12-11 16:08 -------
(In reply to comment #34)
> CP2k actually gives here an ICE with -O2 (PR 30147)
> at least when I use ./do_regtest (otherwise I didn't saw it). I did not yet
> look at why the calculation results are wrong.
> 

yes, I'm currently also getting this

gfortran -c -O3 -ftree-vectorize -ffast-math -march=opteron
input_cp2k_motion.f90
input_cp2k_motion.f90: In function ‘create_neb_section’:
input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at
fold-const.c:2150

in fact, this is on a file added to the CP2K CVS repo 2 days ago, so it is not
yet part of the gzip'ed file that I provided for the initial report. That one
compiles OK at -O2. 


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[pault at gcc dot gnu dot org]

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



------- Comment #36 from pault at gcc dot gnu dot org  2006-12-13 13:37 -------
Joost,

> input_cp2k_motion.f90
> input_cp2k_motion.f90: In function ‘create_neb_section’:
> input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at
> fold-const.c:2150
> 
> in fact, this is on a file added to the CP2K CVS repo 2 days ago, so it is not
> yet part of the gzip'ed file that I provided for the initial report. That one
> compiles OK at -O2. 


A reduced version of this one would be very nice - if I would guess, it will be
an assignment in which derived type is not being correctly associated. 
Apparently, I still do not have this entirely right.

BTW I am not sure that a meta-bug was necessarily the best way to handle this
series of problems.  I think that we should have spun off a PR for each bug
that we found.  This is my fault but I signal it for future reference.

Thanks for sticking with us on this one - we'll get there in the end.

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #37 from jv244 at cam dot ac dot uk  2006-12-13 14:01 -------
(In reply to comment #36)

well, this was reduced, filed as PR30147, and fixed. Tobias reduced another one
and filed it as PR30190 (see dependencies).


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- Comment #38 from burnus at gcc dot gnu dot org  2006-12-13 14:03 -------
Hi Paul,
(In reply to comment #36)
> > input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at
> 
> A reduced version of this one would be very nice - if I would guess, it will 
> be an assignment in which derived type is not being correctly associated. 
> Apparently, I still do not have this entirely right.

Test case see PR 30147. This is a now-fixed middle end bug.

A new problem is PR30190 (-fbounds-check creates wrong code with
associated(pointer,target).

I would suggest to close this bug as FIXED as soon as everything is checked in.
(I think 4.2 is still missing, and maybe [or not] 4.1).

The rest should be handled in different bugs, but one can still link to this
bug.


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #39 from jv244 at cam dot ac dot uk  2006-12-13 15:25 -------
I had a look at one of the failing testcases from CP2K testsuite, and under
valgrind there were a number of errors that could be reproduced in the small
testcase of PR30200


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #40 from jv244 at cam dot ac dot uk  2006-12-19 12:49 -------
I've now checked that gcc trunk (revision 120045) compiles CP2K (at -O3
-ftree-vectorize -ffast-math -march=opteron) and that the numerical results
seem acceptable. Great job... I hope the the original file is kept around so
that gfortran doesn't regress on this.

I've also checked the fortran-experiments branch to see how it performs on
CP2K's libint_interface.f90 (as preprocessed with -D__LIBINT), but it looks
like gfortran's  ISO_C_BINDING stuff is not yet ready. That file might be a
nice testcase as well (compiles with g95, but unfortunately fails on the
versions of xlf90 and NAG I have access to, because of unimplemented features)


-- 


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

[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- Comment #41 from pault at gcc dot gnu dot org  2006-12-21 15:05 -------
Subject: Bug 29975

Author: pault
Date: Thu Dec 21 15:05:24 2006
New Revision: 120113

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120113
Log:
2006-12-21  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/29975
        PR fortran/30068
        PR fortran/30096
        * interface.c (compare_type_rank_if): Reject invalid generic
        interfaces.
        (check_interface1): Give a warning for nonreferred to ambiguous
        interfaces.
        (check_sym_interfaces): Check whether an ambiguous interface is
        referred to.  Do not check host associated interfaces since these
        cannot be ambiguous with the local versions.
        (check_uop_interface, gfc_check_interfaces): Update call to
        check_interface1.
        * symbol.c (gfc_get_sym_tree, gfc_get_sym_tree): Allow adding
        unambiguous procedures to generic interfaces.
        * gfortran.h (symbol_attribute): Added use_only and
        ambiguous_interfaces.
        * module.c (load_need): Set the use_only flag, if needed.
        * resolve.c (resolve_fl_procedure): Warn for nonreferred
        interfaces.
        * expr.c (find_array_section): Fix initializer array contructor.


2006-12-21  Paul Thomas  <pault@gcc.gnu.org>
            Tobias Burnus  <burnus@gcc.gnu.org>

        PR fortran/29975
        PR fortran/30068
        * gfortran.dg/interface_4.f90: Test adding procedure to generic
        interface.
        * gfortran.dg/interface_5.f90: Test warning for not-referenced-to
        ambiguous interfaces.
        * gfortran.dg/interface_6.f90: Test invalid, ambiguous interface.
        * gfortran.dg/interface_7.f90: Test invalid, ambiguous interface.
        * gfortran.dg/interface_8.f90: Test warning for not-referenced-to
        ambiguous interfaces.
        * gfortran.dg/interface_1.f90: Change dg-error into a dg-warning.
        * gfortran.dg/array_initializer_2.f90: Add initializer array
        constructor test.

        PR fortran/30096
        * gfortran.dg/interface_9.f90: Test that host interfaces are
        not checked for ambiguity with the local version.


Added:
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_4.f90
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_5.f90
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_6.f90
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_7.f90
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_8.f90
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_9.f90
Modified:
    branches/gcc-4_2-branch/gcc/fortran/ChangeLog
    branches/gcc-4_2-branch/gcc/fortran/expr.c
    branches/gcc-4_2-branch/gcc/fortran/gfortran.h
    branches/gcc-4_2-branch/gcc/fortran/interface.c
    branches/gcc-4_2-branch/gcc/fortran/module.c
    branches/gcc-4_2-branch/gcc/fortran/resolve.c
    branches/gcc-4_2-branch/gcc/fortran/symbol.c
    branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_initializer_2.f90
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/generic_7.f90
    branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_1.f90


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- 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.cgi?id=29975

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[steven at gcc dot gnu dot org]

------- 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
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.3.0


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

[Bug fortran/29975] [meta-bugs] 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: 816 bytes --]



------- 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 error: in operand_equal_p, at
fold-const.c:2539
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pinskia at gcc dot gnu dot org]

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



------- 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 compiler error: in operand_equal_p, at
> fold-const.c:2539

I don't see how we can get an ICE here except for a tree checking error:
  /* If both types don't have the same signedness, then we can't consider
     them equal.  We must check this before the STRIP_NOPS calls
     because they may change the signedness of the arguments.  */
  if (TYPE_UNSIGNED (TREE_TYPE (arg0)) != TYPE_UNSIGNED (TREE_TYPE (arg1)))
    return 0;


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

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



------- 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 (also
yesterday's version) without any ICE. I also tried gfortran 4.3 20070102.

> 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 error: in operand_equal_p, at
> fold-const.c:2539

This is in my CP2k:
         box_length(1:3)=abc(1:3)
where
  REAL(KIND=dp), DIMENSION(1:3) :: abc, box_length

Can you try to find the minimal set of options which causes this bug?
e.g. -O0 no -ftree-vectorize -ffast-math, no -fopenmp etc.
What is your exact version of gfortran?

By the way, I think one should leave in future this PR closed and open new PR;
this PR is a wild mixure between a meta bug (5 dependend bugs, now fixed) and a
couple of rather independent bugs reported directly here.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|pault at gcc dot gnu dot org|unassigned at gcc dot gnu
                   |                            |dot org
             Status|REOPENED                    |NEW


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

------- 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 might
be responsible for it.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

this is a new regression. I really think CP2K should be added to some nightly
tester somewhere by gfortran developers...


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

------- 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 compiler error: Segmentation fault

It compiled fine two days ago (with the patch for PR30391), I tested it myself!
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 to confirm this, it'd be nice to send a mail to the list.

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


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paulthomas2 at wanadoo dot
                   |                            |fr
   Last reconfirmed|2007-01-21 16:34:55         |2007-02-12 16:16:29
               date|                            |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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).
> 
I agree that are two separate issues. One is to get it to work (and keep it
that way), and the other would be to monitor runtime performance. For the
latter issue I can prepare reasonable benchmark inputs, while for the former I
think it is good enough to just compile the tarbal from the initial comment.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 to confirm this, it'd be nice to send a mail to the list.

The line corresponding to the error message    is:

    IF (failure) NULLIFY(sll)


I don't know if this triggers something, looks like a simple statement.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pinskia at gcc dot gnu dot org]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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 at -O1 and above, the current ICE is at -O0
> 
Nonetheless, I do not see it being associated with my doo-doo in module.c, do
you?

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0 <compare_symtree>)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:137
137       *r = insert (n, *r, compare);
(gdb) bt
#0  gfc_insert_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0
<compare_symtree>)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:137
#1  0x0000000000459d34 in gfc_new_symtree (root=0x0, name=0x7fbfffe980
"@20233")
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:1909
#2  0x000000000043a44a in get_unique_symtree (ns=0x0)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:1775
#3  0x000000000043ca1a in read_cleanup (p=0x7c7f9f0)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3290
#4  0x000000000043c9db in read_cleanup (p=0x7922d50)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284
#5  0x000000000043c9db in read_cleanup (p=0x7a26300)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284
#6  0x000000000043c9db in read_cleanup (p=0x7c77ec0)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284
#7  0x000000000043c9db in read_cleanup (p=0x79dfbf0)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284
#8  0x000000000043c9db in read_cleanup (p=0x7af9f20)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284
#9  0x000000000043c9db in read_cleanup (p=0x7af2390)
    at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3284
#10 0x000000000043d10d in read_module () at
/scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:3563
#11 0x000000000043d555 in gfc_use_module () at
/scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:4164
#12 0x0000000000442b98 in accept_statement (st=Variable "st" is not available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:1255
#13 0x0000000000443625 in parse_spec (st=ST_USE) at
/scratch/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:1887
#14 0x0000000000444e9a in gfc_parse_file () at
/scratch/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:3063
#15 0x00000000004631ae in gfc_be_parse_file (set_yydebug=Variable "set_yydebug"
is not available.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

------- 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 <compare_symtree>)
>     at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:137
> 137       *r = insert (n, *r, compare);
> (gdb) bt
> #0  gfc_insert_bbt (root=0x0, new=0x7a23c80, compare=0x459ed0
> <compare_symtree>)
>     at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/bbt.c:137
> #1  0x0000000000459d34 in gfc_new_symtree (root=0x0, name=0x7fbfffe980
> "@20233")
>     at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:1909
> #2  0x000000000043a44a in get_unique_symtree (ns=0x0)
>     at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/module.c:1775

Yes, that's the one: http://gcc.gnu.org/ml/fortran/2007-02/msg00250.html


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-02-12 16:16:29         |2007-02-12 18:30:31
               date|                            |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 segfault would be wrong.
Trying to reduce the testcase further, my automatic script got stuck on what is
now PR 30779


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[paulthomas2 at wanadoo dot fr]

------- 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/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 segfault would be wrong.
> Trying to reduce the testcase further, my automatic script got stuck on what is
> now PR 30779
>
>
>   
OK Yours is one and the same as Daniel's.  The backtrace makes that 
completely clear.  The fix was posted to the list earlier on today. It 
is just now regtesting - I will commit it before I go to bed tonight.

Thanks for bearing with us.

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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, 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 segfault would be wrong.
> > Trying to reduce the testcase further, my automatic script got stuck on what is
> > now PR 30779
> >
> >
> >   
> OK Yours is one and the same as Daniel's.  The backtrace makes that 
> completely clear.  The fix was posted to the list earlier on today. It 
> is just now regtesting - I will commit it before I go to bed tonight.
> 
> Thanks for bearing with us.
> 
> Paul
> 

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

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 20:20
> hindsight:)
Yes, current trunk compiles CP2K again at -O0 (still blocked by PR 30391 at
-O1). No need to apologize, I realize that many of the change you make fall
into the 'subtle' category and do not pop-up with the normal regtesting. As
said before, I'm, unfortunately, used to the fact that even good commercial
compilers (say NAG's f95, IBM's xlf90, Intel's ifort) regress on CP2K from time
to time. It is very annoying to have to fight compilers, after the computer
center upgraded a machine. My hope is that CP2K being freely available (even in
a handy single file format, see initial comment) could prevent this from
happening. Ultimately, I want to see some runtime regression tester... maybe I
should try to get CP2K in a future version of SPEC ... any hints on how to do
that ??


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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 freely available (even in
> a handy single file format, see initial comment) could prevent this from
> happening.

I have been meaning to get ito into service, ever since you posted it.

Ultimately, I want to see some runtime regression tester... maybe I
> should try to get CP2K in a future version of SPEC ... any hints on how to do
> that ??

Apparently, you..... offer it.

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[kargl at gcc dot gnu dot org]

------- 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 error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> 
> this is a new regression. I really think CP2K should be added to some nightly
> tester somewhere by gfortran developers...

Well, I'd add it to my testsuite if weren't a PITA to figure out how to
make it build.

troutmask:sgk[246] tools/get_arch_code
###########################################################
have a look at cp2k/tools/get_arch_code
your system is a FreeBSD-FreeBSD 7.0-CURRENT #1: Fri Feb  9 12:01:52 PST 2007  
  root@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW
-7.0-CURRENT-amd64
but get_arch_code is not able to deal with that 
############################################################
unknown


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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_gfortran.f90


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jvdelisle at gcc dot gnu dot org]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 want to do the testing on a fixed version of CP2K,
i.e. that it is sure that any failure you might observe is due to a change in
the compiler, and not because we messed up CP2K (which also happens). You'll
certainly get the majority of regressions wrt CP2K this way. I also suggest
that this tarbal is kept available elsewhere, since it is on a tmp part of the
webserver.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jvdelisle at gcc dot gnu dot org]

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



------- 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 version 4.3.0 20070216 (experimental)

/home/jerry/cp2k/makefiles/../src/mc_coordinates.F: In function
‘check_for_overlap’:
/home/jerry/cp2k/makefiles/../src/mc_coordinates.F:137: internal compiler
error: in operand_equal_p, at fold-const.c:2717
Please submit a full bug report,


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

------- 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
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|ice-on-valid-code           |
         Resolution|                            |FIXED


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

[Bug fortran/29975] [meta-bugs] 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: 739 bytes --]



------- 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: In function ‘xas_env_init’:
all_cp2k_gfortran.f90:315153: internal compiler error: Segmentation fault


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug fortran/29975] [meta-bugs] 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: 602 bytes --]



------- 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 opteron.
> 
> all_cp2k_gfortran.f90: In function ‘xas_env_init’:
> all_cp2k_gfortran.f90:315153: internal compiler error: Segmentation fault
> 

compiling the offending module with 'gfortran -ftree-loop-linear -O2' is enough
to trigger the ICE


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[steven at gcc dot gnu dot org]

------- 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    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-02-12 18:30:31         |2007-02-17 16:01:22
               date|                            |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

This is now PR 30835


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 relevant machine_gfortran.F and arch files to the CP2K CVS, to
facilitate gfortran testing with CVS sources.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

------- 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 that, OpenMP being frequently broken on cp2k and gfortran being a free
compiler OpenMP-capable, you might have tried it :)


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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. So far I have had relatively little interest in
openmp, because the openmp bits in CP2K are really few, and really bad...
mainly because our focus is on massively parallel. However, things are changing
quickly on that front as well, and we'll soon have a 8 cpu x 2 core (AMD)
shared memory machine for experimenting a bit more seriously with this (among
other things). One issue with OpenMP is that it is very easy to break an OpenMP
code (it is just comments), unless you force all developers to always compile
the openmp version as well (or you add one more automatic tester). The other
thing is that some of the mistakes one can make with openmp easily (such as a
forgotten critical section) only trigger bugs from time to time, e.g. depending
on how threads are scheduled. Anyway, many excuses to say 'not really, but
maybe soon'...


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[steven at gcc dot gnu dot org]

------- 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 more difficult to break OpenMP-annotated Fortran code.  One think I've
been thinking about, is to make the parser always parse OpenMP directives, and
issue warnings if something doesn't look right but -fopenmp is not given.  Is
that something that would help avoid the most common cases of broken OpenMP
directives? Do you have some examples of common errors with OpenMP?


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-02-17 16:01:22         |2007-03-12 23:24:37
               date|                            |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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: Assembler messages:
/tmp/ccNk6D7G.s:820: Error: suffix or operands invalid for `sahf'
make[2]: *** [fparser.o] Error 1
make[2]: *** Waiting for unfinished jobs....
rm fftrot.f90 fftpre.f90 fft_lib.f90 mltfftsg_tools.f90 fftw2_lib.f90
fftacml_lib.f90 fftessl_lib.f90 mltfftsg.f90 ctrig.f90 fftmkl_lib.f90
fftsci_lib.f90 cp2k.f90 fftw3_lib.f90 fftsg_lib.f90 fftstp.f90
make[2]: Leaving directory
`/scratch/vondele/clean/cp2k/obj/Linux-x86-64-gfortran/sopt'
make[1]: *** [build] Error 2


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[ubizjak at gmail dot com]

------- 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 invalid for `sahf'

Strange, because sahf has _no_ suffix or operands:

(define_insn "x86_sahf_1"
  [(set (reg:CC FLAGS_REG)
        (unspec:CC [(match_operand:HI 0 "register_operand" "a")]
                   UNSPEC_SAHF))]
  "TARGET_SAHF"
  "sahf"
  [(set_attr "length" "1")
   (set_attr "athlon_decode" "vector")
   (set_attr "amdfam10_decode" "direct")
   (set_attr "mode" "SI")])

And double strange, because athlon should not generate sahf, as it is not in
TARGET_USE_SAHF group of processors.

Could you post the temporary asm (only lines around line 820 will be enough) to
check what is going wrong?


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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    %rdx, %rax
        movlpd  (%rbx,%rax,8), %xmm2
        cvttsd2si       %xmm2, %edi
        cvtsi2sd        %edi, %xmm1
        comisd  %xmm1, %xmm2
        jae     .L117
        decl    %edi
        cvtsi2sd        %edi, %xmm1
.L117:
        movsd   %xmm2, (%rsp)
        fldl    (%rsp)
        movsd   %xmm1, (%rsp)
        fldl    (%rsp)
        fxch    %st(1)
.L120:
        fprem
        fnstsw  %ax
        sahf
        jp      .L120
        fstp    %st(1)
        xorpd   %xmm2, %xmm2
        fstpl   24(%rsp)
        movlpd  24(%rsp), %xmm1
        comisd  %xmm2, %xmm1
        jne     .L146
        call    _gfortran_pow_r8_i4
        movsd   %xmm0, (%rbx,%r12,8)
        jmp     .L123
.L146:
        xorl    %edx, %edx
        movl    $60, %r8d
        movl    $5, %ecx
        movl    $.LC7, %esi
        movl    $.LC8, %edi
        call    __termination__stop_program_old
        movq    32(%rsp), %rax
        movq    __fparser__comp+8(%rip), %rdx
        movq    __fparser__comp(%rip), %rbp
        movq    __fparser__comp+24(%rip), %r15
        movl    (%rax), %eax
        movq    %rdx, 8(%rsp)
        movl    %eax, 20(%rsp)
        jmp     .L123


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[burnus at gcc dot gnu dot org]

------- 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 difficult to break OpenMP-annotated Fortran code.

I think the biggest problem is that OpenMP goes out of sync with the serial
code. (Though MPI is much, much worser in this regard.) For MPI it is simply to
forget to update the different code paths. For OpenMP, it is presumably the
condiditional compilation part and forgetting to put critical
sections/barriers.

> One think I've been thinking about, is to make the parser always parse OpenMP
> directives, and issue warnings if something doesn't look right but
> -fopenmp is not given. Is that something that would help avoid the most
> common cases of broken OpenMP directives?

I think this will help (as it at least forces the lexical correctness of the
OpenMP statements), but algorithmic problems (missing barriers/critical
sections, conditional compilation parts) can unfortunately not be found this
way ; using -fopenmp will find some more kind of problems (esp. in conditional
parts), but will not find those algorithmic problems neither.


(In reply to comment #77)
> 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: Assembler messages:
> /tmp/ccNk6D7G.s:820: Error: suffix or operands invalid for `sahf'

Does not seem to happen (20070314 on x86-64 Linux) with current CVS version of
CP2k.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[ubizjak at gmail dot com]

------- 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
>         jp      .L120
>         fstp    %st(1)

This is correct asm for MOD [fmod] function.

> And double strange, because athlon should not generate sahf, as it is not in
> TARGET_USE_SAHF group of processors.

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.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 the code to compile again. Unfortunately, with the (nice!) option
-march=native, this issue also re-appears. From a user point of view it would
be nice to have gcc detect the version of binutils installed (BTW, the
requirements on the web pages still mention binutils 2.13, which might be
correct for 4.0 but would need updating ?)


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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.
0x0000000000afa307 in __qs_resp__resp_fit ()

objdump -d gives me

  afa2e1:       f2 0f 11 84 24 68 02    movsd  %xmm0,0x268(%rsp)
  afa2e8:       00 00
  afa2ea:       dd 84 24 68 02 00 00    fldl   0x268(%rsp)
  afa2f1:       f2 0f 11 8c 24 68 02    movsd  %xmm1,0x268(%rsp)
  afa2f8:       00 00
  afa2fa:       dd 84 24 68 02 00 00    fldl   0x268(%rsp)
  afa301:       d9 c9                   fxch   %st(1)
  afa303:       d9 f8                   fprem
  afa305:       df e0                   fnstsw %ax
  afa307:       9e                      (bad)
  afa308:       7a f9                   jp     afa303
<__qs_resp__resp_fit+0x1383>
  afa30a:       dd d9                   fstp   %st(1)
  afa30c:       dd 9c 24 68 02 00 00    fstpl  0x268(%rsp)
  afa313:       66 0f 12 ac 24 68 02    movlpd 0x268(%rsp),%xmm5
  afa31a:       00 00
  afa31c:       66 0f 2f ef             comisd %xmm7,%xmm5
  afa320:       0f 95 c1                setne  %cl
  afa323:       66 0f 2f c7             comisd %xmm7,%xmm0
  afa327:       0f 92 c2                setb   %dl
  afa32a:       66 0f 2f cf             comisd %xmm7,%xmm1
  afa32e:       0f 92 c0                setb   %al
  afa331:       31 d0                   xor    %edx,%eax

/proc/cpuinfo is:

vendor_id       : AuthenticAMD
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 840
stepping        : 8


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[ubizjak at gmail dot com]

------- 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.
> 0x0000000000afa307 in __qs_resp__resp_fit ()

> vendor_id       : AuthenticAMD
> cpu family      : 15
> model           : 5
> model name      : AMD Opteron(tm) Processor 840
> stepping        : 8

Could you post your cpuflags? There should be lahf_lm flag present for
opterons.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 acpi mmx fxsr sse sse2 ss ht tm syscall nx lm
constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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
flags and no (lahf_lm):
cpu family      : 15
model           : 5
model name      : AMD Opteron(tm) Processor 840
stepping        : 8
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[ubizjak at gmail dot com]

------- 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
> stepping        : 8
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow

I was just writting the reply about wrong AMD errata 110 workaround. Please
wait a couple of minutes, I'll switch descriptions of all AMD processors to
default to NO_SAHF.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[ubizjak at gmail dot com]

------- 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.
> 0x0000000000afa307 in __qs_resp__resp_fit ()
> 
> objdump -d gives me

>   afa305:       df e0                   fnstsw %ax
>   afa307:       9e                      (bad)
>   afa308:       7a f9                   jp     afa303

The above (bad) opcode is harmless bug in objdump.

The code generation should be fixed by
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01108.html. The issue with older
binutils is also fixed by a couple of previous patches.

Thanks for your reports!


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

------- 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
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 code runs
fine with other compilers and gfortran if compiled with '-O0 -g -Wall -Wextra'.
Also, crashes are in several unrelated locations, so it seems something that
might be easy to trigger. Failing testcases include:
 /QS/regtest-gpw-1/Ar.inp.out
/QS/regtest-gpw-1/NO2_lsd.inp.out
/QS/regtest-gpw-1/H2O-harris.inp.out
/QS/regtest-gapw/H2O-gapw-gth.inp.out
/QS/regtest-gpw-1/H2O-MD-harris.inp.out
/QS/regtest-gapw/H2O-gapw-all.inp.out
/QS/regtest-gapw/H2O-gapwxc-gth.inp.out
/QS/regtest-gapw/H2S-gapw.inp.out
/QS/regtest-gapw/HF_gapw_all_LB.inp.out
/QS/regtest-gapw/OF_gapw_all_lsd_LB.inp.out
/QS/regtest-gapw/H-gapw-all.inp.out
/QS/regtest-gapw/He2-all.inp.out
/QS/regtest-gpw-1/H2O-Harris-Debug-SCF.inp.out
/QS/regtest-gpw-3/H+.inp.out :
/QS/regtest-gapw/He2-all-md.inp.out
/QS/regtest-gapw/CO.inp.out
/QS/regtest-gapw/CO_xastphh.inp.out
/QS/regtest-gapw/CO_xastpfh.inp.out
/QS/regtest-gapw/CO_xastpxhh.inp.out
/QS/regtest-gapw/CO_xastpxfh.inp.out
/QS/regtest-gapw/CO_xastpval.inp.out
/QS/regtest-gapw/Li-ROKS.inp.out
I'll see if I can reduce the number of optimization options.


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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. Valgrind reports:

==5839==
==5839== Invalid read of size 4
==5839==    at 0x433696: __ai_overlap_new_MOD_overlap (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x9BB779:
__qs_core_hamiltonian_MOD_build_core_hamiltonian_matrix (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x9E8834: __qs_energy_MOD_qs_energies (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x9FFE33: __qs_force_MOD_qs_forces (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x606294: __force_env_methods_MOD_force_env_calc_energy_force
(in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x4B8788: __cp2k_runs_MOD_cp2k_run (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x4B97BB: __cp2k_runs_MOD_run_input (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0xD3658A: MAIN__ (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0xE6291B: main (fmain.c:22)
==5839==  Address 0x1C04DD48 is not stack'd, malloc'd or (recently) free'd
==5839==
==5839== Process terminating with default action of signal 11 (SIGSEGV)
==5839==  Access not within mapped region at address 0x1C04DD48
==5839==    at 0x433696: __ai_overlap_new_MOD_overlap (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x9BB779:
__qs_core_hamiltonian_MOD_build_core_hamiltonian_matrix (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x9E8834: __qs_energy_MOD_qs_energies (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x9FFE33: __qs_force_MOD_qs_forces (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x606294: __force_env_methods_MOD_force_env_calc_energy_force
(in /scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x4B8788: __cp2k_runs_MOD_cp2k_run (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0x4B97BB: __cp2k_runs_MOD_run_input (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k.sopt)
==5839==    by 0xD3658A: MAIN__ (in
/scratch/vondele/clean/cp2k/exe/Linux-x86-64-gfortran/cp2k

but I'm not sure that this is really indicative of the location that gets
miscompiled.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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_core_hamiltonian.F with -O0 the codes
passes the point where it segfaulted (to finite a new location to segfault).


-- 


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

[Bug fortran/29975] [meta-bugs] 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: 1166 bytes --]



------- 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 function ‘overlap’:
ai_overlap_new.f90:60: warning: ‘offset.8’ may be used uninitialized in this
function
ai_overlap_new.f90:60: warning: ‘stride.7’ may be used uninitialized in this
function
ai_overlap_new.f90:60: warning: ‘stride.5’ may be used uninitialized in this
function
ai_overlap_new.f90:60: warning: ‘pab.0’ may be used uninitialized in this
function
ai_overlap_new.f90:60: warning: ‘offset.16’ may be used uninitialized in this
function
ai_overlap_new.f90:60: warning: ‘stride.15’ may be used uninitialized in this
function
ai_overlap_new.f90:60: warning: ‘stride.13’ may be used uninitialized in this
function
ai_overlap_new.f90:60: warning: ‘stride.11’ may be used uninitialized in this
function
ai_overlap_new.f90:60: warning: ‘sdab.0’ may be used uninitialized in this
function


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/29975] [meta-bugs] 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: 1015 bytes --]



------- 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
/scratch/vondele/clean/cp2k/src/../src/semi_empirical_int_ana.F: In function
‘dterep_ana’:
/scratch/vondele/clean/cp2k/src/../src/semi_empirical_int_ana.F:2319: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [semi_empirical_int_ana.o] Error 1


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[dfranke at gcc dot gnu dot org]

------- 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                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 segfault you've observed is actually in a
different subroutine (file) than what I reported above (based on a run on an
opteron). The file you've extracted compiles fine here. It could still be the
same issue though.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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. 
> 
> Looking at PR32018, I notice that the segfault you've observed is actually in a
> different subroutine (file) than what I reported above (based on a run on an
> opteron). The file you've extracted compiles fine here. It could still be the
> same issue though.
> 


might be a different issue, the trace I see here is :
(gdb) run -O3 -ftree-vectorize -ffast-math -march=opteron
semi_empirical_int_ana.f90
Starting program:
/scratch/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951
-O3 -ftree-vectorize -ffast-math -march=opteron semi_empirical_int_ana.f90
 check_dterep_ana dterep_ana rotint_ana {GC 8106k -> 5800k} dtaper_ana
dnucint_ana check_dnucint_ana invert_derivative invert_integral rotnuc_ana {GC
8112k -> 7433k}
Analyzing compilation unit
 {GC 10372k -> 9175k}Performing interprocedural optimizations
 <visibility> <early_local_cleanups> {GC 14010k -> 13275k} <inline>
<static-var> <pure-const> <type-escape-var>Assembling functions:
 dtaper_ana invert_integral invert_derivative check_dnucint_ana dnucint_ana {GC
17386k -> 12699k} rotnuc_ana {GC 16571k -> 13382k} dterep_ana {GC 17536k ->
11295k}
Program received signal SIGSEGV, Segmentation fault.
verify_ssa_name (ssa_name=0xa5a5a5a5a5a5a5a5, is_virtual=0 '\0') at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:109
109       if (TREE_CODE (ssa_name) != SSA_NAME)
(gdb) bt
#0  verify_ssa_name (ssa_name=0xa5a5a5a5a5a5a5a5, is_virtual=0 '\0') at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:109
#1  0x0000000000784305 in verify_ssa (check_modified_stmt=1 '\001') at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:716
#2  0x00000000006082d5 in execute_function_todo (data=Variable "data" is not
available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:918
#3  0x000000000060803b in execute_todo (flags=Variable "flags" is not
available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:942
#4  0x000000000060851a in execute_one_pass (pass=0xcc4b80) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1087
#5  0x000000000060867c in execute_pass_list (pass=0xcc4b80) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1117
#6  0x000000000060868e in execute_pass_list (pass=0xcc4160) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1118
#7  0x000000000060868e in execute_pass_list (pass=0xcc3fe0) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1118
#8  0x000000000060868e in execute_pass_list (pass=0xcc3440) at
/scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1118
#9  0x00000000006d2378 in tree_rest_of_compilation (fndecl=0x2a95b3ca00) at
/scratch/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:406
#10 0x000000000080ff50 in cgraph_expand_function (node=0x2a95c34700) at
/scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1086
#11 0x00000000008123f2 in cgraph_optimize () at
/scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1155
#12 0x0000000000465ebd in gfc_be_parse_file (set_yydebug=Variable "set_yydebug"
is not available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:307
#13 0x00000000006818e4 in toplev_main (argc=Variable "argc" is not available.
) at /scratch/vondele/gcc_trunk/gcc/gcc/toplev.c:1051


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 -march=nocona or -mtune=generic


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 -march=nocona or -mtune=generic


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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/bugzilla/show_bug.cgi?id=29975

[Bug fortran/29975] [meta-bugs] 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: 509 bytes --]



------- 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_value, at tree.c:7720
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[tbm at cyrius dot com]

------- 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 #100.  This got fixed, see PR32231.  Can you please
test whether your testcase works now?


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 traceback as
> what you posted in comment #100.  This got fixed, see PR32231.  Can you please
> test whether your testcase works now?
> 
Great... the bug reported in comment #100 is indeed fixed after the fix for
PR32231. I actually had problems to reproduce the problem, the '--param
ggc-min-expand=0 --param ggc-min-heapsize=0' is a useful trick though.


-- 


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

[Bug fortran/29975] [meta-bugs] 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: 570 bytes --]



------- 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:3776: internal compiler
error: in gfc_conv_variable, at fortran/trans-expr.c:386
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] 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: 758 bytes --]



------- 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:3820: warning: Function
return value not set
/scratch/vondele/clean/cp2k/src/../src/pw_types.F: In function
‘fft_wrap_pw1pw2’:
/scratch/vondele/clean/cp2k/src/../src/pw_types.F:2647: internal compiler
error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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/bugzilla/show_bug.cgi?id=29975

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 version of CP2K,
together with two benchmarks and a little script to run and test them as:

http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz

The timings of the benchmarks (against ifort 9.1 '-O1 -xT' on intel core2 duo)
are

gfortran:
> ./do_all
BENCH01 IS OK
BENCH01 WALL TIME [s] 267.27
BENCH02 IS OK
BENCH02 WALL TIME [s] 86.77

intel:
> ./do_all
BENCH01 IS OK
BENCH01 WALL TIME [s] 231.78
BENCH02 IS OK
BENCH02 WALL TIME [s] 77.84

this seems quite good (despite being 10-15% slower). 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).

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'. This happens on an opteron
with 16Gb of RAM while compilation with e.g. '-O1' or '-O3' goes fine. Watching
top, the maximum virtual memory is about 3Gb (and somewhat more than 2Gb at
-O3).


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 good (despite being 10-15% slower)
> 
> Indeed, this is not so bad. Do you use external libraries?

yes, linked against lapack/blas (gotoblas and mkl respectively), but the input
is tuned so that this is a negligable fraction of the total time.

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

No, I haven't made a testcase for this, this takes a lot of time.

> > with an out of memory error at '-O1 -fbounds-check'.
> 
> Yup, -fbounds-check for code with lots of array access has a high cost, 

single file package, but see PR 32439 for details.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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/bugzilla/show_bug.cgi?id=29975

[Bug fortran/29975] [meta-bugs] 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: 1051 bytes --]



------- Comment #116 from jv244 at cam dot ac dot uk  2007-06-22 05:56 -------
There is currently a new ICE

vondele@pcihopt1:/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_stat, at tree.c:3074
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
vondele@pcihopt1:/scratch/vondele/gcc_test/gfortran/test/src> gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /scratch/vondele/gcc_trunk/gcc/configure
--prefix=/scratch/vondele/gcc_trunk/build
--with-mpfr_include=/scratch/vondele/mpfr-2.2.0/
--with-mpfr_lib=/scratch/vondele/mpfr-2.2.0/ --with-gmp=/users/vondele/
--enable-languages=c,fortran
Thread model: posix
gcc version 4.3.0 20070620 (experimental)

but the compiler is now two days old, so I'll check if it is reproducable by
something more recent.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pinskia at gcc dot gnu dot org]

------- 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 Japan
has kept me from testing the patch).


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 already too (though the trip to Japan
> has kept me from testing the patch).
> 

yes still happening, now PR 32459


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

whereas one gets

Total energy:                                             -127.642599

This is a very large difference beyond numerics. The miscompilation is
triggered by:

# BUG
FCFLAGS  = -O3 -ffast-math -ftree-vectorize -march=native

but not

# OK
FCFLAGS  = -O3 -ffast-math -march=native
# OK
FCFLAGS  = -O3 -funroll-loops -ftree-vectorize -march=native

I might try to find out which module gets miscompiled, but this could be a bit
of a slow process.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pinskia at gmail dot com]

------- 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 -0000, jv244 at cam dot ac dot uk
<gcc-bugzilla@gcc.gnu.org> wrote:
> # BUG
> FCFLAGS  = -O3 -ffast-math -ftree-vectorize -march=native
So -ffast-math with vectorizer changes the results.

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 begin with, it might be
the case this is just a percussion issue.

-- Pinski


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 dependencies, so I don't think I will get a reduced testcase for this.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 begin with, it might be
> the case this is just a percussion issue.

I don't think there is code in the module mentioned before that would be
sensitive to changes in the way reductions are done. It is likely something
else.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 qs_neighbor_lists. It is a module with
> lots of dependencies, so I don't think I will get a reduced testcase for this.
Compiling that module under valgrind gives an error:

valgrind --tool=memcheck
/data03/vondele/gcc_4_2_0/build/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951
qs_neighbor_lists.f90 -march=k8 -mtune=k8 -quiet -dumpbase
qs_neighbor_lists.f90 -auxbase qs_neighbor_lists -O3 -version -ffast-math
-ftree-vectorize -ftree-vectorizer-verbose=1 -I
/data03/vondele/gcc_4_2_0/build/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude
-o /tmp/ccoFFIrV.s


==30523== Conditional jump or move depends on uninitialised value(s)
==30523==    at 0x706E08: vrp_evaluate_conditional_warnv (tree-vrp.c:4186)
==30523==    by 0x706F9C: vrp_evaluate_conditional (tree-vrp.c:4318)
==30523==    by 0x4B6E9F: substitute_and_fold (tree-ssa-propagate.c:1053)
==30523==    by 0x700F04: execute_vrp (tree-vrp.c:5318)
==30523==    by 0x6F9F27: execute_one_pass (passes.c:881)
==30523==    by 0x6FA08B: execute_pass_list (passes.c:932)
==30523==    by 0x6FA09D: execute_pass_list (passes.c:933)
==30523==    by 0x48CCCD: tree_rest_of_compilation (tree-optimize.c:463)
==30523==    by 0x742363: cgraph_expand_function (cgraphunit.c:1244)
==30523==    by 0x742C8D: cgraph_optimize (cgraphunit.c:1309)
==30523==    by 0x4633DC: gfc_be_parse_file (f95-lang.c:307)
==30523==    by 0x6DBF92: toplev_main (toplev.c:1033)

also, I checked all vectorized loops in the code path that gets executed for
the testcase, and there is only one trivial one (zeroing a freshly allocated
array).    Rewriting that bit so that it doesn't get vectorized still somehow
triggers the bug. 


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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_bug.cgi?id=29975

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 miscompiled (i.e.
same wrong answers obtained from 4.2_branch). The fact that the miscompilation
is now completely silent makes it a bit harder to find I'm afraid.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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_neighbor_lists module is still miscompiled (i.e.
> same wrong answers obtained from 4.2_branch). The fact that the miscompilation
> is now completely silent makes it a bit harder to find I'm afraid.
> 

serious looking miscompilation added with a small testcase as PR 32533


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 introduced. -O1 is
Ok.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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.2.0, but I'm not sure when it was introduced. -O1 is
> Ok.

miscompiled subroutine is mulliken_restraint


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[ubizjak at gmail dot com]

------- 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 4.2.0, but I'm not sure when it was introduced. -O1 is
> > Ok.
> 
> miscompiled subroutine is mulliken_restraint

Could you use bisection to isolate the patch that introduced regression?


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 as PR 32604



-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 'sort' referenced at (1) not found in module 'util'
[...]

Tue Jul 10 06:45:07 UTC 2007 (revision 126510)


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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  0x00c67e4a in __topology_util_MOD_topology_set_atm_mass ()
#1  0x00c14fb0 in __topology_MOD_connectivity_control ()
#2  0x00c158cc in __topology_MOD_topology_control ()
#3  0x009e3709 in __qs_environment_MOD_qs_init ()
#4  0x00abd19d in __qs_main_MOD_quickstep_create_force_env ()
#5  0x00597029 in __f77_interface_MOD_create_force_env ()
#6  0x004b0b5f in __cp2k_runs_MOD_cp2k_run ()
#7  0x004b2652 in __cp2k_runs_MOD_run_input ()
#8  0x004abc51 in MAIN__ ()
#9  0x00de593e in main (argc=14571838, argv=0x2)
    at ../../../trunk/libgfortran/fmain.c:22

Cheers

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 -ffast-math -ftree-vectorize -march=native"'. I'll
start a new test with current trunk. The crash could of course be arch/option
sensitive.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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 -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 past experiences.

Cheers

Paul


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 past experiences.

I tried (on an opteron):
-m32 -O3 -ffast-math -march=pentium4
-m32 -O3 -ffast-math -march=nocona
(any other suggestion ?) but couldn't get a crash.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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 naive but
wrong.

I fixed it this morning and verified that CP2K is OK.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/29975] [meta-bugs] 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: 858 bytes --]



------- 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.F:297: internal
compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[pault at gcc dot gnu dot org]

------- 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/bugzilla/show_bug.cgi?id=29975

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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 that the open dependency PR32580 can be tackled with high
priority in 4.4 (also because it is a prerequisite to call the iso_c_binding
'complete').


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[fxcoudert at gcc dot gnu dot org]

------- 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
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- 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
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[kargl at gcc dot gnu dot org]

------- 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, for the occasional regression that cp2k finds,
it seems rather arrogant to re-open this bug report.  Particularly, 
since you failed to close the re-opened report last time.


-- 


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

[Bug fortran/29975] [meta-bugs] ICEs with CP2K

[jvdelisle at gcc dot gnu dot org]

------- 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, please just open the new PR.

Thanks for the reports.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|36119                       |
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug other/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

------- Comment #154 from jv244 at cam dot ac dot uk  2008-05-05 10:31 -------
this PR remains meaningful, but indeed the component should be changed to
'other'


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |other


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