public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/64290] New: Destructor not called at deallocation of LHS
@ 2014-12-12 16:26 baradi09 at gmail dot com
  2014-12-15 11:46 ` [Bug fortran/64290] [F03] No finalization " janus at gcc dot gnu.org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: baradi09 at gmail dot com @ 2014-12-12 16:26 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 64290
           Summary: Destructor not called at deallocation of LHS
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: baradi09 at gmail dot com

Created attachment 34268
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34268&action=edit
Self contained source demonstrating

During an assingment with an allocatable type on both, the LHS and the RHS, the
destructor of the LHS-type is not called. IMHO, this is erroneous behaviour as
the LHS gets (hopfully) deallocated on the assignment.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/64290] [F03] No finalization at deallocation of LHS
  2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
@ 2014-12-15 11:46 ` janus at gcc dot gnu.org
  2021-01-11  8:17 ` pault at gcc dot gnu.org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: janus at gcc dot gnu.org @ 2014-12-15 11:46 UTC (permalink / raw)
  To: gcc-bugs

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-15
                 CC|                            |janus at gcc dot gnu.org
         Depends on|                            |37336
            Summary|Destructor not called at    |[F03] No finalization at
                   |deallocation of LHS         |deallocation of LHS
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. See also PR 37336 comment 27.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/64290] [F03] No finalization at deallocation of LHS
  2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
  2014-12-15 11:46 ` [Bug fortran/64290] [F03] No finalization " janus at gcc dot gnu.org
@ 2021-01-11  8:17 ` pault at gcc dot gnu.org
  2021-01-12 12:04 ` pault at gcc dot gnu.org
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2021-01-11  8:17 UTC (permalink / raw)
  To: gcc-bugs

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 49936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49936&action=edit
Initial fix for the PR

Triggered by a recent thread on clf, I have made a first stab at this PR. This
patch is thus far perfect and has the following regressions:

FAIL: gfortran.dg/class_optional_1.f90   -O0  execution test
FAIL: gfortran.dg/dynamic_dispatch_6.f03   -O1  execution test
FAIL: gfortran.dg/finalize_15.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/finalize_25.f90   -O0  execution test
FAIL: gfortran.dg/finalize_29.f08   -O0  execution test
plus
FAIL: gfortran.dg/prof/dynamic_dispatch_6.f03 execution,    -fprofile-generate
-D_PROFILE_GENERATE

which is not too bad for a first attempt. Note that for arrays, finalization is
occurring before reallocation of the lhs contrary to the requirements of the
standard.

This test, based on the reporter's testcase, works as intended:
module testmode
  implicit none

  type :: simple
    integer :: ind
  contains
    final :: destruct1, destruct2
  end type simple

  integer :: check_scalar
  integer :: check_array(2)
  integer :: final_count = 0

contains

  subroutine destruct1(self)
    type(simple), intent(inout) :: self

!    print *, "DESTRUCTING SCALAR", self%ind
    check_scalar = self%ind
    check_array = 0
    final_count = final_count + 1

  end subroutine destruct1

  subroutine destruct2(self)
    type(simple), intent(inout) :: self(:)

!    print *, "DESTRUCTING ARRAY", self%ind
    check_scalar = 0
    check_array = self%ind
    final_count = final_count + 1

  end subroutine destruct2

  subroutine test (cnt, scalar, array, off)
    integer :: cnt
    integer :: scalar
    integer :: array(:)
    integer :: off
    if (final_count .ne. cnt) stop 1 + off
    if (check_scalar .ne. scalar) stop 2 + off
    if (any (check_array .ne. array)) stop 3 + off
  end subroutine test

end module testmode

program test_final
  use testmode
  implicit none

  type(simple), allocatable :: myres, myres2
  type(simple), allocatable :: myarray(:)
  type(simple) :: thyres = simple(21), thyres2 = simple(22)

  allocate(myres)
  allocate(myres2)
  myres%ind = 1
  myres2%ind = 2
  myres = myres2
  call test(1, 1, [0,0], 10)

  allocate(myarray(2))
  myarray%ind = [42, 43]
  myarray = [thyres, thyres2]
  call test(2, 0, [42,43], 20)

  thyres2 = simple(99)
  call test(3, 22, [0,0], 30)

  thyres = thyres2
  call test(4, 21, [0,0], 40)

  deallocate (myres, myres2)
  call test(6, 2, [0,0], 100)

  deallocate (myarray)
  call test(7, 0, [21,22], 200)

end program test_final

Paul

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/64290] [F03] No finalization at deallocation of LHS
  2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
  2014-12-15 11:46 ` [Bug fortran/64290] [F03] No finalization " janus at gcc dot gnu.org
  2021-01-11  8:17 ` pault at gcc dot gnu.org
@ 2021-01-12 12:04 ` pault at gcc dot gnu.org
  2021-01-12 13:03 ` drikosev at gmail dot com
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2021-01-12 12:04 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 49952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49952&action=edit
Slightly better patch

This gets rid of the regression in gfortran.dg/finalize_29.f08.

However, finalize_25.f90 exposes the real scale of the problem because it shows
that finalization is partially implemented for variables with allocatable
components and this causes collisions with the finalization in the patch.

Cheers

Paul

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/64290] [F03] No finalization at deallocation of LHS
  2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
                   ` (2 preceding siblings ...)
  2021-01-12 12:04 ` pault at gcc dot gnu.org
@ 2021-01-12 13:03 ` drikosev at gmail dot com
  2021-01-18  8:32 ` drikosev at gmail dot com
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: drikosev at gmail dot com @ 2021-01-12 13:03 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Ev Drikos <drikosev at gmail dot com> ---


Hello,

There are some open PRs related to elemental finalisers. Having seen
how you reallocate arrays, I'd the impression that the functionality
for polymorphic entities would had a similar design. As one may also
need ie to reset at least the '_len' field, ie class(*) x; x='a';

Which in turn may not cause regressions to "finalize_25.f90" and I see
that this test counts some finalisation calls. Of course I don't doubt
that finalization may be partially implemented as you say. Admittedly
the interpretation of 10.2.1.3 & 7.5.6.3 seems to be a herculean task.

To my understanding, an outcome of the discussion in c.l.f is that the
reallocation takes place if the LHS & RHS have different runtime types,
at least this seems to be a criterion for no rank polymorphic entities.


Hope this helps,
Ev. Drikos

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/64290] [F03] No finalization at deallocation of LHS
  2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
                   ` (3 preceding siblings ...)
  2021-01-12 13:03 ` drikosev at gmail dot com
@ 2021-01-18  8:32 ` drikosev at gmail dot com
  2021-05-04 12:31 ` rguenth at gcc dot gnu.org
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: drikosev at gmail dot com @ 2021-01-18  8:32 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Ev Drikos <drikosev at gmail dot com> ---
Created attachment 49990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49990&action=edit
realloc_class_8.f95

Hello,

Having seen a Note in F2018 draft, specifically
10.2.1.3 Interpretation of intrinsic assignments,
I wrote a test case that I thought should be ok,
but I face this: 

$ gfortran8 realloc_class_8.f95 && ./a.out

 DEFERRED LENGTH NAME

 NAME=NONE [LEN=           4 ]
 USER=NONE [LEN=           4 ]

 NAME=Mr. John Richard Doe [LEN=          20 ]
 USER=Mr. John RichardMr.  [LEN=          20 ]
STOP 6

Of course, there are no finalizers in this case,
yet I think that is closely related because they
have the same bug fix (class reallocations).  


Hope this helps,
Ev. Drikos

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/64290] [F03] No finalization at deallocation of LHS
  2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
                   ` (4 preceding siblings ...)
  2021-01-18  8:32 ` drikosev at gmail dot com
@ 2021-05-04 12:31 ` rguenth at gcc dot gnu.org
  2022-12-16  9:28 ` drikosev at gmail dot com
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-04 12:31 UTC (permalink / raw)
  To: gcc-bugs

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/64290] [F03] No finalization at deallocation of LHS
  2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
                   ` (5 preceding siblings ...)
  2021-05-04 12:31 ` rguenth at gcc dot gnu.org
@ 2022-12-16  9:28 ` drikosev at gmail dot com
  2023-03-18  7:56 ` cvs-commit at gcc dot gnu.org
  2023-03-18 12:23 ` pault at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: drikosev at gmail dot com @ 2022-12-16  9:28 UTC (permalink / raw)
  To: gcc-bugs

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

Ev Drikos <drikosev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #49990|0                           |1
        is obsolete|                            |

--- Comment #6 from Ev Drikos <drikosev at gmail dot com> ---
Created attachment 54109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54109&action=edit
Deallocation on Intrinsic Assignment

Hello, 

This message follows a post by P. Thomas to c.l.f:
https://groups.google.com/g/comp.lang.fortran/c/n62ukWe3TmY/m/5t4RWHELBAAJ

So, I'd like to add to this PR a patch with few relevant test cases. The test
case "realloc_class_8.f95" has been confirmed by feedback at:
https://fortran-lang.discourse.group/t/deallocation-on-intrinsic-assignment/567

Ev. Drikos

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/64290] [F03] No finalization at deallocation of LHS
  2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
                   ` (6 preceding siblings ...)
  2022-12-16  9:28 ` drikosev at gmail dot com
@ 2023-03-18  7:56 ` cvs-commit at gcc dot gnu.org
  2023-03-18 12:23 ` pault at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-03-18  7:56 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:d7caf313525a46f200d7f5db1ba893f853774aee

commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Mar 18 07:56:23 2023 +0000

    Fortran: Fix bugs and missing features in finalization [PR37336]

    2023-03-18  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/103854
            PR fortran/96122
            PR fortran/37336
            * class.cc (finalize_component): Include the missing arguments
            in the call to the component's finalizer wrapper.
            (has_finalizer_component): Do not return true for procedure
            pointer components.
            (finalizer_insert_packed_call): Remove the redundant argument
            in the call to the final subroutine.
            (generate_finalization_wrapper): Add support for assumed rank
            finalizers.
            (gfc_may_be_finalized): New helper function.
            * dump-parse-tree.cc (write_proc): Whitespace.
            * gfortran.h : Add prototype for gfc_may_be_finalized.
            * resolve.cc (resolve_function): Correct derived types that
            have an incomplete namespace.
            (resolve_where, gfc_resolve_where_code_in_forall,
            gfc_resolve_forall_body, gfc_resolve_code): Check that the op
            code is still EXEC_ASSIGN. If it is set lhs to must finalize.
            (is_finalizable_type): New function.
            (generate_component_assignments): Set must_finalize if needed.
            (gfc_resolve_finalizers): Error if assumed rank finalizer is
            not the only one. Warning on lack of scalar finalizer modified
            to account for assumed rank finalizers.
            (generate_final_call): New function.
            (generate_component_assignments): Enclose the outermost call in
            a block to capture automatic deallocation and final calls.
            Set must_finalize as required to satisfy the standards. Use an
            explicit pointer assignment for pointer components to capture
            finalization of the target. Likewise use explicit assignment
            for allocatable components. Do not use the temporary copy of
            the lhs in defined assignment if the component is allocatable.
            Put the temporary in the same namespace as the lhs symbol if
            the component may be finalized. Remove the leading assignment
            from the expansion of assignment of components that have their
            own defined assignment components. Suppress finalization of
            assignment of temporary components to the lhs. Make an explicit
            final call for the rhs function temporary if it exists.
            (gfc_resolve_code): Set must_finalize for assignments with an
            array constructor on the rhs.
            (gfc_resolve_finalizers): Ensure that an assumed rank finalizer
            is the only finalizer for that type and correct the surprising
            warning for the lack of a scalar finalizer.
            (check_defined_assignments): Handle allocatable components.
            (resolve_fl_derived): Set referenced the vtab for use
            associated symbols.
            (resolve_symbol): Set referenced an unreferenced symbol that
            will be finalized.
            * trans-array.cc (gfc_trans_array_constructor_value): Add code
            to finalize the constructor result. Warn that this feature was
            removed in F2018 and that it is suppressed by -std=2018.
            (trans_array_constructor): Add finalblock, pass to previous
            and apply to loop->post if filled.
            (gfc_add_loop_ss_code): Add se finalblock to outer loop post.
            (gfc_trans_array_cobounds, gfc_trans_array_bounds): Add any
            generated finalization code to the main block.
            (structure_alloc_comps): Add boolean argument to suppress
            finalization and use it for calls from
            gfc_deallocate_alloc_comp_no_caf. Otherwise it defaults to
            false.
            (gfc_copy_alloc_comp_no_fini): New wrapper for
            structure_alloc_comps.
            (gfc_alloc_allocatable_for_assignment): Suppress finalization
            by setting new arg in call to gfc_deallocate_alloc_comp_no_caf.
            (gfc_trans_deferred_array): Use gfc_may_be_finalized and do not
            deallocate the components of entities with a leading '_' in the
            name that are also marked as artificial.
            * trans-array.h : Add the new boolean argument to the prototype
            of gfc_deallocate_alloc_comp_no_caf with a default of false.
            Add prototype for gfc_copy_alloc_comp_no_fini.
            * trans-decl.cc(init_intent_out_dt): Tidy up the code.
            * trans-expr.cc (gfc_init_se): Initialize finalblock.
            (gfc_conv_procedure_call): Use gfc_finalize_tree_expr to
            finalize function results. Replace in-line block for class
            results with call to new function.
            (gfc_conv_expr): Finalize structure constructors for F2003 and
            F2008. Warn that this feature was deleted in F2018 and, unlike
            array constructors, is not default. Add array constructor
            finalblock to the post block.
            (gfc_trans_scalar_assign): Suppress finalization by setting new
            argument in call to gfc_deallocate_alloc_comp_no_caf. Add the
            finalization blocks to the main block.
            (gfc_trans_arrayfunc_assign): Use gfc_assignment_finalizer_call
            and ensure that finalization occurs after the evaluation of the
            rhs but using the initial value for the lhs. Finalize rhs
            function results using gfc_finalize_tree_expr.
            (trans_class_assignment, gfc_trans_assignment_1): As previous
            function, taking care to order evaluation, assignment and
            finalization correctly.
            * trans-io.cc (gfc_trans_transfer): Add the final block.
            * trans-stmt.cc (gfc_trans_call, gfc_trans_allocate): likewise.
            (trans_associate_var): Nullify derived allocatable components
            and finalize function targets with defined assignment
            components on leaving the block scope.
            (trans_allocate): Finalize source expressions, if required,
            and set init_expr artificial temporarily to suppress the
            finalization in gfc_trans_assignment.
            * trans.cc (gfc_add_finalizer_call): Do not finalize the
            temporaries generated in type assignment with defined
            assignment components.
            (gfc_assignment_finalizer_call): New function.
            (gfc_finalize_tree_expr): New function.
            * trans.h: Add finalblock to gfc_se. Add the prototypes for
            gfc_finalize_tree_expr and gfc_assignment_finalizer_call.

    gcc/testsuite/
            PR fortran/64290
            * gfortran.dg/finalize_38.f90 : New test.
            * gfortran.dg/finalize_38a.f90 : New test.
            * gfortran.dg/allocate_with_source_25.f90 : The number of final
            calls goes down from 6 to 4.
            * gfortran.dg/associate_25.f90 : Remove the incorrect comment.
            * gfortran.dg/auto_dealloc_2.f90 : Change the tree dump expr
            but the final count remains the same.
            * gfortran.dg/unlimited_polymorphic_8.f90 : Tree dump reveals
            foo.1.x rather than foo.0.x

            PR fortran/67444
            * gfortran.dg/finalize_39.f90 : New test.

            PR fortran/67471
            * gfortran.dg/finalize_40.f90 : New test.

            PR fortran/69298
            PR fortran/70863
            * gfortran.dg/finalize_41.f90 : New test.

            PR fortran/71798
            * gfortran.dg/finalize_42.f90 : New test.

            PR fortran/80524
            * gfortran.dg/finalize_43.f90 : New test.

            PR fortran/82996
            * gfortran.dg/finalize_44.f90 : New test.

            PR fortran/84472
            * gfortran.dg/finalize_45.f90 : New test.

            PR fortran/88735
            PR fortran/93691
            * gfortran.dg/finalize_46.f90 : New test.

            PR fortran/91316
            * gfortran.dg/finalize_47.f90 : New test.

            PR fortran/106576
            * gfortran.dg/finalize_48.f90 : New test.

            PR fortran/37336
            * gfortran.dg/finalize_49.f90 : New test.
            * gfortran.dg/finalize_50.f90 : New test.
            * gfortran.dg/finalize_51.f90 : New test.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug fortran/64290] [F03] No finalization at deallocation of LHS
  2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
                   ` (7 preceding siblings ...)
  2023-03-18  7:56 ` cvs-commit at gcc dot gnu.org
@ 2023-03-18 12:23 ` pault at gcc dot gnu.org
  8 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu.org @ 2023-03-18 12:23 UTC (permalink / raw)
  To: gcc-bugs

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on mainline. After a while, I will ask the list if a backport to
12-branch is OK.

Cheers

Paul

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2023-03-18 12:23 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-12 16:26 [Bug fortran/64290] New: Destructor not called at deallocation of LHS baradi09 at gmail dot com
2014-12-15 11:46 ` [Bug fortran/64290] [F03] No finalization " janus at gcc dot gnu.org
2021-01-11  8:17 ` pault at gcc dot gnu.org
2021-01-12 12:04 ` pault at gcc dot gnu.org
2021-01-12 13:03 ` drikosev at gmail dot com
2021-01-18  8:32 ` drikosev at gmail dot com
2021-05-04 12:31 ` rguenth at gcc dot gnu.org
2022-12-16  9:28 ` drikosev at gmail dot com
2023-03-18  7:56 ` cvs-commit at gcc dot gnu.org
2023-03-18 12:23 ` pault at gcc dot gnu.org

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).