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;
} *
?
>
> 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. :-)
