Hi, > 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).
right. Then it should be ok to just check for BT_CLASS. Updated patch attached. > Otherwise, it looks OK to me. Thanks. I will commit the attached version after another regtest. > (Don't forget the dg-do compile -> run change.) Done. > 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 In addition to the can't-convert error, this one also gives integer, target :: tgt 1 Internal Error at (1): but I don't directly see why. I will also add it to the above PR to keep track of it. Cheers, Janus
pr57306_v5.diff
Description: Binary data
pointer_init_8.f90
Description: Binary data