Re: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array

[Andre Vehreschild <vehre@gmx.de>]

Hi Mikael, 

> This pointer stuff is very difficult to swallow to me.

I totally understand. When doing the patch I had to restart twice, because I
mixed up the development on the class arrays so completely, that I couldn't get
it right again.

> I understand that for classes, the CLASS_DATA (sym)->pointer is always
> set, but almost everywhere the checks for pointerness are like
>   (sym->ts.type != BT_CLASS && sym->attr.pointer)
>   || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.class_pointer)
> and I don't see a convincing reason to have it different here.

I see your point. Currently I am bootstraping and regtesting some patches for
commit. While this is running, my machine is nearly unusable. I will look into
this as soon, as my machine allows, but probably not before tomorrow.
 
> At least gfc_is_nodesc_array should return 0 if sym->ts.type == BT_CLASS
> which solves the problem there; for the other cases, I think that
> class_pointer should be looked at.  gfc_build_class_symbol  clears the
> sym->attr.pointer flag for class containers so it doesn't make sense to
> test that flag.

Completely right again. But I figured, that because sym->attr.pointer is never
set for BT_CLASS there is no harm to check it and furthermore no need to guard
it by checking whether ts.type == BT_CLASS. Fortunately not checking for
class_pointer in _data's attr, didn't throw any regressions. Thinking about it
now, I also think that it is probably safer to add the check for the
class_pointer attribute were attr.pointer is checked on the sym, having the
expression like you pointed out:

>   (sym->ts.type != BT_CLASS && sym->attr.pointer)
>   || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.class_pointer)

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de