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.
