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

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

[hubicka at gcc dot gnu.org]

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.

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

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
With this patch
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586644.html
we misoptimize unmodified testcase with -Os

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jan Hubicka <hubicka@gcc.gnu.org>:

https://gcc.gnu.org/g:3305135c29e1c3e988bd9bad40aefc01d138aaca

commit r12-5960-g3305135c29e1c3e988bd9bad40aefc01d138aaca
Author: Jan Hubicka <jh@suse.cz>
Date:   Tue Dec 14 16:50:27 2021 +0100

    Determine global memory accesses in ipa-modref

    As discussed in PR103585, fatigue2 is now only benchmark from my usual
testing
    set (SPEC2k6, SPEC2k17, CPP benchmarks, polyhedron, Firefox, clang) which
sees
    important regression when inlining functions called once is limited.  This
    prevents us from solving runtime issues in roms benchmarks and elsewhere.

    The problem is that there is perdida function that takes many arguments and
    some of them are array descriptors.  We constant propagate most of their
fields
    but still keep their initialization. Because perdida is quite fast, the
call
    overhead dominates, since we need over 100 memory stores consuing about 35%
    of the overall benchmark runtime.

    The memory stores would be eliminated if perdida did not call fortran I/O
which
    makes modref to thin that the array descriptors could be accessed. We are
    quite close discovering that they can't becuase they are non-escaping from
    function.  This patch makes modref to distingush between global memory
access
    (only things that escapes) and unkonwn accesss (that may access also
    nonescaping things reaching the function).  This makes disambiguation for
    functions containing error handling better.

    Unfortunately the patch hits two semi-latent issues in Fortran frontned.
    First is wrong code in gfortran.dg/unlimited_polymorphic_3.f03. This can be
    turned into wrong code testcase on both mainline and gcc11 if the runtime
    call is removed, so I filled PR 103662 for it. There is TBAA mismatch for
    structure produced in FE.

    Second is issue with GOMP where Fortran marks certain parameters as
non-escaping
    and then makes them escape via GOMP_parallel.  For this I disabled the use
of
    escape info in verify_arg which also disables the useful transform on
perdida
    but still does useful work for e.g. GCC error handling.  I will work on
this
    incrementally.

    Bootstrapped/regtested x86_64-linux, lto-bootstrapped and also tested with
    clang build.  I plan to commit this tomorrow if there are no complains
    (the patch is not completely short but conceptualy simple and handles a lot
    of common cases).

    gcc/ChangeLog:

    2021-12-12  Jan Hubicka  <hubicka@ucw.cz>

            PR ipa/103585
            * ipa-modref-tree.c (modref_access_node::range_info_useful_p):
Handle
            MODREF_GLOBAL_MEMORY_PARM.
            (modref_access_node::dump): Likewise.
            (modref_access_node::get_call_arg): Likewise.
            * ipa-modref-tree.h (enum modref_special_parms): Add
            MODREF_GLOBAL_MEMORY_PARM.
            (modref_access_node::useful_for_kill): Handle
            MODREF_GLOBAL_MEMORY_PARM.
            (modref:tree::merge): Add promote_unknown_to_global.
            * ipa-modref.c (verify_arg):New function.
            (may_access_nonescaping_parm_p): New function.
            (modref_access_analysis::record_global_memory_load): New member
            function.
            (modref_access_analysis::record_global_memory_store): Likewise.
            (modref_access_analysis::process_fnspec): Distingush global and
local
            memory.
            (modref_access_analysis::analyze_call): Likewise.
            * tree-ssa-alias.c (ref_may_access_global_memory_p): New function.
            (modref_may_conflict): Use it.

    gcc/testsuite/ChangeLog:

    2021-12-12  Jan Hubicka  <hubicka@ucw.cz>

            * gcc.dg/analyzer/data-model-1.c: Disable ipa-modref.
            * gcc.dg/uninit-38.c: Likewise.
            * gcc.dg/uninit-pr98578.c: Liewise.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Can you explain in simple words why adding

  if (ptr1%k .ne. 42) print *

before the line

  if (ptr1%k .ne. 42) STOP 2

makes the test succeed, but adding it after that one the test fails?
Or adding

  print *, ptr1%k

near the end of subroutine foo?

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

[hubicka at kam dot mff.cuni.cz]

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

--- Comment #4 from hubicka at kam dot mff.cuni.cz ---
> Can you explain in simple words why adding
> 
>   if (ptr1%k .ne. 42) print *
> 
> before the line
> 
>   if (ptr1%k .ne. 42) STOP 2
> 
> makes the test succeed, but adding it after that one the test fails?
> Or adding
> 
>   print *, ptr1%k
> 
> near the end of subroutine foo?
I am not sure why it depends whether it is before or after the stop.
Perhaps we thread the conditionals and optimize out print in some cases?
However the reason why print matters is because print call confuses the
simplistic escape analysis done in modref.  It now understand the fact
that calling an unknown function where all arguments are constant is
safe and can not make function local parameters escaped.  However it
punt on calling anything with parameter.  Before the patch the same
testcase fails if you replace STOP 2 by anything that terminate program
w/o calling function. For example by division by zero.

I have patch to use PTA escape analysis in modref but it hits other
problem with fortran FE and openMP - GOMP_parallel makes parameters
escape even if Fortran FE produces fnspec delcaring them nonescape...

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

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seurer at gcc dot gnu.org

--- Comment #5 from seurer at gcc dot gnu.org ---
r12-5960 causes an issue at least on powerpc64.

g:3305135c29e1c3e988bd9bad40aefc01d138aaca, r12-5960
make  -k check-gcc-fortran
RUNTESTFLAGS="dg.exp=gfortran.dg/unlimited_polymorphic_3.f03"
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -Os  execution test
# of expected passes            11
# of unexpected failures        1


spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03
-fdiagnostics-plain-output -fdiagnostics-plain-output -Os -pedantic-errors
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./unlimited_polymorphic_3.exe
PASS: gfortran.dg/unlimited_polymorphic_3.f03   -Os  (test for excess errors)
. . .
Execution timeout is: 300
spawn [open ...]
STOP 2
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -Os  execution test

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

[clyon at gcc dot gnu.org]

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

Christophe Lyon <clyon at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clyon at gcc dot gnu.org

--- Comment #6 from Christophe Lyon <clyon at gcc dot gnu.org> ---
(In reply to seurer from comment #5)
> r12-5960 causes an issue at least on powerpc64.

same problem on arm & aarch64

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-01-04
           Keywords|                            |wrong-code

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|TBAA problem in Fortran FE  |[12 Regression] TBAA
                   |triggering in               |problem in Fortran FE
                   |gfortran.dg/unlimited_polym |triggering in
                   |orphic_3.f03                |gfortran.dg/unlimited_polym
                   |                            |orphic_3.f03
   Target Milestone|---                         |12.0

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm marking it as a regression, note the "mistake" in the frontend generated
code is latent.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm inclined to make this P1 even though it is gfortran only.  As a last resort
it should work to make the receiver side a ref-all pointer.

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

[hubicka at kam dot mff.cuni.cz]

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

--- Comment #9 from hubicka at kam dot mff.cuni.cz ---
> I'm inclined to make this P1 even though it is gfortran only.  As a last resort
> it should work to make the receiver side a ref-all pointer.
Yes, I also think this is important bug (like all TBAA related wrong
codes).  Getting alias set 0 to the receiver is probably doable even
with my Fortran frontend knowledge, but I would like to understand why
the types are not matching which I don't.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>From what I can see, for normal derived types resolve_symbol calls
resolve_fl_derived -> resolve_fl_derived0 -> add_dt_to_dt_list
which ensures that the derived type eventually makes it into ns->derived_types
and then gfc_get_derived_type will do:
  /* The derived types from an earlier namespace can be used as the
     canonical type.  */
  if (derived->backend_decl == NULL
      && !derived->attr.use_assoc
      && !derived->attr.used_in_submodule
      && gfc_global_ns_list)
    {
      for (ns = gfc_global_ns_list;
           ns->translated && !got_canonical;
           ns = ns->sibling)
        {
          if (ns->derived_types)
            {
              for (gfc_symbol *dt = ns->derived_types; dt && !got_canonical;
                   dt = dt->dt_next)
                {
                  gfc_copy_dt_decls_ifequal (dt, derived, true);
                  if (derived->backend_decl)
                    got_canonical = true;
                  if (dt->dt_next == ns->derived_types)
                    break;
                }
            }
        }
    }
(ugh, linear walk of all namespaces and all derived types in them!  A hash
table would be much better) will find matching derived type in some other
namespace
and if it has backend_decl, will use it as TYPE_CANONICAL.
All of resolve_symbol and resolve_fl_derived and resolve_fl_derived0 have an
early exit for sym->attr.unlimited_polymorphic,
so add_dt_to_dt_list isn't done for it but that isn't a big deal because
gfc_get_derived_type for derived->attr.unlimited_polymorphic just returns
ptr_type_node (the same in all namespaces).

But __class__STAR_p symbol isn't unlimited_polymorphic, but in
resolve_fl_derive we trigger:
  if (sym->attr.is_class && sym->ts.u.derived == NULL)
    {
      /* Fix up incomplete CLASS symbols.  */
      gfc_component *data = gfc_find_component (sym, "_data", true, true,
NULL);
      gfc_component *vptr = gfc_find_component (sym, "_vptr", true, true,
NULL);

      /* Nothing more to do for unlimited polymorphic entities.  */
      if (data->ts.u.derived->attr.unlimited_polymorphic)
        return true;
and so don't call resolve_fl_derived0, neither for sym nor for vptr, so never
call add_dt_to_dt_list for __class__STAR_p
and so gfc_get_derived_type for those will always set TYPE_CANONICAL to itself,
so each namespace's __class__STAR_p is considered to be private for TBAA
purposes.

--- gcc/fortran/resolve.cc.jj   2022-03-21 11:00:06.447824689 +0100
+++ gcc/fortran/resolve.cc      2022-03-22 12:35:38.381250338 +0100
@@ -15138,7 +15138,10 @@ resolve_fl_derived (gfc_symbol *sym)

       /* Nothing more to do for unlimited polymorphic entities.  */
       if (data->ts.u.derived->attr.unlimited_polymorphic)
-       return true;
+       {
+         add_dt_to_dt_list (sym);
+         return true;
+       }
       else if (vptr->ts.u.derived == NULL)
        {
          gfc_symbol *vtab = gfc_find_derived_vtab (data->ts.u.derived);
doesn't help much though, while it registers __class_STAR_p,
gfc_get_derived_type -> gfc_copy_dt_decls_ifequal -> gfc_compare_derived_types
considers them unequal.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
gfc_get_derived_type sets the unlimited_entity flag for these, but I guess not
all unlimited entities should have the same TYPE_CANONICAL, e.g. on
subroutine foo (a, b, c, d, e, f)
  class(*) :: a
  class(*) :: b(:)
  class(*) :: c(:, :, :)
  class(*), pointer :: d
  class(*), pointer :: e(:)
  class(*), pointer :: f(:, :)
end subroutine
there are various RECORD_TYPEs.
So just adding a single tree to use for those would be wrong, thus I think
best would be really to register the unlimited entities in the derived type
list and handle them in gfc_compare_derived_types.  But I'm afraid I don't know
enough about this stuff to do this myself.

Tobias or Paul, could you please have a look?
This is a P1 bug and therefore GCC 12 blocker.

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

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #12 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 52828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52828&action=edit
Fix attempt

I think the attached patch avoids the multiple declarations for __class_STAR_p,
but the testsuite FAIL remains, so I must be missing important.
Is there a -fdump-tree-types or something so that the problem can be seen in
dumps (both for eyeballing and for matching with the testsuite)?

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

[mikael at gcc dot gnu.org]

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

--- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #12)
> ... so I must be missing important.

I must be missing *something* important.

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

[jakub at gcc dot 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.

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

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Putting a breakpoint on new_alias_set, I see that
RECORD_TYPE sq gets alias set 1
RECORD_TYPE s gets alias set 9
RECORD_TYPE t gets alias set 10

Those are
  type sq
    sequence
    integer :: i
  end type sq
and
  type, bind(c) :: s
    integer (c_int) :: k
  end type s
  type t
    sequence
    integer :: k
  end type t
in the testcase.  The testcase stores through the sq type and reads through
pointer to s and pointer to t type.  As the alias sets are different, for the
middle-end the testcase is invalid.
Now, the question is what is the Fortran unlimited polymorphic semantics, if
one can store through one type and read through a different type which just has
the same layout, or if it also has to use the same name etc., or if it is even
acceptable to store through say a type with a pair of integers and read through
a type with double precision etc.
GCC has types that can alias anything, so if the semantics is like that,
unlimited polymorphic middle-end pointers perhaps should use that.
Or the testcase is invalid and has to use type sq in foo as well.  Or we need
to ensure sq and s/t above have the same alias set.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #12)
> Created attachment 52828 [details]
> Fix attempt
> 
> I think the attached patch avoids the multiple declarations for
> __class_STAR_p,
> but the testsuite FAIL remains, so I must be missing important.
> Is there a -fdump-tree-types or something so that the problem can be seen in
> dumps (both for eyeballing and for matching with the testsuite)?

I agree with Jakub that this is good progression so we should probably get this
to a shape that is committable and commit it.

Btw - thanks for working on the Fortran frontend issues!

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

[mikael at gcc dot gnu.org]

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

--- Comment #17 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #15)
> Now, the question is what is the Fortran unlimited polymorphic semantics, if
> one can store through one type and read through a different type which just
> has the same layout, or if it also has to use the same name etc., or if it
> is even acceptable to store through say a type with a pair of integers and
> read through a type with double precision etc.

I think the pointer assignments in foo are invalid:


10.2.2.3 Data pointer assignment
… If the pointer object is of a type with the BIND attribute or the SEQUENCE
attribute, the dynamic type of the pointer target shall be that type.

 => the dynamic type of tgt shall be respectively s and t

7.3.2.3 CLASS type specifier
… The dynamic type of an associated polymorphic pointer is the dynamic type of
its target.

 => the dynamic type of tgt is that of z
 => the dynamic type of z is that of y
 => the dynamic type of y is that of x, which is sq

7.5.2.4 Determination of derived types
… Data entities also have the same type if they are declared with reference to
different derived-type definitions that specify the same type name, all have
the SEQUENCE attribute or all have the BIND attribute, have no components with
PRIVATE accessibility, and have components that agree in order, name, and
attributes. Otherwise, they are of different derived types.

 => sq and s are different types (different component name)
 => sq and t are different types (different component name, bind(c), sequence)
 => s and t are different types (bind(c), sequence)


So ptr1 and ptr2 should either have type sq, or s and t should be changed to be
"compatible" with sq. And "compatible" is defined in the 7.5.2.4 excerpt above.

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

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
! { dg-do run }
!
! Check that pointer assignments allowed by F2003:C717
! work and check null initialization of CLASS(*) pointers.
!
! Contributed by Tobias Burnus <burnus@gcc.gnu.org>
!
program main
  interface
    subroutine foo(z)
      class(*), pointer, intent(in) :: z
    end subroutine foo
  end interface
  type sq
    sequence
    integer :: i
  end type sq
  type(sq), target :: x
  class(*), pointer :: y, z
  x%i = 42
  y => x
  z => y ! unlimited => unlimited allowed
  call foo (z)
  call bar
contains
  subroutine bar
    type t
    end type t
    type(t), pointer :: x
    class(*), pointer :: ptr1 => null() ! pointer initialization
    if (same_type_as (ptr1, x) .neqv. .FALSE.) STOP 1
  end subroutine bar

end program main


subroutine foo(tgt)
  class(*), pointer, intent(in) :: tgt
  type sq
    sequence
    integer :: i
  end type sq
  type(sq), pointer :: ptr
  ptr => tgt ! sequence type => unlimited allowed
  if (ptr%i .ne. 42) STOP 2
end subroutine foo

works with your patch and doesn't without it.
But, if I change sq in foo to s, it doesn't work anymore.  Though, seems even
type name and all member names are important, so I think we should just
change the testcase to the above and perhaps add another one with bind(c)
derived type instead of the sequence one.

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

[hubicka at kam dot mff.cuni.cz]

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

--- Comment #19 from hubicka at kam dot mff.cuni.cz ---
> I agree with Jakub that this is good progression so we should probably get this
> to a shape that is committable and commit it.
> 
> Btw - thanks for working on the Fortran frontend issues!
Indeed! This bug was haunting me for a while :)

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:fa5cd7102da676dcb1757b1288421f5f3439ae0e

commit r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Sun Apr 24 15:05:41 2022 +0200

    fortran: Detect duplicate unlimited polymorphic types [PR103662]

    This fixes a type-based alias analysis issue with unlimited polymorphic
    class descriptors (types behind class(*)) causing data initialisation to
    be removed by optimization.

    The fortran front-end may create multiple declarations for types, for
    example if a type is redeclared in each program unit it is used in.
    To avoid optimization seeing them as non-aliasing, a list of derived
    types is created at resolution time, and used at translation to set
    the same TYPE_CANONICAL type for each duplicate type declaration.

    This mechanism didnât work for unlimited polymorphic descriptors types,
    as there is a short-circuit return skipping all the resolution handling
    for them, including the type registration.

    This change adds type registration at the short-circuit return, and
    updates type comparison to handle specifically unlimited polymorphic
    fake symbols, class descriptor types and virtual table types.

    The test, which exhibited mismatching dynamic types had to be fixed as
    well.

            PR fortran/103662

    gcc/fortran/ChangeLog:

            * interface.cc (gfc_compare_derived_types): Support comparing
            unlimited polymorphic fake symbols.  Recursively compare class
            descriptor types and virtual table types.
            * resolve.cc (resolve_fl_derived): Add type to the types list
            on unlimited polymorphic short-circuit return.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/unlimited_polymorphic_3.f03 (foo): Separate
            bind(c) and sequence checks to...
            (foo_bc, foo_sq): ... two different procedures.
            (main, foo*): Change type declarations so that type name,
            component name, and either bind(c) or sequence attribute match
            between the main type declarations and the procedure type
            declarations.
            (toplevel): Add optimization dump checks.

    Co-Authored-By: Jakub Jelinek <jakub@redhat.com>

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:6cc26f3037a18b9a958b4ac2a1363149a7fccd39

commit r12-8243-g6cc26f3037a18b9a958b4ac2a1363149a7fccd39
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Mon Apr 25 13:14:20 2022 +0200

    testsuite: add additional option to force DSE execution [PR103662]

    This fixes a dump tree match check that is UNRESOLVED with the -O0
    optimization option, as the optimization pass corresponding to the
    dump file is not run at -O0, and the dump is not generated.

            PR fortran/103662

    gcc/testsuite/ChangeLog:

            * gfortran.dg/unlimited_polymorphic_3.f03: Force execution of
            the DSE optimization pass.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:22c24ba48a20a4944a50cca06449debed7d1b3f4

commit r12-8260-g22c24ba48a20a4944a50cca06449debed7d1b3f4
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 26 09:17:32 2022 +0200

    testsuite: Improve unlimited_polymorphic_3.f03 [PR103662]

    On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
    > I have just pushed the attached fix for two UNRESOLVED checks at -O0 that
I
    > hadnât seen.

    I don't like forcing of DSE in -O0 compilation, wouldn't it be better
    to just not check the dse dump at -O0 like in the following patch?

    Even better would be to check that the z._data = stores are both present
    in *.optimized dump, but that doesn't really work at -O2 or above because
    we inline the functions and optimize it completely away (both the stores
    and corresponding reads).

    The first hunk is needed so that __OPTIMIZE__ effective target works in
    Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
    is considered not to match at all.

    2022-04-26  Jakub Jelinek  <jakub@redhat.com>

            PR fortran/103662
            * lib/target-supports.exp (check_effective_target___OPTIMIZE__):
Add
            a var definition to avoid pedwarn about empty translation unit.
            * gfortran.dg/unlimited_polymorphic_3.f03: Remove -ftree-dse from
            dg-additional-options, guard scan-tree-dump-not directives on
            __OPTIMIZE__ target.

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

[hubicka at kam dot mff.cuni.cz]

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

--- Comment #24 from hubicka at kam dot mff.cuni.cz ---
Thanks a lot!
Honza

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #25 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:

https://gcc.gnu.org/g:6a460a2007dd9c527c5f9d5bbbedb852db7c1373

commit r12-8281-g6a460a2007dd9c527c5f9d5bbbedb852db7c1373
Author: Mikael Morin <mikael@gcc.gnu.org>
Date:   Wed Apr 27 11:36:16 2022 +0200

    fortran: Compare non-constant bound expressions. [PR105379]

    Starting with r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e,
    class descriptor types are compared to detect duplicate declarations.

    This caused ICEs as the comparison of array spec supported only constant
    explicit bounds, but dummy class variable descriptor types can have a
    _data field with non-constant array spec bounds.

    This change adds support for non-constant bounds.  For that,
    gfc_dep_compare_expr is used.  It does probably more than strictly
    necessary, but using it avoids rewriting a specific comparison function,
    making mistakes and forgetting cases.

            PR fortran/103662
            PR fortran/105379

    gcc/fortran/ChangeLog:

            * array.cc (compare_bounds): Use bool as return type.
            Support non-constant expressions.
            (gfc_compare_array_spec): Update call to compare_bounds.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/class_dummy_8.f90: New test.
            * gfortran.dg/class_dummy_9.f90: New test.