This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
- From: "mikael at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 18 Jan 2011 17:22:18 +0000
- Subject: [Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
- Auto-submitted: auto-generated
- References: <bug-45586-4@http.gcc.gnu.org/bugzilla/>
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.