From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DD37F3858C5E; Fri, 3 Feb 2023 00:07:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD37F3858C5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675382865; bh=GFUmMSSgibqeynG3cDrrKxQb7hMLR1sqYJkNKkTEcIs=; h=From:To:Subject:Date:From; b=F/pNvoq3KcJuRqV31quM+Yf7gpzGzP5pmHfxoQrr+0Cp8U9nM4vl9O1RrA+XAWqXD 0zSM23RnOCUhQVMlp3hnT7BZKdU8EMPFxNM0vtorfm7gNZ/TY9161leXfBjPJ+LbRJ ZGcrIlCFWCVCS7SjlooxofNAFnznTH0cMvvGgOK8= From: "Boyce at engineer dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/108649] New: allocation segmentation fault for pointer derive type and ICE for final-binding Date: Fri, 03 Feb 2023 00:07:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 11.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Boyce at engineer dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108649 Bug ID: 108649 Summary: allocation segmentation fault for pointer derive type and ICE for final-binding Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Boyce at engineer dot com Target Milestone: --- I was having a very challenging time simplifying the errors from this progr= am into basic test case.=20 I have developed several workarounds for bugs that are currently listed here (or I posted), but the ones in this post I could not find nor simplify. This code base is about 30 years old and been under active development the entire time, so it has code styles ranging from simple F77 to F2018. Its a simulation software used for understand groundwater availability by simulating the subsurface, climate conditions, agriculture production, and river/stream flow. https://www.usgs.gov/software/modflow-one-water-hydrologic-flow-model-mf-ow= hm Unfortunately, this code is too long to post here, so I attached it instead. Its source is hosted at:=20 https://code.usgs.gov/modflow/mf-owhm which is a gitlab webserver. Note that the code attached here contains my gfortran workarounds to avoid = the deallocation ICE (first issue discussed below), while the code online does = not. I tested this code with with=20 GNU Fortran (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 and GNU Fortran (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0 on LUbuntu 22.04 and on windows with GNU Fortran (Rev10, Built by MSYS2 project) 12.2.0 There are two issues:=20 DEALLOCATE(x) where x is a derive type with a FINAL (final-binding) subroutine.=20 It seems to have the most problems for derive types with complex final subroutines (usually that call derive type components that have final subroutines). For example, in the file wel8.f90, the following code would fail: deallocate(gwfweldat(igrid)%welfeed) welfeed=3D>null() where in a module are the global variables type(line_feed), pointer,save:: welfeed and the other is a larger derived data type that has the same record. type gwfweltype ! integer,pointer:: iout ! type(line_feed), pointer:: welfeed ! ... end type How I was able to get the code to compile was: welfeed=3D>gwfweldat(igrid)%welfeed gwfweldat(igrid)%welfeed=3D>null() deallocate(welfeed) welfeed=3D>null() The second issue is that a debug compilation (-O0 -g -w -fbacktrace -fcheck=3Dall) raises runtime memory errors that should not happen: SIGSEGV: Segmentation fault - invalid memory reference This typically occurs where a global variable pointer is allocated. The attached zip file has minimum code base and a makefile configured to bu= ild the program with gfortran. The folder structure is: bin - compiled binary location examples - runtime examples for validation lib - any intermediate library files (not used in current setup) obj - object (.o), module (.mod), and submodule (.smod) files are he= re src - source code The makefile has instructions in the comment header.=20 In short, there are a set of variables set at the start, and based on their answer setup the makefile. Here are the important parts: You can set F90 :=3D gfortran to the compiler version you want, such as F90 :=3D gfortran-12 If set the following is set to YES STATIC :=3D NO will add to the compiler directives: -static -static-libgfortran -static-libgcc -static-libstdc++ This must remain as YES, as the code is dependent on it. DBLE :=3D YES If you want to change any of the compiler flags, they are specified in: F90FlagsGCC simply typing "make" should build the code. Its current setup runs on all the source files: gfortran -O0 -g -w -fbacktrace -fdefault-double-8 -ffree-line-length-2048 -fmax-errors=3D10 -ffpe-trap=3Dzero,overflow,underflow -finit-real=3Dnan -f= check=3Dall -fdefault-real-8 -J./obj/debug_gfortran -c XXXX.f90 -o obj/debug_gfortran/XXXX.o if you want it to run all its test examples, there are a set of bash scripts located on: https://code.usgs.gov/modflow/mf-owhm/ in the examples/bash_example_run directory. (https://code.usgs.gov/modflow/mf-owhm/-/tree/main/examples/bash_example_ru= n) 1_RunValidation.sh will run all the examples and has a set of additional arguments that can be set. In particular, 1_RunValidation.sh debug will indicate that it should run the debug version (mf-owhm-debug rather th= an mf-owhm). In the attachment I added run_breaking_example0.sh, run_breaking_example1.s= h, and run_breaking_example2.sh which calls mf-owhm-debug.nix with one of the example problems. For example, if I run (on 11.3.0) run_breaking_example0.sh the following er= ror is encountered: ---------------------------------------------------------------------------= ---------------------------- Program received signal SIGSEGV: Segmentation fault - invalid memory refere= nce. Backtrace for this error: #0 0x7f30118d4ad0 in ??? #1 0x7f30118d3c35 in ??? #2 0x7f301157c51f in ??? #3 0x560a7abaaaf5 in __wel_subroutines_MOD_gwf2wel8ar at ./src/modflow_base/wel8.f90:98 #4 0x560a7ae1f271 in modflow_owhm_run_ at ./src/main.f90:396 #5 0x560a7ae3f213 in modflow_owhm at ./src/main.f90:100 #6 0x560a7ae3f262 in main at ./src/main.f90:173 ---------------------------------------------------------------------------= ---------------------------- if I add=20 -fsanitize=3Daddress,undefined to the F90FlagsGCC variable, then I get the following: ---------------------------------------------------------------------------= ---------------------------- src/modflow_base/wel8.f90:98:19: runtime error: store to null pointer of ty= pe 'character(kind=3D1)' Program received signal SIGSEGV: Segmentation fault - invalid memory refere= nce. Backtrace for this error: #0 0x1526569f7ad0 in ??? #1 0x1526569f6c35 in ??? #2 0x15265606851f in ??? #3 0x5609ea5b9f51 in __wel_subroutines_MOD_gwf2wel8ar at ./src/modflow_base/wel8.f90:98 #4 0x5609eb0f8719 in modflow_owhm_run_ at ./src/main.f90:396 #5 0x5609eb17c7cd in modflow_owhm at ./src/main.f90:100 #6 0x5609eb17c85c in main at ./src/main.f90:173 ---------------------------------------------------------------------------= ---------------------------- The line it is complaining about is a pointer is a derived type that is in = the global space that is being allocated: ALLOCATE(WELFEED) which is brought in from USE GWFWEL2MODULE and defined in MODULE GWFWEL2MODULE as=20 TYPE(LINE_FEED), POINTER,SAVE:: WELFEED run_breaking_example1.sh gives a different source file, but it contains a similar allocation to the same derived type. Backtrace for this error: #0 0x7f24d28b2ad0 in ??? #1 0x7f24d28b1c35 in ??? #2 0x7f24d255a51f in ??? #3 0x5639bf0b981d in __ghb_subroutines_MOD_gwf2ghb7ar at ./src/modflow_base/ghb.f:124 #4 0x5639bf40b8ca in modflow_owhm_run_ at ./src/main.f90:401 #5 0x5639bf42b213 in modflow_owhm at ./src/main.f90:100 #6 0x5639bf42b262 in main at ./src/main.f90:173 ---------------------------------------------------------------------------= ---------------------------- This program has always used Intel Fortran (ifort) for the last 20 years without any issue.=20 I am hoping to adapt it to compile with gfortran to broaden its compiler support, and take advantage of the error messages that gfortran provides wh= en developing new features (ifort tends to be too lenient). It would be wonderful to start using gfortran as part of the compiler set f= or this project (and some of its downstream dependencies.=