[Bug fortran/103662] New: TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

[hubicka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662

            Bug ID: 103662
           Summary: TBAA problem in Fortran FE triggering in
                    gfortran.dg/unlimited_polymorphic_3.f03
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

In this testcase we have:

void foo (struct __class__STAR_p & restrict tgt)
{
  struct s * ptr1;
  integer(kind=4) _1;

  <bb 2> [local count: 1073741824]:
  ptr1_4 = *tgt_3(D)._data;
  _1 = *ptr1_4.k;
  if (_1 != 42)
    goto <bb 3>; [0.04%]
  else
    goto <bb 4>; [99.96%]

  <bb 3> [local count: 429496]:
  _gfortran_stop_numeric (2, 0);

  <bb 4> [local count: 1073312329]:
  return;

}

The load ptr1_4 = *tgt_3(D)._data has alias sets:
 - Analyzing load: *tgt_3(D)._data
   - Recording base_set=9 ref_set=5  Parm 0 param offset:0 offset:0 size:64
max_size:64
 - Analyzing load: *ptr1_4.k
   - Recording base_set=11 ref_set=2 

Now the value is set in main:

void MAIN__ ()
{
  integer(kind=8) y$_len;
  struct __vtype__STAR * {ref-all} y$_vptr;
  void * y$_data;
  struct __class__STAR_p z;
  struct __class__STAR_p y;
  struct sq x;
  static struct __vtype_main_Sq __vtab_main_Sq = {._hash=85658372, ._size=4,
._extends=0B, ._def_init=&__def_init_main_Sq, ._copy=__copy_main_Sq,
._final=0B, ._deallocate=0B};
  static struct sq __def_init_main_Sq;

  <bb 2> [local count: 1073741824]:
  x.i = 42;
  z._vptr = &__vtab_main_Sq;
  z._len = 0;
  z._data = &x;
  foo (&z);
  bar ();
  x ={v} {CLOBBER};
  y ={v} {CLOBBER};
  z ={v} {CLOBBER};
  return;

}

here however the z._data store is:
ipa-modref: call stmt foo (&z);                                                 
ipa-modref: call to foo/0 does not use ref: z._data alias sets: 4->5            
  Deleted dead store: z._data = &x;                                             

So it has base alias set 4 which is not considered aliasing with alias set 9. 
With mainline version of modref we do not perform the optimization because we
are paranoid about _gfortran_stop_numeric (2, 0); possibly accessing something.
If this is replaced by code that does not perform call we get wrong code with
-Os.

So __class__STAR_p is produced twice while it should not be.