Janus Weil wrote:
Ok for trunk?
Sorry for the belated review.
+ bool ptr = sym->attr.pointer || sym->attr.allocatable
+ || (sym->ts.type == BT_CLASS
+ && CLASS_DATA (sym)->attr.class_pointer);
That looks quite imbalanced. Why do you not take care of
CLASS_DATA(sym)->attr.allocatable? Actually, shouldn't that always be
true for BT_CLASS in this context? A BT_CLASS should either be a
pointer/allocatable or a dummy argument - but the latter is never
initialized (while being a dummy).
Otherwise, it looks OK to me.
(Don't forget the dg-do compile -> run change.)
From follow-up emails:
type t
class(*), pointer :: x
end type t
type(t), target :: y
integer,target :: z
type(t) :: x = t(y)
type(t) :: x = t(z)
class(*), pointer :: a => y
Your example yields (with and without the current patch):
type(t) :: x = t(y)
1
Error: Can't convert TYPE(t) to CLASS(*) at (1)
In fact the patch does not really handle unlimited polymorphics. I
suspect several fixes might be needed to get your test case running.
Is it ok to do this in a follow-up patch?
Seems as if there is more work required ... Yes, a follow-up patch is
fine, but somewhere the omission should be recorded. (As you did in
PR49213.)
Talking about the example above, the following is similar and may or may
not be handled:
integer, target :: tgt
type t2
end type t2
type(t2), target :: tgt2
type t
class(*), pointer :: a => tgt
class(*), pointer :: b => tgt2
end type t
type(t) :: x
type(t), SAVE :: y
end
Regarding the example: Does it now work when the target and the pointer are
in the same scoping unit? Or does one still need to place the targets into
the module?
Well, they will work as soon as PR 55207 is fixed (there is a working
patch already, which hopefully can be committed soon).
Good to know that that is already tracked and being fixed.
Tobias
