Bug 29975

Summary: [meta-bugs] ICEs with CP2K
Product: gcc Reporter: Joost VandeVondele <Joost.VandeVondele>
Component: otherAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: burnus, christian.joensson, dfranke, fxcoudert, gcc-bugs, irar, nicolasbock, P.Schaffnit, paulthomas2, pinskia, tkoenig
Priority: P3 Keywords: meta-bug
Version: 4.3.0   
Target Milestone: 4.3.0   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2007-03-12 23:24:37
Bug Depends on: 29976, 30147, 30190, 30200, 30238, 30391, 30817, 30835, 31683, 32018, 32096, 32140, 32176, 32242, 32248, 32310, 32417, 32439, 32450, 32459, 32514, 32521, 32533, 32580, 32604, 32633, 32727, 34335, 34946, 36037, 36071, 36129, 36131, 36132, 36198, 36265, 37174, 37223, 37251, 37300    
Bug Blocks:    
Attachments: This patch fixes the testcase of #6 and regtests on Cygwin_NT/PIV
test case for interface "bl_copy"
This fixes the INTERFACE part of the problem.
A further development of the patch
CP2K input file that causes segfault

Description Joost VandeVondele 2006-11-25 12:19:35 UTC
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).
Comment 1 Francois-Xavier Coudert 2006-11-25 13:22:11 UTC
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?
Comment 2 Joost VandeVondele 2006-11-25 14:15:49 UTC
(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)




Comment 3 Paul Thomas 2006-11-27 22:21:35 UTC
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!
Comment 4 Francois-Xavier Coudert 2006-11-27 22:24:42 UTC
(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.
Comment 5 Joost VandeVondele 2006-11-28 15:36:12 UTC
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
Comment 6 Tobias Burnus 2006-11-28 18:04:01 UTC
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
Comment 7 Paul Thomas 2006-11-29 22:15:46 UTC
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
Comment 8 Joost VandeVondele 2006-11-29 22:26:00 UTC
(In reply to comment #7)
> Joost,
> 
> Do you happen to know at what revision things went bad?
I'm afraid I don't...
Comment 9 Tobias Burnus 2006-11-30 07:36:54 UTC
(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
Comment 10 Paul Thomas 2006-12-01 13:16:33 UTC
Created attachment 12722 [details]
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!
Comment 11 Tobias Burnus 2006-12-01 17:20:12 UTC
Created attachment 12724 [details]
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
Comment 12 Joost VandeVondele 2006-12-02 13:37:21 UTC
> 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.
Comment 13 Joost VandeVondele 2006-12-02 13:55:32 UTC
(In reply to comment #11)
> Created an attachment (id=12724) [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 ...
Comment 14 Joost VandeVondele 2006-12-02 14:00:14 UTC
> 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.

Comment 15 Paul Thomas 2006-12-02 17:50:30 UTC
> 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
Comment 16 Paul Thomas 2006-12-03 13:38:38 UTC
Created attachment 12730 [details]
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
Comment 17 Tobias Burnus 2006-12-03 14:44:45 UTC
> 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)
Comment 18 Paul Thomas 2006-12-03 17:42:02 UTC
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

Comment 19 Paul Thomas 2006-12-03 19:41:37 UTC
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
Comment 20 Paul Thomas 2006-12-03 21:01:52 UTC
Created attachment 12733 [details]
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
Comment 21 Tobias Burnus 2006-12-03 21:50:45 UTC
> 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.)
Comment 22 Tobias Burnus 2006-12-03 22:07:36 UTC
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).
Comment 23 Tobias Burnus 2006-12-03 22:49:19 UTC
(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
Comment 24 Paul Thomas 2006-12-04 20:55:56 UTC
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. 
Comment 25 Tobias Burnus 2006-12-04 21:15:15 UTC
> 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".
Comment 26 patchapp@dberlin.org 2006-12-05 19:15:18 UTC
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
Comment 27 patchapp@dberlin.org 2006-12-08 19:50:25 UTC
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
Comment 28 Paul Thomas 2006-12-09 21:13:47 UTC
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

Comment 29 Joost VandeVondele 2006-12-10 20:08:34 UTC
Created attachment 12777 [details]
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
Comment 30 Joost VandeVondele 2006-12-11 09:51:38 UTC
(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
Comment 31 Tobias Burnus 2006-12-11 10:07:50 UTC
> > 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.
Comment 32 Joost VandeVondele 2006-12-11 11:29:05 UTC
(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 ?
Comment 33 Joost VandeVondele 2006-12-11 11:54:31 UTC
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.
Comment 34 Tobias Burnus 2006-12-11 15:56:35 UTC
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.
Comment 35 Joost VandeVondele 2006-12-11 16:08:21 UTC
(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. 
Comment 36 Paul Thomas 2006-12-13 13:37:53 UTC
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
Comment 37 Joost VandeVondele 2006-12-13 14:01:00 UTC
(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).

Comment 38 Tobias Burnus 2006-12-13 14:03:34 UTC
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.
Comment 39 Joost VandeVondele 2006-12-13 15:25:55 UTC
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
Comment 40 Joost VandeVondele 2006-12-19 12:49:44 UTC
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)
Comment 41 Paul Thomas 2006-12-21 15:05:52 UTC
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

Comment 42 Tobias Burnus 2006-12-21 16:09:02 UTC
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.
Comment 43 Steven Bosscher 2006-12-23 14:51:15 UTC
Fixed in GCC 4.3.0
Comment 44 Joost VandeVondele 2007-01-06 06:30:41 UTC
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.
Comment 45 Andrew Pinski 2007-01-06 06:41:36 UTC
(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;
Comment 46 Tobias Burnus 2007-01-06 09:22:00 UTC
(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.
Comment 47 Francois-Xavier Coudert 2007-01-06 10:43:10 UTC
(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.
Comment 48 Joost VandeVondele 2007-02-12 15:56:24 UTC
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...
Comment 49 Francois-Xavier Coudert 2007-02-12 16:16:28 UTC
(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).
Comment 50 Joost VandeVondele 2007-02-12 17:09:28 UTC
> > 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.
Comment 51 Joost VandeVondele 2007-02-12 17:12:38 UTC
> 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.
Comment 52 Andrew Pinski 2007-02-12 17:20:01 UTC
> I don't know if this triggers something, looks like a simple statement.

Yes that triggers my memory of PR 30391.
Comment 53 Joost VandeVondele 2007-02-12 17:52:16 UTC
(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

Comment 54 Paul Thomas 2007-02-12 18:02:06 UTC
(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
Comment 55 Joost VandeVondele 2007-02-12 18:26:13 UTC
> 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.

Comment 56 Francois-Xavier Coudert 2007-02-12 18:30:31 UTC
(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
Comment 57 Joost VandeVondele 2007-02-12 19:18:00 UTC
 
> 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
Comment 58 Paul Thomas 2007-02-12 22:55:48 UTC
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



Comment 59 Paul Thomas 2007-02-13 06:56:20 UTC
(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
Comment 60 Joost VandeVondele 2007-02-13 09:20:12 UTC
> 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 ??
Comment 61 Paul Thomas 2007-02-13 13:51:45 UTC
(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

Comment 62 kargl 2007-02-13 19:50:49 UTC
(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


Comment 63 Joost VandeVondele 2007-02-13 20:04:09 UTC
> 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
Comment 64 Jerry DeLisle 2007-02-16 02:50:47 UTC
I now have a machine at home here running i686-pc-gnu-linux that I plan to set up daily compile test on.  Joost, does that link in coment #63 get updated daily?
Comment 65 Joost VandeVondele 2007-02-16 05:57:36 UTC
(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.
Comment 66 Jerry DeLisle 2007-02-16 06:33:50 UTC
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,
Comment 67 Francois-Xavier Coudert 2007-02-16 06:50:55 UTC
PR 30391 is fixed with rev. 122030, so we should close this PR. Please reopen if we regress.
Comment 68 Joost VandeVondele 2007-02-17 07:50:42 UTC
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

Comment 69 Joost VandeVondele 2007-02-17 09:17:18 UTC
(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
Comment 70 Steven Bosscher 2007-02-17 16:01:22 UTC
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.
Comment 71 Joost VandeVondele 2007-02-17 16:17:12 UTC
(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
Comment 72 Joost VandeVondele 2007-02-19 19:51:49 UTC
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.
Comment 73 Joost VandeVondele 2007-03-02 08:41:52 UTC
I've added PR 31021 to track some performance issue with gfortran on one of CP2K's kernels.
Comment 74 Francois-Xavier Coudert 2007-03-03 08:52:50 UTC
(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 :)
Comment 75 Joost VandeVondele 2007-03-03 10:12:31 UTC
> 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'...
Comment 76 Steven Bosscher 2007-03-12 23:24:37 UTC
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?

Comment 77 Joost VandeVondele 2007-03-14 14:48:41 UTC
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
Comment 78 Uroš Bizjak 2007-03-14 15:01:05 UTC
(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?
Comment 79 Joost VandeVondele 2007-03-14 15:14:09 UTC
(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
Comment 80 Tobias Burnus 2007-03-14 15:15:12 UTC
(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.
Comment 81 Uroš Bizjak 2007-03-14 15:30:36 UTC
(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.
Comment 82 Joost VandeVondele 2007-03-14 16:29:44 UTC
> 
> 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 ?)
Comment 83 Joost VandeVondele 2007-03-16 11:11:10 UTC
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
Comment 84 Uroš Bizjak 2007-03-16 11:21:08 UTC
(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.
Comment 85 Joost VandeVondele 2007-03-16 11:52:49 UTC
(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

Comment 86 Joost VandeVondele 2007-03-16 12:07:50 UTC
(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
Comment 87 Uroš Bizjak 2007-03-16 12:16:24 UTC
(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.
Comment 88 Uroš Bizjak 2007-03-16 12:43:20 UTC
(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!
Comment 89 Joost VandeVondele 2007-03-16 14:16:22 UTC
> 
> Thanks for your reports!
> 

and you for your fixes... things are back to working now.
Comment 90 Francois-Xavier Coudert 2007-03-17 11:24:16 UTC
Closing as fixed.
Comment 91 Joost VandeVondele 2007-04-24 13:37:43 UTC
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.
Comment 92 Joost VandeVondele 2007-04-24 14:31:35 UTC
(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.

Comment 93 Joost VandeVondele 2007-04-24 15:11:59 UTC
(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).

Comment 94 Joost VandeVondele 2007-04-24 15:27:16 UTC
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
Comment 95 Joost VandeVondele 2007-04-24 15:42:56 UTC
added PR 31683 with a reduced testcase
Comment 96 Joost VandeVondele 2007-05-04 09:15:20 UTC
(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
Comment 97 Joost VandeVondele 2007-05-21 08:30:46 UTC
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
Comment 98 Daniel Franke 2007-05-21 12:38:46 UTC
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64 equivalent and got the ICE described in PR32018.
Comment 99 Joost VandeVondele 2007-05-21 15:40:50 UTC
(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.
Comment 100 Joost VandeVondele 2007-05-21 15:58:06 UTC
(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

Comment 101 Joost VandeVondele 2007-05-26 08:45:35 UTC
current gcc (i.e. after the fix for PR32018) still ICEs as described in comment #100
Comment 102 Joost VandeVondele 2007-05-26 09:02:26 UTC
(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
Comment 103 Joost VandeVondele 2007-05-26 10:06:22 UTC
(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
Comment 104 Joost VandeVondele 2007-05-29 15:07:35 UTC
Even at optimisations levels lower than the one needed to generate the ICE of PR 32096 (thanks tobias burnus), CP2K seems miscompiled. One possible testcase has been added as PR 32140. 
Comment 105 Joost VandeVondele 2007-06-01 07:08:58 UTC
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.
Comment 106 Martin Michlmayr 2007-06-07 07:21:19 UTC
(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?
Comment 107 Joost VandeVondele 2007-06-07 09:25:16 UTC
(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.
Comment 108 Joost VandeVondele 2007-06-07 09:34:26 UTC
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.
Comment 109 Joost VandeVondele 2007-06-07 11:56:44 UTC
(In reply to comment #108)
> Unfortunately the newly updated compiler ICEs now at -O0
> 

this is now PR 32242
Comment 110 Joost VandeVondele 2007-06-07 19:26:12 UTC
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.
Comment 111 Joost VandeVondele 2007-06-07 19:36:19 UTC
(In reply to comment #110)
> /scratch/vondele/clean/cp2k/src/../src/pw_types.F:2647: internal compiler
> error: in gfc_trans_assignment_1, at fortran/trans-expr.c:3877

filed as PR 32248

Comment 112 Joost VandeVondele 2007-06-20 20:25:01 UTC
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).
Comment 113 Francois-Xavier Coudert 2007-06-20 20:41:19 UTC
(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"?
Comment 114 Joost VandeVondele 2007-06-21 03:41:38 UTC
(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.
Comment 115 Joost VandeVondele 2007-06-21 09:05:34 UTC
trying to investigate the culprit of the slowdown mentioned in comment 112 I found out that adding -pg to the compile flags leads to a miscompiled code. I've filed PR 32450 to track the issue
Comment 116 Joost VandeVondele 2007-06-22 05:56:10 UTC
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.
Comment 117 Andrew Pinski 2007-06-22 07:24:36 UTC
(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).
Comment 118 Joost VandeVondele 2007-06-22 07:34:37 UTC
(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
Comment 119 Joost VandeVondele 2007-06-27 08:24:44 UTC
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.
Comment 120 pinskia@gmail.com 2007-06-27 09:37:32 UTC
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
Comment 121 Joost VandeVondele 2007-06-27 12:47:17 UTC
(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.
Comment 122 Joost VandeVondele 2007-06-27 12:51:00 UTC
(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.
Comment 123 Joost VandeVondele 2007-06-27 13:54:10 UTC
(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. 
Comment 124 Joost VandeVondele 2007-06-27 14:21:14 UTC
(In reply to comment #123)
and there is no valgrind error if I remove -ftree-vectorize from the options. Which, I guess, explains why things get compiled correctly in that case.

Comment 125 Joost VandeVondele 2007-06-27 14:45:09 UTC
(In reply to comment #119)
> Testing gcc 4.2.0 I unfortunately found that it miscompiles CP2K.

filed as PR 32521
Comment 126 Joost VandeVondele 2007-06-27 19:55:46 UTC
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.
Comment 127 Joost VandeVondele 2007-06-28 06:08:10 UTC
(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
Comment 128 Joost VandeVondele 2007-07-02 21:36:06 UTC
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.
Comment 129 Joost VandeVondele 2007-07-02 21:42:08 UTC
(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
Comment 130 Uroš Bizjak 2007-07-03 07:11:20 UTC
(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?
Comment 131 Joost VandeVondele 2007-07-03 07:22:58 UTC
(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
 

Comment 132 Joost VandeVondele 2007-07-05 14:39:57 UTC
new bogus gfortran error on CP2K : PR 32633
Comment 133 Francois-Xavier Coudert 2007-07-06 12:18:43 UTC
I've made a first try to an automatic nightly tester of CP2K (thanks Joost for the input files provided), I'll post full details when I'm sure it's working OK.
Comment 134 Joost VandeVondele 2007-07-06 14:52:22 UTC
(In reply to comment #133)
> I've made a first try to an automatic nightly tester of CP2K (thanks Joost for
> the input files provided), I'll post full details when I'm sure it's working
> OK.

that's great...

Comment 135 Joost VandeVondele 2007-07-10 07:05:09 UTC
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)
Comment 136 Joost VandeVondele 2007-07-11 05:48:35 UTC
(In reply to comment #135)
> new bogus errors compiling all.f90 ...  

filed as PR 32727
Comment 137 Paul Thomas 2007-07-24 06:18:17 UTC
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
Comment 138 Joost VandeVondele 2007-07-24 06:31:41 UTC
(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.
Comment 139 Joost VandeVondele 2007-07-24 07:22:11 UTC
(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.
Comment 140 Paul Thomas 2007-07-24 07:45:55 UTC
(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
Comment 141 Joost VandeVondele 2007-07-24 08:44:18 UTC
(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.
Comment 142 Francois-Xavier Coudert 2007-08-15 10:44:28 UTC
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!
Comment 143 Joost VandeVondele 2007-12-05 10:12:52 UTC
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
Comment 144 Paul Thomas 2007-12-06 08:17:07 UTC
(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
Comment 145 Joost VandeVondele 2008-01-23 19:02:30 UTC
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.
Comment 146 Joost VandeVondele 2008-01-23 19:30:39 UTC
(In reply to comment #145)
> current gfortran trunk seems to fail on CVS sources of CP2K with:

PR34946
Comment 147 Paul Thomas 2008-02-16 18:54:46 UTC
(In reply to comment #146)
> (In reply to comment #145)
> > current gfortran trunk seems to fail on CVS sources of CP2K with:
> PR34946

Joost - can this be closed again?

Cheers

Paul
Comment 148 Joost VandeVondele 2008-02-18 08:10:47 UTC
(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').
Comment 149 Joost VandeVondele 2008-04-28 12:45:24 UTC
new ICE, PR36071.
Comment 150 Francois-Xavier Coudert 2008-05-01 08:28:53 UTC
Apparently fixed.
Comment 151 Joost VandeVondele 2008-05-03 18:17:57 UTC
New ICE PR36119, reopening.
Comment 152 kargl 2008-05-03 18:42:24 UTC
(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.
Comment 153 Jerry DeLisle 2008-05-03 19:15:38 UTC
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.
Comment 154 Joost VandeVondele 2008-05-05 10:31:07 UTC
this PR remains meaningful, but indeed the component should be changed to 'other'