[Bug fortran/57590] [OOP] wrong code with class variables of different shapes

["mikael at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57590

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to janus from comment #3)
> (In reply to Mikael Morin from comment #0)
> > Every of the 'a' dummy argument should have its own class container type.
> > This means that we have to discriminate not only on the array spec type, but
> > also for AS_EXPLICIT on the bounds, and on the bounds' expressions (in the
> > 'sn' case).
> 
> I think in general it's ok to use the same class container type for all of
> them, but we should not fix the array spec of the _data component at compile
> time (but use something like AS_ASSUMED_SHAPE instead?).
OK, makes some sense.
But then we have to keep the original array spec somewhere.

What we can do:
 (1) Store array spec, pointer etc in the class container using
     attr->class_pointer, class_as, etc fields different from the regular
     attr->pointer, as, etc.
     This is currently done for attr->pointer, we need to extend it to as,
     attr->dimension, attr->codimension, attr.allocatable.
     Then, the code generation has to test for attr->is_class or something
     to know whether to use foo or class_foo.

 (2) Keep the fields in their original location, that is don't clear as,
     attr->pointer, attr->allocatable, attr->dimension, attr->codimension
     in gfc_build_class_symbol.
     This as the benefit over (1) of not needing extra room, and avoiding
     the foo->attr->bar vs CLASS_DATA(foo)->attr->bar vs
     CLASS_DATA(foo)->attr->class_bar hell.
     It needs basically the same adjustments at translation stage to not
     use the array spec etc of a class container.

The two above need some adjustements at translation stage, which defeats the
purpose of generating the class container using front-end structures only.
Thus, I'm more in favor of (3):
 (3) Don't use gfc_build_class_symbol, or delay it as much as possible until 
     code generation.  We are all dreamers, aren't we ? ;-)

> 
> As the dump shows, we set up a proper array descriptor for _data anyway, we
> just need to use it:
Hm, no; we just need to not clear the original array spec, or keep it somewhere
so that we can use it.  The original array spec is a constant, while data
loaded from the descriptor is not, until some middle-end inter process
optimizations guessed otherwise.

> 
> Maybe one can even get rid of the different class containers for different
> ranks if one uses AS_ASSUMED_RANK?
I think it's better for the middle-end to have types as much separated as
possible.  Unless of course we are forced to have the same type (as in
pr57297).