public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/110626] New: Duplicated finalization in derived
@ 2023-07-11  9:40 habbit89 at hotmail dot es
  2023-07-11  9:46 ` [Bug fortran/110626] " habbit89 at hotmail dot es
  2023-07-11 10:27 ` habbit89 at hotmail dot es
  0 siblings, 2 replies; 3+ messages in thread
From: habbit89 at hotmail dot es @ 2023-07-11  9:40 UTC (permalink / raw)
  To: gcc-bugs

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)

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-07-11 10:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-11  9:40 [Bug fortran/110626] New: Duplicated finalization in derived habbit89 at hotmail dot es
2023-07-11  9:46 ` [Bug fortran/110626] " habbit89 at hotmail dot es
2023-07-11 10:27 ` habbit89 at hotmail dot es

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).