https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 4 Jun 2019, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 > > --- Comment #12 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- > In libgfortran, we have > > #define GFC_ARRAY_DESCRIPTOR(type) \ > struct {\ > type *base_addr;\ > size_t offset;\ > dtype_type dtype;\ > index_type span;\ > descriptor_dimension dim[];\ > } > > and then later > > typedef GFC_ARRAY_DESCRIPTOR (GFC_INTEGER_4) gfc_array_i4; > > so the array descriptors expected by the libgfotran routines > have a flexible array members. > > If, in the front end, we have the equivalent of (the type name > isn't exactly what the front end generates) > > typedef struct { > GFC_INTEGER_4 *base_addr;\ > size_t offset;\ > dtype_type dtype;\ > index_type span;\ > descriptor_dimension dim[3];\ > } _array03_integer_4_descriptor; > > _array03_integer_4_descriptor my_descriptor; Yeah, I do remember this. I think we settled on the above (previously you had dim[7] in the library I think) to be compatible. Still a C simple testcase complains: typedef struct { int ndim; int dim[]; } *descp; void foo (descp d); void bar() { struct { int ndim; int dim[2]; } desc; desc.ndim = 2; foo (&desc); } t2.c: In function ‘bar’: t2.c:8:8: warning: passing argument 1 of ‘foo’ from incompatible pointer type [-Wincompatible-pointer-types] foo (&desc); ^~~~~ t2.c:2:17: note: expected ‘descp’ {aka ‘struct <anonymous> *’} but argument is of type ‘struct <anonymous> *’ void foo (descp d); ~~~~~~^ and we probably assign different alias sets to both. Now to make aliasing happy both the Frontend and LTO have to compute the same TYPE_CANONICAL for _all_ of the array descriptor types. You can either go and allocate dim always to the max size statically or in the Fortran FE use self-referential types (not sure if you then can statically instantiate an object of such type...) or rewrite all accesses to the fixed-dimension statically allocated array descriptors to go via the dim[] type (I think I suggested the latter elsewhere). So instantiate my_descriptor and then store for further use VIEW_CONVERT_EXPR <generic-descriptor-type> (my_descriptor). I hope that doesn't defeat [IPA] optimization ... > and a pointer type that corresponds to what the library > expects, we should then be able to call > > minloc_... ((gfc_array_i4 *) &my_descriptor, ..) > > right? > > I think this should probably be restricted to calling the > library, I would feel nervous touching use code with this. While that might silence the warning it doesn't solve the TBAA issue that is indeed present -- the populating of the descriptor on the fortran caller side would not alias with reads from the passed descriptor done via the C routine and its descriptor type. In practice we probably see the must-alias relationship and let the TBAA disambiguation possibility unused but I guess we'll quickly get less lucky...