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

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looking at your patch, there is a positive change with your patch, in optimized
dump the z._data store is no longer removed:
 __attribute__((externally_visible))
 integer(kind=4) main (integer(kind=4) argc, character(kind=1) * * argv)
 {
+  struct sq x;
   struct __class__STAR_p z;
   static integer(kind=4) options.0[7] = {2116, 4095, 0, 1, 1, 0, 31};
   integer(kind=4) _7;
@@ -37,6 +38,7 @@ integer(kind=4) main (integer(kind=4) ar
   <bb 2> [local count: 1073741824]:
   _gfortran_set_args (argc_2(D), argv_3(D));
   _gfortran_set_options (7, &options.0[0]);
+  z._data = &x;
   foo (&z);
   _7 = __vtab__STAR._hash;
   if (_7 == 58708456)
@@ -48,6 +50,7 @@ integer(kind=4) main (integer(kind=4) ar
   _gfortran_stop_numeric (1, 0);

   <bb 4> [local count: 1073441178]:
+  x ={v} {CLOBBER(eol)};
   z ={v} {CLOBBER(eol)};
   return 0;
But yes, it is still not enough.
If I use -Os -fno-tree-dse rather than -Os with your patch, the incremental
difference in optimized dump is:
--- unlimited_polymorphic_3.f03.252t.optimized  2022-04-19 15:32:50.716092070
+0200
+++ unlimited_polymorphic_3.f03.252t.optimized  2022-04-19 15:33:07.994850946
+0200
@@ -1,4 +1,17 @@

+;; Function __copy_main_Sq (__copy_main_Sq.0, funcdef_no=2, decl_uid=4241,
cgraph_uid=2, symbol_order=2)
+
+__attribute__((fn spec (". r w ")))
+void __copy_main_Sq (struct sq & restrict src, struct sq & restrict dst)
+{
+  <bb 2> [local count: 1073741824]:
+  *dst_2(D) = *src_3(D);
+  return;
+
+}
+
+
+
 ;; Function foo (foo_, funcdef_no=0, decl_uid=4226, cgraph_uid=1,
symbol_order=1)

 __attribute__((fn spec (". r ")))
@@ -32,12 +45,16 @@ integer(kind=4) main (integer(kind=4) ar
 {
   struct sq x;
   struct __class__STAR_p z;
+  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 integer(kind=4) options.0[7] = {2116, 4095, 0, 1, 1, 0, 31};
   integer(kind=4) _7;

   <bb 2> [local count: 1073741824]:
   _gfortran_set_args (argc_2(D), argv_3(D));
   _gfortran_set_options (7, &options.0[0]);
+  x.i = 42;
+  z._vptr = &__vtab_main_Sq;
+  z._len = 0;
   z._data = &x;
   foo (&z);
   _7 = __vtab__STAR._hash;

I think the _vptr and _len fields aren't ever read and so it is ok the stores
to them are optimized away, so I think it is the x.i = 42; store.