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
