[Bug fortran/51334] New: [OOP] ICE with type-bound operator: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_conv_component_ref, at fortran/trans-expr.c:556

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

             Bug #: 51334
           Summary: [OOP] ICE with type-bound operator: tree check:
                    expected record_type or union_type or qual_union_type,
                    have function_type in gfc_conv_component_ref, at
                    fortran/trans-expr.c:556
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: janus@gcc.gnu.org


Created attachment 25938
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25938
Failing program

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d9df983132fcc643

Arjen Markus reports there that his program ICEs with GCC 4.6; it also does so
with GCC the trunk. It does compile with ifort 12.1 (but not with 12.0);
however, there are unresolved symbols with ifort 12.1. It fails to compile with
PGI 11.5 and crayftn 7.1.4.111, but those errors look bogus.


In gfortran 4.7:

Test.f90: In function âtest_pde_solverâ:
Test.f90:375:0: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have function_type in gfc_conv_component_ref, at
fortran/trans-expr.c:556


The line of interest is:
        deriv    = diff * solution%nabla2()

The ICE is in gfc_conv_component_ref; debugging shows:

(gdb) p c->name
$2 = 0x2aaaacf09050 "_vptr"

(gdb) p debug_tree(decl)
 <indirect_ref 0x2aaaacf1baa0
    type <function_type 0x2aaaacf0e738
        type <record_type 0x2aaaacf069d8
__class_base_pde_objects_Base_pde_object_a BLK
[...]


It looks as if the constructor patch causes the generation of a function decl
instead of an record decl. However, given that the problem also occurs with
4.7, there seems to be something else broken as well.