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

mikael at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Jan 18 17:38:00 GMT 2011


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

--- Comment #33 from Mikael Morin <mikael at gcc dot gnu.org> 2011-01-18 17:21:54 UTC ---
(In reply to comment #32)
> 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.
As I said in comment #27, gfc_component structs belonging to the type, they are
shared between target and non-target variants. Thus one cannot set inherited
target attributes on them. 
Consider this :
!!!!!!!!!!!!!
type bar
  integer :: a
end type bar

type(bar), pointer :: b
type(bar)          :: c
end
!!!!!!!!!!!!!
If you want to set the target attribute on b%a, you will set it on the `a'
component of the `bar' type, and will impact `c' as well.



More information about the Gcc-bugs mailing list