http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #31 from rguenther at suse dot de <rguenther at suse dot de> 2011-01-18 13:37:42 UTC --- On Tue, 18 Jan 2011, mikael at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > --- Comment #30 from Mikael Morin <mikael at gcc dot gnu.org> 2011-01-18 > 12:48:41 UTC --- > (In reply to comment #28) > > One way would be to keep for data types all the time the two versions > > around: > > One with restrict and one without restrict; > makes sense > > > thus, if one does type extension, > > one has always a fully restrictless data type. > Why? From my point of view type extension is orthogonal to target. > If an entity of extended derived type has the target/pointer attribute, one > uses the non-restrict variant for its base type, and if it hasn't one uses the > restrict variant. Do I miss something? > > > Unfortunately, that seems to > > cause a missed-optimization for > > type t > > integer :: a > > integer, pointer :: b > > end type t > > type(t) :: x > > as "x%a" cannot alias and only "x%b" can - but is seems that one cannot > > encode > > this for the ME such that "t" as a whole has to be marked as unrestricted. > > How about: > > struct t_restrict { > int a; > int * b; > } * restrict > > VS > > struct t_norestrict { > int a; > int * b; > } * > > ? Yes. The restrict qualifier on t_restrict * does not apply to members, so as long as int *b is not restrict qualified the b's alias. > > I think the easiest would be to create for derived types sym->backend_decl > > and > > another backend_decl with "restrict" - and propagate both variants types > > through, when extending the type or including it into another type. As soon > > as > > it is used as POINTER component, one could drop propagating the > > backend_decl_restricted. > > Looks like a plan. :-) I think Micha has started working on something. Richard.
