[Bug fortran/108649] New: allocation segmentation fault for pointer derive type and ICE for final-binding

["Boyce at engineer dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649

            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 program
into basic test case. 
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-owhm

Unfortunately, this code is too long to post here, so I attached it instead.

Its source is hosted at: 
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 
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: 
DEALLOCATE(x)

where x is a derive type with a FINAL (final-binding) subroutine. 

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=>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=>gwfweldat(igrid)%welfeed
  gwfweldat(igrid)%welfeed=>null()
  deallocate(welfeed)
  welfeed=>null()


The second issue is that a debug compilation (-O0 -g -w -fbacktrace
-fcheck=all)   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 build
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 here
  src      - source code

The makefile has instructions in the comment header. 
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 := gfortran

to the compiler version you want, such as
F90 := gfortran-12

If set the following is set to YES
STATIC := 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 := 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=10 -ffpe-trap=zero,overflow,underflow -finit-real=nan -fcheck=all
-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_run)

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 than
mf-owhm).


In the attachment I added run_breaking_example0.sh, run_breaking_example1.sh,
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 error
is encountered:
-------------------------------------------------------------------------------------------------------
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

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 
-fsanitize=address,undefined
 to the F90FlagsGCC variable, then I get the following:


-------------------------------------------------------------------------------------------------------
src/modflow_base/wel8.f90:98:19: runtime error: store to null pointer of type
'character(kind=1)'

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

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 
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. 
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 when
developing new features (ifort tends to be too lenient).

It would be wonderful to start using gfortran as part of the compiler set for
this project (and some of its downstream dependencies.