[Patch, fortran] PR98573 - Dynamic type lost on assignment

Tobias Burnus tobias@codesourcery.com
Fri Jan 29 10:57:06 GMT 2021


On 23.01.21 10:04, Paul Richard Thomas via Fortran wrote:

> This is a relatively obvious patch. The chunk in trans-array.c is not part
> of the fix for the PR but does suppress some of the bad dtype's that arise
> from allocation of class objects.
Do you have a testcase for it? Either behavioral (dg-do run) or based on
the tree-dump + scan? I think it would be useful to ensure that, even if
it is not part of the PR – and hence the testcase. (At least it does not
look as if the testcase goes beyond the PR.)
> The part in trans-stmt.c provides vptrs
> for all class allocations if the expression3 is available.
>
> [...]
>
>         /* Set the vptr only when no source= is set.  When source= is set, then
>        the trans_assignment below will set the vptr.  */
> -      if (al_vptr != NULL_TREE && (!code->expr3 || code->expr3->mold))
> +      if (al_vptr != NULL_TREE && (!code->expr3 || code->expr3->mold
> +                                || code->expr3->ts.type == BT_CLASS))

First, the comment needs to be updated as the branch is also called in some
cases for 'source='.

Additionally, I wonder whether there is the any issue with this and code
along the line of the following (here for scalars, but arrays might cause
additional issues):

type t
end type t
class(t), allocatable :: cx
type(t), allocatable :: ty

allocate(ty, source=cx)
end

Where 'source=' is polymorphic – but the allocated variable is not.
Already without your patch, I see:
   ty = (struct t *) __builtin_malloc (MAX_EXPR <(unsigned long) cx._vptr->_size, 1>);
which may allocate too much. vptr is not set (obviously)
and __vtab_MAIN___T._copy (cx._data, ty); looks fine.

Thus, with the current code, the main issue seems to be only overallocation.

And doing with the code above
   ty = cx
will currently ICE in gfc_allocate_using_malloc (called by trans_class_assignment).

I do not quite see whether those are separate issues or whether they are made
worse (or better?) by your patch.

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter


More information about the Fortran mailing list