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

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586

--- Comment #28 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-17 13:20:42 UTC ---
(In reply to comment #26)
> It is, btw, a sign of bad Fortran language design and makes the point
> of the pointer/target attributes moot.

Well, I think it is just different model, which is used by the middle end and
by the Fortran language, thus there is no simple one-to-one matching. That a
hack was needed to get a better "restricted" support is already a hint that the
models are a bit incompatible.

Fortran's handling is simple: Every variable does not alias by default - the
compiler only has to assume aliasing (of the variable and its components) if
the variable is explicitly marked as TARGET in that scope; for sections of code
where it does not have a TARGET attribute, the user has to ensure that there is
no aliasing. There is only one complication: pointers and pointer components of
derived types ("TYPE") can alias. [Cf. comment 18]

Seemingly there is an issue of propagating this information properly to the
middle end.

Thus, for the first test case (comment 1):

  TYPE realspace_grid_type
     REAL(KIND=dp), DIMENSION ( :, :, : ), ALLOCATABLE :: r
  END TYPE realspace_grid_type
  TYPE(realspace_grid_type), POINTER :: x, y

The "POINTER" attribute means that "x" and "y" are pointers; thus, if "x" and
"y" are the same, x%r and y%r are the same, if "x" and "y" are different, "x%r"
and "y%r" are different arrays. Additionally, the "pointer" attribute means
that "x%r" and "y%r" have implicitly the TARGET attribute.


Quoting comment 15:
> You then need to make sure to create variant types of aggregates with the
> target attribute applied to all subtypes (thus, the restrict stuff removed)
> as the middle-end doesn't know about this rule.

Which seems to be sensible - though it might need a substantial rework of the
FE to keep all the time both variants available:

>From comment 24:
> Note that the data member has lost the restrict too. Thus, when creating such
> pointer qualified types, one should take care not to update the
> sym->backend_decl of the derived type as they are different. That looks
> like a substantial rework.

One way would be to keep for data types all the time the two versions around:
One with restrict and one without restrict; thus, if one does type extension,
one has always a fully restrictless data type. 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.


> Or maybe drop restrict all together on the type for correctness.

Well, "restrict" is a very important means to allow for optimization; at least
as long as no POINTER is involved (neither the data type nor a component) and
also no TARGET, one should really use restricted pointers. For the other cases,
one has probably to accept that the ME does not support Fortran's rules :-(

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.