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).