[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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #24 from Mikael Morin <mikael at gcc dot gnu.org> 2011-01-16 14:25:05 UTC ---
(In reply to comment #23)
> We could do the analysis that fixed PR 45777 here, I just don't know
> where :-)
> 
> Could somebody point me to the right place (I presume somewhere in trans-*)?

$ grep RESTRICT *
ChangeLog-2009:    instead set DECL_RESTRICTED_P on affected decls.
trans-decl.c:    DECL_RESTRICTED_P (decl) = 1;
trans-types.c:  prvoid_type_node = build_qualified_type (pvoid_type_node,
TYPE_QUAL_RESTRICT);
trans-types.c:                TYPE_QUAL_RESTRICT);
trans-types.c:    type = build_qualified_type (type, TYPE_QUAL_RESTRICT);
trans-types.c:    arraytype = build_qualified_type (arraytype,
TYPE_QUAL_RESTRICT);
trans-types.c:        type = build_qualified_type (type, TYPE_QUAL_RESTRICT);
$

then if you look at those places, they are guarded with a "if (restricted)"
condition, so the places you are looking for are those of calls to functions
expecting an argument named restricted (gfc_build_array_type,
gfc_get_nodesc_array_type). 

However, it doesn't look that easy. 
If I understand the thing correctly, in case you have an entity with a pointer
or target attribute, you have to build a variant of its base type without the
restrict attribute. That seems easy. Less easy is that you have to build a
variant type without the restrict attribute for each of it's sub-components
too. 

That is, for
!!!!!
type foo
  integer, allocatable :: bar(:)
end type foo
type(foo) :: x
type(foo), pointer :: y

call baz (x, y)
!!!!!
The type of baz's first actual argument (namely &x) is struct foo * restrict
but the type of baz's second actual argument (namely &y) is not struct foo *.

typeof(&x) ==
struct foo_restrict { 
  struct integer_array {
    struct array_bounds {
      int lbound, ubound, stride;
    } bounds [];
    ...
    integer * restrict data;
  } bar;
} * restrict

whereas

typeof(&y) ==
struct foo_norestrict { 
  struct integer_array {
    struct array_bounds {
      int lbound, ubound, stride;
    } bounds [];
    ...
    integer * data;
  } bar;
} *


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. 
Or maybe drop restrict all together on the type for correctness.

By the way, does the middle-end support creating a variant of a type with a
sub-component restrict (un)qualified ?