[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.05 09:48:16 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 --- Comment #6 from janus at gcc dot gnu.org 2010-11-05 18:15:02 UTC --- Author: janus Date: Fri Nov 5 18:14:52 2010 New Revision: 166368 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166368 Log: 2010-11-05 Janus Weil ja...@gcc.gnu.org PR fortran/45451 PR fortran/46174 * class.c (gfc_find_derived_vtab): Improved search for existing vtab. Add component '$copy' to vtype symbol for polymorphic deep copying. * expr.c (gfc_check_pointer_assign): Make sure the vtab is generated during resolution stage. * resolve.c (resolve_codes): Don't resolve code if namespace is already resolved. * trans-stmt.c (gfc_trans_allocate): Call '$copy' procedure for polymorphic ALLOCATE statements with SOURCE. 2010-11-05 Janus Weil ja...@gcc.gnu.org PR fortran/45451 PR fortran/46174 * gfortran.dg/class_19.f03: Modified. * gfortran.dg/class_allocate_6.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_allocate_6.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/class_19.f03
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from janus at gcc dot gnu.org 2010-11-05 18:39:41 UTC --- The deep copy issue is fixed by r166368. For poylmorphic deallocation (comment #2) I have opened PR 46321.
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-03 09:18:32 UTC --- Draft patch for $free/$copy (w/o FINALize, cf. PR 37336): http://gcc.gnu.org/ml/fortran/2010-11/msg00030.html
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-10-26 07:09:41 UTC --- (In reply to comment #0) The following is in a sense a follow up to PR 45451. Assuming that X and Y are both polymorphic (CLASS) and the following operation: ALLOCATE (x, SOURCE=y) or x = y ! Fortran 2008: (Re)alloc on assignment with polymorphic LHS What about MOLD= for polymorphic variables?
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-26 07:44:15 UTC --- (In reply to comment #1) What about MOLD= for polymorphic variables? MOLD= should work. Allocate with mold= allocates memory for the effective type of mold and initializes with the default initializer. By default, allocatable components are not allocated and thus there is no problem. (SOURCE= also works if (currently: and only if) all allocatable components are not allocated.) * * * Similarly affected: Deallocation when leaving the scope: The allocatable components of the effective type are not deallocated. Example: implicit none type t end type t type, extends(t) :: t2 integer, allocatable :: all end type t2 class(t), allocatable :: a if (allocated(a)) call foo() end If one looks at the dump, one sees that only allocatable components of the declared type (t, here: none) but not allocatable components of the effective type are freed. I think that's tightly coupled to FINALization subroutines, i.e. PR 37336.
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||domob at gcc dot gnu.org
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-26
13:27:11 UTC ---
Possible implementation scheme: vtab$t contains besides the normal type-bound
procedures and init/size/hash also an two function points: $copy and $free,
which are of the kind:
void $free (struct *DT) {
... free derived types
if (DT-$vtab-$extends DT-$vtab-$extends-$free)
DT-$vtab-$extends-$free (DT)
}
That is, each effective type cleans up its own allocatable components and moves
on to the parent. If the parent does not have an allocatable component itself,
the $free pointer directly points to an ancestor which has -- or is NULL if no
such ancestor exists. The $copy version works alike.
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174
--- Comment #4 from Daniel Kraft domob at gcc dot gnu.org 2010-10-26 19:00:34
UTC ---
(In reply to comment #3)
Possible implementation scheme: vtab$t contains besides the normal type-bound
procedures and init/size/hash also an two function points: $copy and $free,
which are of the kind:
void $free (struct *DT) {
... free derived types
if (DT-$vtab-$extends DT-$vtab-$extends-$free)
DT-$vtab-$extends-$free (DT)
}
That is, each effective type cleans up its own allocatable components and
moves
on to the parent. If the parent does not have an allocatable component itself,
the $free pointer directly points to an ancestor which has -- or is NULL if no
such ancestor exists. The $copy version works alike.
Note that this is basically what I would suggest to do also for finalization --
in principle, all that needs to be extended from your scheme is that $free
also has to call the appropriate finalizer in-between the frees. (This
recursing on parent type is also exactly as finalization is specified by the
standard.)
And because there may be multiple FINAL procedures differing in rank and the
correct one must be called in any case, I fear that we have to create a $free
for each rank, too (or play some nasty tricks). But that should be more a
mechanical change and bloat the resulting code instead of being hard to
implement.
