[Bug fortran/110626] New: Duplicated finalization in derived

[Bug fortran/110626] New: Duplicated finalization in derived

[habbit89 at hotmail dot es]

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

            Bug ID: 110626
           Summary: Duplicated finalization in derived
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: habbit89 at hotmail dot es
  Target Milestone: ---

Created attachment 55520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55520&action=edit
Example module and test program

After the changes to finalization in gfortran 13 there seems to be an issue
under the following circumstances:

* A derived type A has custom assignment and finalization
* It is used as a component (or as a base) of another type B

Then, assignment of type B will call the assignment of A only once, but the
final subroutine twice, which breaks resource holding code such as reference
counting.

The example has two subroutines, one where two objects of type A are used
directly, and one where objects of type B are used. In both cases, o1 is
initialized to some value, then it is copied to o2, then o2 is overwritten
again. The expected result would, in both cases, be a finalization of the
target before the assignment, then the assignment call.

Compiling and running the example will give the following correct results on
gfortran 11

> $ gfortran-11 -Wall -Wextra -o a-11.out testmod.f90
> $ ./a-11.out
> o1:     7FFFA5E1BD2C
> o2:     7FFFA5E1BD28
> dtor: -1     7FFFA5E1BD28
> copy: 15 from     7FFFA5E1BD2C to     7FFFA5E1BD28
> dtor: 16     7FFFA5E1BD28
> copy: 15 from     7FFFA5E1BD2C to     7FFFA5E1BD28
> dtor: 16     7FFFA5E1BD28
> dtor: 15     7FFFA5E1BD2C
>  objects of type B in subroutine
> o1:     7FFFA5E1BD2C
> o2:     7FFFA5E1BD28
> dtor: 15     7FFFA5E1BD28
> copy: 15 from     7FFFA5E1BD2C to     7FFFA5E1BD28
> dtor: 15     7FFFA5E1BD28
> copy: 15 from     7FFFA5E1BD2C to     7FFFA5E1BD28
> dtor: 16     7FFFA5E1BD28
> dtor: 15     7FFFA5E1BD2C

But the following *invalid* results in gfortran 13:

> $ gfortran-13 -Wall -Wextra -o a-13.out testmod.f90
> $ ./a-13.out 
>  objects of type A in subroutine
> o1:     7FFFCEEDBC2C
> o2:     7FFFCEEDBC28
> dtor: -1     7FFFCEEDBC28
> copy: 15 from     7FFFCEEDBC2C to     7FFFCEEDBC28
> dtor: 16     7FFFCEEDBC28
> copy: 15 from     7FFFCEEDBC2C to     7FFFCEEDBC28
> dtor: 16     7FFFCEEDBC28
> dtor: 15     7FFFCEEDBC2C
>  objects of type B in subroutine
> o1:     7FFFCEEDBC24
> o2:     7FFFCEEDBC20
> dtor: -1     7FFFCEEDBC20
> dtor: -1     7FFFCEEDBC2C
> copy: 15 from     7FFFCEEDBC24 to     7FFFCEEDBC2C
> dtor: 16     7FFFCEEDBC20
> dtor: 16     7FFFCEEDBC28
> copy: 15 from     7FFFCEEDBC24 to     7FFFCEEDBC28
> dtor: 16     7FFFCEEDBC20
> dtor: 15     7FFFCEEDBC24

The part where objects of type A are used directly works in both versions.
However, when objects of type *B* are used, gfortran 13 shows the following
behaviour:
* There seems to be a "shadow"/temporary object created at a different location
which is neither o1 nor o2, probably at a stack address.
* The assignment operator runs only once, from o1 to this shadow object.
* The value is then apparently blitted onto/used for o2, which might be okay
except that...
* Before the next assignment, the final subroutine of A runs *twice*, once with
the actual o2 and once with this shadow object.

Thus, given that the assignment code runs once but the finalization runs
*twice*, using this scheme to hold resources (e.g. via ref counting) breaks. In
particular, it is very weird that 

I am _assuming_ that the two separate finalizations may be conceptually come
from 1. the overall finalization of B before the assignment, and 2. the
intent(out) for A in subroutine copy. However, both calls use the values
_prior_ to the finalization (since it sets the value to -2 but the calls both
print 16)

[Bug fortran/110626] Duplicated finalization in derived

[habbit89 at hotmail dot es]

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

--- Comment #1 from Javier Martín <habbit89 at hotmail dot es> ---
Contextual/environment information: I could reproduce the issue with gfortran
13.1, running in both Debian Sid and MSYS2 UCRT64 on Windows 10 22H2.

In Debian:
> $ gfortran-13 -v
> Using built-in specs.
> COLLECT_GCC=gfortran-13
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 13.1.0-7' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-13-Nk38xB/gcc-13-13.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-Nk38xB/gcc-13-13.1.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 13.1.0 (Debian 13.1.0-7)

In Windows:
> C> gfortran-13 -v
> Using built-in specs.
> COLLECT_GCC=gfortran
> COLLECT_LTO_WRAPPER=C:/Users/jvma/devtools/msys2/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe
> Target: x86_64-w64-mingw32
> Configured with: ../gcc-13.1.0/configure --prefix=/ucrt64 --with-local-prefix=/ucrt64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/ucrt64/include --libexecdir=/ucrt64/lib --enable-bootstrap --enable-checking=release --with-arch=nocona --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64 --with-pkgversion='Rev7, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 13.1.0 (Rev7, Built by MSYS2 project)

[Bug fortran/110626] Duplicated finalization in derived

[habbit89 at hotmail dot es]

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

--- Comment #2 from Javier Martín <habbit89 at hotmail dot es> ---
Note: when I said that the output of gfortran-11 is "correct", it is in
reference to this specific issue. In particular, the output of gfortran-11
seems to be affected by bug 105170, which is a separate problem with assignment
and finalization of derived types. However, that bug appears to be fixed in the
finalization changes for gfortran-13.