[Bug fortran/97652] New: New pdt14 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[Bug fortran/97652] New: New pdt14 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[hubicka at gcc dot gnu.org]

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

            Bug ID: 97652
           Summary: New pdt14 failure after
                    g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

pdt14 is miscompiled with -fipa-modref.  This is triggered by handling fnspec,
but it seems to only trigger latent problem.

The only disambiguations are:
ipa-modref: call stmt push_8 (&root, &C.4105);
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (&root, &C.4104);
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (&root, &C.4103);
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (&root, &C.4105);
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (&root, &C.4104);
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (&root, &C.4103);
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11

these ought to be safe since __vtab_link_module_Pdtlink_8 is readonly in the
testcase. With LTO we detect that variable as such (and the testcase stil work
without modref and fails different with modref).

fre3 does quite a lot of additional changes and I am not sure what gets wrong
here:

 __attribute__((externally_visible))
 main (integer(kind=4) argc, character(kind=1) * * argv)
 {
+  struct array01_unknown cdesc.10;
+  struct array01_unknown cdesc.9;
+  real(kind=8) res;
+  struct Pdtlink_8 * previous;
+  struct Pdtlink_8 * current;
+  real(kind=8) res;
   struct pdtlink_8 * root;
   static integer(kind=4) options.11[7] = {2150, 4095, 1, 1, 1, 0, 31};
-  real(kind=8) _7;
-  integer(kind=4) _8;
-  real(kind=8) _9;
-  integer(kind=4) _10;
-  real(kind=8) _11;
-  integer(kind=4) _12;
-  real(kind=8) _13;
-  integer(kind=4) _14;
+  struct Pdtlink_8 * _15;
+  struct Pdtlink_8 * _17;
+  struct Pdtlink_8 * _21;
+  struct Pdtlink_8 * _22;
+  void (*<T5d4>) () _23;
+  struct Pdtlink_8 * _25;
+  void (*<T5d4>) () _26;

   <bb 2> [local count: 1073741824]:
   _gfortran_set_args (argc_2(D), argv_3(D));
@@ -1972,52 +2120,75 @@
   push_8 (&root, &C.4103);
   push_8 (&root, &C.4104);
   push_8 (&root, &C.4105);
-  _7 = pop_8 (&root);
-  _8 = (integer(kind=4)) _7;
-  if (_8 != 3)
-    goto <bb 3>; [0.04%]
+  _15 = MEM[(struct Pdtlink_8 * &)&root];
+  if (_15 != 0B)
+    goto <bb 3>; [70.00%]
   else
-    goto <bb 4>; [99.96%]
+    goto <bb 11>; [30.00%]

-  <bb 3> [local count: 429496]:
-  _gfortran_stop_numeric (1, 0);
-
-  <bb 4> [local count: 1073312329]:
-  _9 = pop_8 (&root);
-  _10 = (integer(kind=4)) _9;
-  if (_10 != 2)
-    goto <bb 5>; [0.04%]
+  <bb 3> [local count: 75913541732]:
+  # current_16 = PHI <_15(2), _17(3)>
+  # previous_29 = PHI <_15(2), current_16(3)>
+  _17 = current_16->next;
+  if (_17 == 0B)
+    goto <bb 4>; [0.00%]
   else
-    goto <bb 6>; [99.96%]
-
-  <bb 5> [local count: 429324]:
-  _gfortran_stop_numeric (2, 0);
+    goto <bb 3>; [100.00%]

-  <bb 6> [local count: 1072883005]:
-  _11 = pop_8 (&root);
-  _12 = (integer(kind=4)) _11;
-  if (_12 != 1)
-    goto <bb 7>; [0.04%]
+  <bb 4> [count: 0]:
+  res_19 = current_16->n;
+  _21 = previous_29->next;
+  if (_21 == 0B)
+    goto <bb 5>; [30.00%]
   else
-    goto <bb 8>; [99.96%]
+    goto <bb 8>; [70.00%]

-  <bb 7> [local count: 429152]:
-  _gfortran_stop_numeric (3, 0);
+  <bb 5> [count: 0]:
+  _22 = _15->next;
+  if (_22 != 0B)
+    goto <bb 6>; [70.00%]
+  else
+    goto <bb 7>; [30.00%]

-  <bb 8> [local count: 1072453853]:
-  _13 = pop_8 (&root);
-  _14 = (integer(kind=4)) _13;
-  if (_14 != 0)
-    goto <bb 9>; [0.04%]
+  <bb 6> [count: 0]:
+  MEM <c_char[8]> [(struct dtype_type *)&cdesc.9 + 24B] = {};
+  cdesc.9.dtype.elem_len = 24;
+  cdesc.9.dtype.rank = 1;
+  cdesc.9.dtype.type = 11;
+  cdesc.9.dim[0].lbound = 1;
+  cdesc.9.dim[0].stride = 1;
+  cdesc.9.dim[0].ubound = 1;
+  cdesc.9.data = _22;
+  _23 = __vtab_link_module_Pdtlink_8._deallocate;
+  __builtin_unreachable ();
+
+  <bb 7> [count: 0]:
+  __builtin_unreachable ();
+
+  <bb 8> [count: 0]:
+  _25 = _21->next;
+  if (_25 != 0B)
+    goto <bb 9>; [70.00%]
   else
-    goto <bb 10>; [99.96%]
+    goto <bb 10>; [30.00%]
+
+  <bb 9> [count: 0]:
+  MEM <c_char[8]> [(struct dtype_type *)&cdesc.10 + 24B] = {};
+  cdesc.10.dtype.elem_len = 24;
+  cdesc.10.dtype.rank = 1;
+  cdesc.10.dtype.type = 11;
+  cdesc.10.dim[0].lbound = 1;
+  cdesc.10.dim[0].stride = 1;
+  cdesc.10.dim[0].ubound = 1;
+  cdesc.10.data = _25;
+  _26 = __vtab_link_module_Pdtlink_8._deallocate;
+  __builtin_unreachable ();

-  <bb 9> [local count: 428981]:
-  _gfortran_stop_numeric (4, 0);
+  <bb 10> [count: 0]:
+  __builtin_unreachable ();

-  <bb 10> [local count: 1072024872]:
-  root ={v} {CLOBBER};
-  return 0;
+  <bb 11> [local count: 128815]:
+  _gfortran_stop_numeric (1, 0);

[Bug fortran/97652] New pdt14 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Actually there is another propagation happening in ipa-cp analysis:

--- aa/pdt_14.f03.077i.cp       2020-10-31 09:00:52.809726530 +0100
+++ pdt_14.f03.077i.cp  2020-10-31 09:10:35.204755828 +0100
@@ -10,6 +10,8 @@
   Starting walk at: push_8 (&root, &C.4104);
   instance pointer: &root  Outer instance pointer: root offset: 0 (bits) vtbl
reference: 
   Function call may change dynamic type:push_8 (&root, &C.4103);
+ipa-modref: call stmt push_8 (&root, &C.4103);
+ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14
 Determining dynamic type for call: push_8 (&root, &C.4104);
   Starting walk at: push_8 (&root, &C.4104);
   instance pointer: &C.4104  Outer instance pointer: C.4104 offset: 0 (bits)
vtbl reference: 
@@ -19,6 +21,10 @@
   instance pointer: &root  Outer instance pointer: root offset: 0 (bits) vtbl
reference: 
   Function call may change dynamic type:push_8 (&root, &C.4104);
   Function call may change dynamic type:push_8 (&root, &C.4103);
+ipa-modref: call stmt push_8 (&root, &C.4104);
+ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14
+ipa-modref: call stmt push_8 (&root, &C.4103);
+ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14
 Determining dynamic type for call: push_8 (&root, &C.4105);
   Starting walk at: push_8 (&root, &C.4105);
   instance pointer: &C.4105  Outer instance pointer: C.4105 offset: 0 (bits)
vtbl reference: 
@@ -30,6 +36,12 @@
   Function call may change dynamic type:push_8 (&root, &C.4105);
   Function call may change dynamic type:push_8 (&root, &C.4104);
   Function call may change dynamic type:push_8 (&root, &C.4103);
+ipa-modref: call stmt push_8 (&root, &C.4105);
+ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14
+ipa-modref: call stmt push_8 (&root, &C.4104);
+ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14
+ipa-modref: call stmt push_8 (&root, &C.4103);
+ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14
 Determining dynamic type for call: _3 = pop_8 (&root);
   Starting walk at: _3 = pop_8 (&root);
   instance pointer: &root  Outer instance pointer: root offset: 0 (bits) vtbl
reference: 
@@ -129,10 +141,14 @@
        no arg info
     callsite  ch2701/7 -> pop_8/5 : 
        param 0: UNKNOWN
+         Aggregate passed by reference:
+           offset: 0, type: struct pdtlink_8 *, CONST: 0B
          value: 0x0, mask: 0xfffffffffffffff8
          VR  [1, -1]
     callsite  ch2701/7 -> push_8/6 : 
        param 0: UNKNOWN
+         Aggregate passed by reference:
+           offset: 0, type: struct pdtlink_8 *, CONST: 0B
          value: 0x0, mask: 0xfffffffffffffff8
          VR  [1, -1]
        param 1: CONST: &C.4105 -> 3.0e+0
@@ -140,6 +156,8 @@
          Unknown VR
     callsite  ch2701/7 -> push_8/6 : 
        param 0: UNKNOWN
+         Aggregate passed by reference:
+           offset: 0, type: struct pdtlink_8 *, CONST: 0B
          value: 0x0, mask: 0xfffffffffffffff8
          VR  [1, -1]
        param 1: CONST: &C.4104 -> 2.0e+0

The jump function is not used for cloning, only triggers inline, but the
conclusion seems wrong.  push_8 can make root non-0.  Root is of type pdtlink_8
so perhaps Frontend produces multiple copies of these.

push_8 store is:
 - Analyzing store: *self_34(D)                                                 
   - Recording base_set=8 ref_set=8 parm=0                                      
so indeed a different alias set than 14 used by ch2701

[Bug fortran/97652] New pdt14 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
*** Bug 97672 has been marked as a duplicate of this bug. ***

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
            Summary|New gfortran.dg/pdt_14.f03  |[11 Regression] New
                   |failure after               |gfortran.dg/pdt_14.f03
                   |g:617695cdc2b3d950f1e4deb5e |failure after
                   |a85d5cc302943f4             |g:617695cdc2b3d950f1e4deb5e
                   |                            |a85d5cc302943f4

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 97674 has been marked as a duplicate of this bug. ***

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I can only see one __vtype_link_module_Pdtlink_8 and one Pdtlink_8 type
(breaking at record_component_aliases).

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Oh, btw:

> /home/rguenther/obj-gcc2-g/gcc/testsuite/gfortran/../../gfortran -B/home/rguenther/obj-gcc2-g/gcc/testsuite/gfortran/../../ -B/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libgfortran/ /home/rguenther/src/gcc2/gcc/testsuite/gfortran.dg/pdt_14.f03 -fdiagnostics-plain-output -fdiagnostics-plain-output -O2 -pedantic-errors -B/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libatomic/.libs -B/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libquadmath/.libs -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libquadmath/.libs -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libquadmath/.libs -lm -o ./pdt_14.exe -fno-ipa-cp -fno-ipa-vrp -fno-ipa-icf -fdump-ipa-all      
during IPA pass: inline
dump file: ./pdt_14.f03.081i.inline
/home/rguenther/src/gcc2/gcc/testsuite/gfortran.dg/pdt_14.f03:85:0: internal
compiler error: Segmentation fault
0x14896d3 crash_signal
        /home/rguenther/src/gcc2/gcc/toplev.c:330
0xd26c14 cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*)
        /home/rguenther/src/gcc2/gcc/cgraph.c:1513
0x156e11a redirect_all_calls(copy_body_data*, basic_block_def*)
        /home/rguenther/src/gcc2/gcc/tree-inline.c:2963
0x156e906 copy_cfg_body
        /home/rguenther/src/gcc2/gcc/tree-inline.c:3118
0x156f0e5 copy_body
        /home/rguenther/src/gcc2/gcc/tree-inline.c:3294
0x1574028 expand_call_inline
        /home/rguenther/src/gcc2/gcc/tree-inline.c:5084
0x1574dca gimple_expand_calls_inline

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-11-02
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
And it looks like something (inlining) inserts __builtin_unreachable () calls
that eventually make us optimize this to an endless loop.

pdt_14.f03.081i.inline:Introduced new external node (__builtin_unreachable/19).
pdt_14.f03.081i.inline:unreachable                                       :     
  4 calls, 0.000000 freq, 0 count
pdt_14.f03.081i.inline:        __builtin_unreachable/19 unreachable
...

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> ---
> And it looks like something (inlining) inserts __builtin_unreachable () calls
> that eventually make us optimize this to an endless loop.
> 
> pdt_14.f03.081i.inline:Introduced new external node (__builtin_unreachable/19).
> pdt_14.f03.081i.inline:unreachable                                       :     
>   4 calls, 0.000000 freq, 0 count
> pdt_14.f03.081i.inline:        __builtin_unreachable/19 unreachable
> ...
Aha, that will be the wrong jump function from ipa-cp I mentioned in
earlier comment.  We should not believe that root is not written to as
we derive now from TBAA in push_8.

[Bug ipa/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |ipa

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, the unreachable () appears in place of indirect calls:

  _8 = __vtab_link_module_Pdtlink_8._deallocate;
  _8 (&cdesc.1);

but -fno-devirtualize doesn't help.

[Bug ipa/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #7)
> > And it looks like something (inlining) inserts __builtin_unreachable () calls
> > that eventually make us optimize this to an endless loop.
> > 
> > pdt_14.f03.081i.inline:Introduced new external node (__builtin_unreachable/19).
> > pdt_14.f03.081i.inline:unreachable                                       :     
> >   4 calls, 0.000000 freq, 0 count
> > pdt_14.f03.081i.inline:        __builtin_unreachable/19 unreachable
> > ...
> Aha, that will be the wrong jump function from ipa-cp I mentioned in
> earlier comment.  We should not believe that root is not written to as
> we derive now from TBAA in push_8.

But -fno-ipa-cp doesn't help.

[Bug ipa/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[hubicka at ucw dot cz]

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

--- Comment #10 from Jan Hubicka <hubicka at ucw dot cz> ---
> > Aha, that will be the wrong jump function from ipa-cp I mentioned in
> > earlier comment.  We should not believe that root is not written to as
> > we derive now from TBAA in push_8.
> 
> But -fno-ipa-cp doesn't help.

It is because jump functions are used both by inlining and ipa-cp.   If
inline predicates says that the path is impossible (which it will
derriving from jump function) we redirect to unreachable.

Honza

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|ipa                         |fortran

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
push_8 argument type is

    arguments <parm_decl 0x7ffff69cd600 self
        type <reference_type 0x7ffff69ec000 type <pointer_type 0x7ffff69e3000>
            unsigned DI size <integer_cst 0x7ffff680cbb8 64> unit-size
<integer_cst 0x7ffff680cbd0 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff69ec000>
        readonly used unsigned DI passed-by-reference
/home/rguenther/src/gcc2/gcc/testsuite/gfortran.dg/pdt_14.f03:47:0 size
<integer_cst 0x7ffff680cbb8 64> unit-size <integer_cst 0x7ffff680cbd0 8>
        align:64 warn_if_not_align:0 context <function_decl 0x7ffff69e0400
pop_8> arg-type <reference_type 0x7ffff69ec000>>
(gdb) p debug_tree (0x7ffff69e3000)
 <pointer_type 0x7ffff69e3000
    type <record_type 0x7ffff69dcf18 Pdtlink_8 BLK
        size <integer_cst 0x7ffff682a078 constant 192>
        unit-size <integer_cst 0x7ffff682a048 constant 24>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff69dcf18

and in ch2701 the root variable is

var_decl 0x7ffff69f6900 root type <pointer_type 0x7ffff69fb0a8>
            addressable used unsigned DI
/home/rguenther/src/gcc2/gcc/testsuite/gfortran.dg/pdt_14.f03:78:48 size
<integer_cst 0x7ffff680cbb8 64> unit-size <integer_cst 0x7ffff680cbd0 8>
            align:64 warn_if_not_align:0 context <function_decl 0x7ffff69e0b00
ch2701>>
(gdb) p debug_tree (0x7ffff69fb0a8)
 <pointer_type 0x7ffff69fb0a8
    type <record_type 0x7ffff69fb2a0 pdtlink_8 BLK
        size <integer_cst 0x7ffff682a078 constant 192>
        unit-size <integer_cst 0x7ffff682a048 constant 24>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff69fb2a0

which is a different type.  The latter is created here:

#0  0x0000000000c1d6f2 in gfc_get_derived_type (derived=0x39ebb70, codimen=0)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:2647
#1  0x0000000000c18c21 in gfc_typenode_for_spec (spec=0x39eb090, codim=0)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:1167
#2  0x0000000000c1c54b in gfc_sym_type (sym=0x39eb070)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:2252
#3  0x0000000000b701d9 in gfc_get_symbol_decl (sym=0x39eb070)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:1790
#4  0x0000000000b7fe7f in generate_local_decl (sym=0x39eb070)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:5948
#5  0x0000000000b1843d in do_traverse_symtree (st=0x39ec880, st_func=0x0, 
    sym_func=0xb7fdbb <generate_local_decl(gfc_symbol*)>)
    at /home/rguenther/src/gcc2/gcc/fortran/symbol.c:4170
#6  0x0000000000b184f8 in gfc_traverse_ns (ns=0x3a2f6d0, 
    sym_func=0xb7fdbb <generate_local_decl(gfc_symbol*)>)
    at /home/rguenther/src/gcc2/gcc/fortran/symbol.c:4195
#7  0x0000000000b80677 in generate_local_vars (ns=0x3a2f6d0)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:6154
#8  0x0000000000b825af in gfc_generate_function_code (ns=0x3a2f6d0)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:6812
#9  0x0000000000b3e3fe in gfc_generate_code (ns=0x3a2f6d0)
    at /home/rguenther/src/gcc2/gcc/fortran/trans.c:2235
#10 0x0000000000abe7e0 in translate_all_program_units (
    gfc_global_ns_list=0x39b18f0)

while the former here:

#0  0x0000000000c1d6f2 in gfc_get_derived_type (derived=0x39c6480, codimen=0)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:2647
#1  0x0000000000c18c21 in gfc_typenode_for_spec (spec=0x39ce5a0, codim=0)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:1167
#2  0x0000000000c1c54b in gfc_sym_type (sym=0x39ce580)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:2252
#3  0x0000000000b701d9 in gfc_get_symbol_decl (sym=0x39ce580)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:1790
#4  0x0000000000b7dd72 in gfc_create_module_variable (sym=0x39ce580)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:5339
#5  0x0000000000b1843d in do_traverse_symtree (st=0x3951a30, st_func=0x0, 
    sym_func=0xb7d65d <gfc_create_module_variable(gfc_symbol*)>)
    at /home/rguenther/src/gcc2/gcc/fortran/symbol.c:4170
#6  0x0000000000b184f8 in gfc_traverse_ns (ns=0x39b2f80, 
    sym_func=0xb7d65d <gfc_create_module_variable(gfc_symbol*)>)
    at /home/rguenther/src/gcc2/gcc/fortran/symbol.c:4195
#7  0x0000000000b7fb05 in gfc_generate_module_vars (ns=0x39b2f80)
    at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:5838
#8  0x0000000000b3e4f4 in gfc_generate_module_code (ns=0x39b2f80)
    at /home/rguenther/src/gcc2/gcc/fortran/trans.c:2259
#9  0x0000000000abe712 in translate_all_program_units (
    gfc_global_ns_list=0x39b18f0)

there is it seems code to deal with the type already been there but it seems
this handling doesn't work.  It does

  /* Store up the canonical type to be added to this one.  */
  if (got_canonical)
    {
      if (TYPE_CANONICAL (derived->backend_decl))
        canonical = TYPE_CANONICAL (derived->backend_decl);
      else
        canonical = derived->backend_decl;

      derived->backend_decl = NULL_TREE;
    }

  /* derived->backend_decl != 0 means we saw it before, but its
     components' backend_decl may have not been built.  */
  if (derived->backend_decl)
...
  else
    {
      /* We see this derived type first time, so build the type node.  */
      typenode = make_node (RECORD_TYPE);
      TYPE_NAME (typenode) = get_identifier (derived->name);
      TYPE_PACKED (typenode) = flag_pack_derived;
      derived->backend_decl = typenode;
    }

but we enver find a canonical type.

Looks like a latent issue exposed now.

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note setting TYPE_TYPELESS_STORAGE on the aggregates doesn't help the testcase
since the pointer types are the issue.

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 97686 has been marked as a duplicate of this bug. ***

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
The following works with and without -flto (fixes the endless loop without
and the execute fail with)

diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index b7129dcbe6d..4643fff243f 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2647,6 +2647,8 @@ gfc_get_derived_type (gfc_symbol * derived, int codimen)
       typenode = make_node (RECORD_TYPE);
       TYPE_NAME (typenode) = get_identifier (derived->name);
       TYPE_PACKED (typenode) = flag_pack_derived;
+      if (!got_canonical)
+       SET_TYPE_STRUCTURAL_EQUALITY (typenode);
       derived->backend_decl = typenode;
     }

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:

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

commit r11-4766-gc283a711c850efaab4fe3bca5ef7200eb854bba1
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Fri Nov 6 08:26:51 2020 +0100

    Fortran: Fix type-decl for PDT / wrong-code pdt_14.f03 issue [PR97652]

    Parameterized derived types are handled in a special way and start with
'Pdt'.
    If the 'P' is not uppercase, gfc_get_derived_type (which calls
    gfc_get_module_backend_decl) does not find the existing declaration and
    builds a new type. The middle end then sees those types as being different
    and nonalising, creating an endless loop for pdt_14.f03.

    gcc/fortran/ChangeLog:

            PR fortran/97652
            * module.c (mio_symbol): Fix symbol name for pdt_type.

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Tobias Burnus
<burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:099857318ca92210e34cfb8975c5c58c00bf1587

commit r10-8989-g099857318ca92210e34cfb8975c5c58c00bf1587
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Fri Nov 6 08:26:51 2020 +0100

    Fortran: Fix type-decl for PDT / wrong-code pdt_14.f03 issue [PR97652]

    Parameterized derived types are handled in a special way and start with
'Pdt'.
    If the 'P' is not uppercase, gfc_get_derived_type (which calls
    gfc_get_module_backend_decl) does not find the existing declaration and
    builds a new type. The middle end then sees those types as being different
    and nonalising, creating an endless loop for pdt_14.f03.

    gcc/fortran/ChangeLog:

            PR fortran/97652
            * module.c (mio_symbol): Fix symbol name for pdt_type.

    (cherry picked from commit c283a711c850efaab4fe3bca5ef7200eb854bba1)

[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Tobias Burnus
<burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:542b564343fdb896ede9c9d5e32d45dcd96b2a00

commit r9-9028-g542b564343fdb896ede9c9d5e32d45dcd96b2a00
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Fri Nov 6 08:26:51 2020 +0100

    Fortran: Fix type-decl for PDT / wrong-code pdt_14.f03 issue [PR97652]

    Parameterized derived types are handled in a special way and start with
'Pdt'.
    If the 'P' is not uppercase, gfc_get_derived_type (which calls
    gfc_get_module_backend_decl) does not find the existing declaration and
    builds a new type. The middle end then sees those types as being different
    and nonalising, creating an endless loop for pdt_14.f03.

    gcc/fortran/ChangeLog:

            PR fortran/97652
            * module.c (mio_symbol): Fix symbol name for pdt_type.

    (cherry picked from commit c283a711c850efaab4fe3bca5ef7200eb854bba1)