This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/47082] [4.6 Regression] [OOP] ICE in gfc_conv_component_ref


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]