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.