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

["mikael at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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. :-)