https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #16 from Martin Jambor <mjambor at suse dot cz> --- Hi, On Tue, Jun 04 2019, Jan Hubicka wrote: >> >> 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. > > Curiously enough in C version of the LTO testcase I get no warning now > since we simplify function type and thus both pointers are turned into > incomplete pointers and considered TBAA compatible. > After lunch I will check why the warning triggers here. > > Still the alias set is different, so I think we more or less get lucky > by using base+offset tests first since array descriptors are accessed > directly after constant propagation of poointers. >> >> 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 ... > I think Martin's code generally gives up on type mismaches so it > is quite possible it gives up already. I guess I'm missing some context here (and the example above does not contain t1.c?). But I quickly grepped for typec_compatible_p and useless_type_conversion_p in ipa-prop.c (and ipa-cp.c) and the code tries to resolve issues with inserting V_C_E rather than giving up straight away. Martin