Bug 51334 - [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
Summary: [OOP] ICE with type-bound operator: tree check: expected record_type or union...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on: 46328
Blocks: 51634
  Show dependency treegraph
 
Reported: 2011-11-28 16:38 UTC by Tobias Burnus
Modified: 2012-01-02 13:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Failing program (2.26 KB, text/plain)
2011-11-28 16:38 UTC, Tobias Burnus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2011-11-28 16:38:37 UTC
Created attachment 25938 [details]
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.
Comment 1 Tobias Burnus 2011-11-28 17:39:08 UTC
The issue seems to be again the nested operators. One has for:
  deriv    = diff * solution%nabla2()

an outer obj_assign_obj(obj1, obj2) operator and as inner operator the RHS == obj2, which is "real_times_obj", defined as:
        function real_times_obj( factor, obj ) result(newobj)
            real, intent(in)                    :: factor
            class(base_pde_object), intent(in)  :: obj
            class(base_pde_object), allocatable :: newobj
As further nesting level, there is the inner nabla2() function, which returns again at CLASS:
  function nabla2( obj )
    class(base_pde_object), intent(in)  :: obj
    class(base_pde_object), allocatable :: nabla2

And at some point one needs to access (expr->vtab->(procedure))(expr->value) which fails without a temporary.

Thus, I think this bug is effectively a duplicate of PR 46328.
Comment 2 Paul Thomas 2012-01-02 13:08:18 UTC
Fixed on trunk by r182796.  (Forgot to put this in the ChangeLogs!).

Thanks for the report

Paul