On Tue, 3 Nov 2020, Paul Richard Thomas wrote:

> Hi Richi,
> 
> That's OK for master and as far back as you have the fortitude to go.

We only know that the issue is exposed on trunk so I'll leave it
there only as a temporary workaround.

> Thanks for the fix.
> 
> I agree that we should always pick up a canonical variant. When I finally
> get "a minute or two" to fix the rather fundamental problems with PDTs, I
> will make sure that this goes away. I am also curious about the time out -
> I'll take a look.

Note the timeout happens because we optimize one loop to an endless
loop, the reason is mentioned in the PRs audit-trail.

Thanks,
Richard.

> 
> Paul
> 
> 
> On Tue, 3 Nov 2020 at 11:35, Richard Biener <rguent...@suse.de> wrote:
> 
> > This marks PDT types as needing structural comparison for TBAA
> > if we didn't pick up a canonical variant (which we should IMHO
> > always do).  This workaround fixes the gfortran.dg/pdt_14.f03
> > fail which materializes as testsuite timeout which is quite
> > annoying.
> >
> > Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
> >
> > OK?
> >
> > 2020-11-03  Richard Biener  <rguent...@suse.de>
> >
> >         PR fortran/97652
> > gcc/fortran
> >         * trans-types.c (gfc_get_derived_type): When we didn't find
> >         a canonical type mark it for structual equality.
> > ---
> >  gcc/fortran/trans-types.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > 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;
> >      }
> >
> > --
> > 2.26.2
> >
> 
> 
> 

-- 
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend

Reply via email to