http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57590
janus at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |wrong-code CC| |janus at gcc dot gnu.org Summary|[OOP] class containers are |[OOP] wrong code with class |recycled between symbols |variables of different |more than they should be |shapes --- Comment #3 from janus at gcc dot gnu.org --- (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?). As the dump shows, we set up a proper array descriptor for _data anyway, we just need to use it: { struct array1_t parm.15; struct __class_MAIN___T_1_0 class.14; class.14._vptr = (struct __vtype_MAIN___T * {ref-all}) &__vtab_MAIN___T; parm.15.dtype = 41; parm.15.dim[0].lbound = 1; parm.15.dim[0].ubound = 5; parm.15.dim[0].stride = 1; parm.15.data = (void *) &c[0]; parm.15.offset = -1; class.14._data = parm.15; s5 (&class.14); } Maybe one can even get rid of the different class containers for different ranks if one uses AS_ASSUMED_RANK?