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

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

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

--- Comment #32 from Michael Matz <matz at gcc dot gnu.org> 2011-01-18 13:56:01 UTC ---
Yes, but it's possible I was going up the wrong tree.  My idea was to
build the no-restrict variants of types on demand, as necessary, basically
from gfc_sym_type(), whenever sym->attr.pointer.

This nearly worked, as in, it gives the top-level objects ('x' in question
of the testcase from comment #2) a correct type (a record of only non-restrict
members, recursively).

Unfortunately the fortran frontend uses a peculiar way to expand the actual
'x%r' construct.  The necessary FIELD_DECL is not pulled out from the
type of 'x' (I mean the TREE_TYPE), but rather from the frontend-specific
representation of types, in this case from the r-named-component's
backend_decl.  And that very backend_decl itself doesn't depend on the
context, as in, there's always only one for a given type.

So, yes, adding another backend_decl for one component which would hold
the no-restrict variant would work.  But that feels like a gross hack.

Everything would work iff 'x' had the proper type from the start, in
the frontend representation already.  Then its components also would have
the proper attributes set (target namely), leading to correctly typed
backend_decls automatically.

I quickly tried to implement something like that last paragraph,
but were unsuccessful so far.  My basic idea was to remember if a frontend
decl had attr.pointer set, and then set attr.target for all subcomponents
(via current_attr or otherwise).  I thought this was possible as it seemed
to me that the frontend possibly builds types for declarations anew each
time if necessary.  But I might be wrong.