http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53971
Bug #: 53971 Summary: [OOP] Class container - reverse order of _vtab and _data Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Created attachment 27798 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27798 Draft patch - should be sufficient, but isn't. The main purpose of the proposed change is the handling of assumed-rank arrays, both implementation wise and by allowing to bump the MAX_DIMENSION without breaking the ABI. The attached patch should be sufficient, but it causes many test suite failures, e.g. by having a __vtype in the call to class.c's find_typebound_proc_uop. For that argument, derived->f2k_derived == NULL, which triggers an assert for gfortran.dg/abstract_type_6.f03. Currently, the first element in a class container is _data, followed by _vptr. _data can be either directly a memory address or array descriptor of rank n. Hence, the byte-offset between the base address of the class container and the _vptr depends on the kind of data (normal scalar vs. array) and the rank. For assumed-shape arrays, that implies that one always needs to have an array descriptor of MAX_DIMENSION – and changing MAX_DIMENSION will break the arrays. If one reorder _vptr and _data, _vptr can be always accessed and one can directly pass class containers (with descriptor) of any rank – the size of the array container is then known at run time based on the rank information. In C syntax, that's { void *_vpt; { /* First fields of the array descriptor. */ array_dim_triplet dim[ ]; } } Where the "[ ]" allows for different lengths; it is created by creating a tree-decl for an array of size 0. The current assumed-rank patch, has always MAX_DIMENSION and copies all fields including the dimension triplet (the latter via range-ref) over.