This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/47082] [4.6 Regression] [OOP] ICE in gfc_conv_component_ref
- From: "pault at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 1 Feb 2011 10:00:36 +0000
- Subject: [Bug fortran/47082] [4.6 Regression] [OOP] ICE in gfc_conv_component_ref
- Auto-submitted: auto-generated
- References: <bug-47082-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47082
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu.org
--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> 2011-02-01 10:00:14 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > This does not solve the problem fully, but it reduces it to PR46448:
> >
> > /tmp/cc9UG1CN.s: Assembler messages:
> > /tmp/cc9UG1CN.s:65: Error: symbol `__copy_m0_t0_' is already defined
>
> After PR46448 is solved now, the patch fully fixes the test case. Still it
> feels a bit hackish.
Not entirely:
If you change the line in module m1 from-
class(t0), pointer, private :: idxmap
to
type(t0), pointer, private :: idxmap
then the reduced testcase of comment #1 compiles. Comparing themain programme
between the two, you will see a symtree '@2' in the failing case that points to
the vtype, '__vtype_m0_T0'. I would guess that this has no backend_decl.
Calling gfc_get_derived_type then associates (I think) the backend_decls with
that of the symtree '__vtype_m0_T0', which is somehow pointing to a different
symbol.
I will explore further at lunchtime.
Paul