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).
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?
(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)
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!
(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.
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
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
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
(In reply to comment #7) > Joost, > > Do you happen to know at what revision things went bad? I'm afraid I don't...
(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
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!
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
> 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.
(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 ...
> 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.
> 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
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
> 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)
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
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
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
> 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.)
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).
(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
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.
> 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".
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
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
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
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
(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
> > 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.
(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 ?
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.
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.
(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.
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
(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).
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.
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
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)
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
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.
Fixed in GCC 4.3.0
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.
(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;
(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.
(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.
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...
(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).
> > 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.
> 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.
> I don't know if this triggers something, looks like a simple statement. Yes that triggers my memory of PR 30391.
(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
(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
> 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.
(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
> 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
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
(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
> 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 ??
(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
(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
> 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
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?
(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.
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,
PR 30391 is fixed with rev. 122030, so we should close this PR. Please reopen if we regress.
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
(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
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.
(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
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.
I've added PR 31021 to track some performance issue with gfortran on one of CP2K's kernels.
(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 :)
> 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'...
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?
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
(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?
(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
(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.
(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.
> > 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 ?)
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
(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.
(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
(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
(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.
(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!
> > Thanks for your reports! > and you for your fixes... things are back to working now.
Closing as fixed.
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.
(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.
(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).
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
added PR 31683 with a reduced testcase
(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
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
Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64 equivalent and got the ICE described in PR32018.
(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.
(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
current gcc (i.e. after the fix for PR32018) still ICEs as described in comment #100
(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
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.
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.
(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?
(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.
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.
(In reply to comment #108) > Unfortunately the newly updated compiler ICEs now at -O0 > this is now PR 32242
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.
(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
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).
(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"?
(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.
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
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.
(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).
(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
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.
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
(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.
(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.
(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.
(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.
(In reply to comment #119) > Testing gcc 4.2.0 I unfortunately found that it miscompiles CP2K. filed as PR 32521
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.
(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
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.
(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
(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?
(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
new bogus gfortran error on CP2K : PR 32633
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.
(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...
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)
(In reply to comment #135) > new bogus errors compiling all.f90 ... filed as PR 32727
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
(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.
(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.
(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
(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.
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!
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
(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
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.
(In reply to comment #145) > current gfortran trunk seems to fail on CVS sources of CP2K with: PR34946
(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
(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').
new ICE, PR36071.
Apparently fixed.
New ICE PR36119, reopening.
(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.
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.
this PR remains meaningful, but indeed the component should be changed to 'other'