[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586

--- Comment #76 from rguenther at suse dot de <rguenther at suse dot de> 2012-08-01 12:28:10 UTC ---
On Wed, 1 Aug 2012, mikael at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
> 
> --- Comment #75 from Mikael Morin <mikael at gcc dot gnu.org> 2012-08-01 12:22:03 UTC ---
> Created attachment 27919
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27919
> rough patch
> 
> (In reply to comment #74)
> > > For variable to be type compatible for assignment, they shall be variants of
> > > the same type, and thus have the same TYPE_FIELDS.
> > > If they shall have the same TYPE_FIELDS, they shall have the same components,
> > > the same components have the same types, so that one cannot be restrict
> > > qualified.
> > 
> > The types should not be variant types ;)  (see my hack patch in
> > this or another bug)
> Ah OK, I thought it was just a hack.
> 
> > > > nor does it address the original
> > > > issue of supporting INTENT IN/OUT properly.
> > > Ah? Isn't a restricted type variable (resp. component, etc) merely one that has
> > > its own alias set? So if it works with restrict, it works with alias sets?
> > 
> > No, alias-sets and restrict are different beasts.  It's important to
> > have the data member restrict qualified for INTENT IN/OUT.
> Ah.
> 
> I have attached a (very rough) patch which is already in the testsuite past the
> first failing cases reported by Dominique.
> About your fix:
> (In reply to comment #64)
> > Index: gcc/fortran/trans-types.c
> > ===================================================================
> > --- gcc/fortran/trans-types.c   (revision 184203)
> > +++ gcc/fortran/trans-types.c   (working copy)
> > @@ -2042,7 +2042,8 @@ gfc_nonrestricted_type (tree t)
> >               }
> >           if (!field)
> >             break;
> > -         ret = build_variant_type_copy (t);
> > +         ret = build_distinct_type_copy (t);
> > +         TYPE_CANONICAL (ret) = TYPE_CANONICAL (t);
> >           TYPE_FIELDS (ret) = NULL_TREE;
> > 
> >           /* Here we make sure that as soon as we know we have to copy
> there is another call to build_variant_type_copy before about array types.
> Should the same fix by applied or are variants OK there?

You mean

      case ARRAY_TYPE:
        {
          tree elemtype = gfc_nonrestricted_type (TREE_TYPE (t));
          if (elemtype == TREE_TYPE (t))
            ret = t;
          else
            {
              ret = build_variant_type_copy (t);

?  Yes, that also should be build_distinct_type_copy.

Richard.