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?
