Bug 46262 - [OOP] tree check: expected function_type or method_type, have pointer_type
[OOP] tree check: expected function_type or method_type, have pointer_type
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P4 normal
: ---
Assigned To: Not yet assigned to anyone
: ice-on-valid-code
: 48011 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-01 19:35 UTC by janus
Modified: 2012-01-02 13:03 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-03-22 14:44:00


Attachments
full test case (2.38 KB, application/x-gtar)
2010-11-01 19:49 UTC, janus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description janus 2010-11-01 19:35:00 UTC
The following code ICEs with current trunk:


module integrable_model_module

  implicit none 

  type :: integrable_model
  contains
    procedure :: multiply
    generic :: operator(*) => multiply
  end type integrable_model

  contains

    subroutine integrate (model)
      class(integrable_model) :: model
      print *,d_dt(model)*2.0
    end subroutine

    function d_dt (this)
      class(integrable_model), intent(in) :: this
      class(integrable_model), allocatable :: d_dt
    end function

    real function multiply(lhs, rhs)
      class(integrable_model), intent(in) :: lhs
      real, intent(in) :: rhs
    end function

end module


integrable_model.f03: In function ‘integrate’:
integrable_model.f03:15:0: internal compiler error: tree check: expected function_type or method_type, have pointer_type in gimplify_call_expr, at gimplify.c:2354

It is reported to work with 4.5.x and a 4.6 snapshot from 20100703.
Comment 1 janus 2010-11-01 19:43:41 UTC
-fdump-tree-original shows wrong code being generated:


      struct class$integrable_model_a <T3f8> (struct class$integrable_model & restrict) D.1529;
      static real(kind=4) C.1528 = 2.0e+0;
      struct class$integrable_model_a D.1527;

      D.1527 = d_dt ((struct class$integrable_model *) model);
      D.1529 = d_dt (&D.1527, &C.1528);
      _gfortran_transfer_real_write (&dt_parm.0, &D.1529, 4);


The second call to "d_dt" should actually be a call to "D.1527->$vptr->multiply".
Comment 2 janus 2010-11-01 19:45:12 UTC
The following variant:


module integrable_model_module

  implicit none 

  type :: integrable_model
  contains
    procedure :: multiply
    generic :: operator(*) => multiply
  end type integrable_model

  contains

    subroutine integrate (model)
      class(integrable_model) :: model
      real :: r
      r = d_dt(model)*2.0
    end subroutine

    function d_dt (this)
      class(integrable_model), intent(in) :: this
      class(integrable_model), allocatable :: d_dt
    end function

    real function multiply(lhs, rhs)
      class(integrable_model), intent(in) :: lhs
      real, intent(in) :: rhs
    end function

end module


yields:

integrable_model.f03: In function ‘integrate’:
integrable_model.f03:16:0: internal compiler error: in fold_convert_loc, at fold-const.c:1934
Comment 3 janus 2010-11-01 19:49:28 UTC
Created attachment 22222 [details]
full test case

When fixing, one should make sure that the full code from

http://portal.acm.org/citation.cfm?id=1644001.1644004

also works (attached). Originally reported by Ralph Kube at http://gcc.gnu.org/ml/fortran/2010-11/msg00003.html.
Comment 4 Jerry DeLisle 2010-11-02 03:33:35 UTC
I have a regression hunt running.
Comment 5 Jerry DeLisle 2010-11-02 05:22:42 UTC
Passes at r162312 and fails at r162313.
Comment 6 janus 2010-11-02 07:29:20 UTC
(In reply to comment #5)
> Passes at r162312 and fails at r162313.

Thanks for checking, Jerry. r162313 was Paul's fix for PR42385 ("poylmorphic operators do not work"):

http://gcc.gnu.org/viewcvs?view=revision&revision=162313
Comment 7 Jerry DeLisle 2010-11-28 15:23:56 UTC
I believe I have this isolated to the changes in resolve.c

Eliminating those changes in the offending patch eliminates the ICE.  Of course, though the code compiles, it does not link.
Comment 8 Jerry DeLisle 2010-11-28 15:52:06 UTC
Specifically, this line is involved with the problem.

Index: resolve.c
===================================================================
--- resolve.c	(revision 167220)
+++ resolve.c	(working copy)
@@ -5739,7 +5739,6 @@ resolve_typebound_function (gfc_expr* e)
       e->symtree = expr->symtree;
       e->ref = gfc_copy_ref (expr->ref);
       gfc_add_vptr_component (e);
-      gfc_add_component_ref (e, name);
       e->value.function.esym = NULL;
       return SUCCESS;
     }
Comment 9 janus 2011-01-05 09:33:56 UTC
(In reply to comment #1)
> -fdump-tree-original shows wrong code being generated:
> 
> 
>       struct class$integrable_model_a <T3f8> (struct class$integrable_model &
> restrict) D.1529;
>       static real(kind=4) C.1528 = 2.0e+0;
>       struct class$integrable_model_a D.1527;
> 
>       D.1527 = d_dt ((struct class$integrable_model *) model);
>       D.1529 = d_dt (&D.1527, &C.1528);
>       _gfortran_transfer_real_write (&dt_parm.0, &D.1529, 4);
> 
> 
> The second call to "d_dt" should actually be a call to
> "D.1527->$vptr->multiply".

Note that 4.5 also produces wrong code here:

      real(kind=4) D.1560;
      static real(kind=4) C.1559 = 2.0e+0;
      struct .class.integrable_model.a D.1558;

      D.1558 = d_dt ((struct .class.integrable_model *) model);
      D.1560 = multiply (&D.1558, &C.1559);
      _gfortran_transfer_real (&dt_parm.0, &D.1560, 4);

It has a static call to 'multiply', instead of a polymorphic call via the vptr. So, since 4.5 also does not handle the test case correctly, I think it's fair to remove the "regression" tag.

In a way one could even argue that the ICE in 4.6 is an improvement over 4.5 silently giving wrong results for such cases, since the user does at least get *some* error message (even though a crude and uninformative one), instead of assuming the feature was supported and getting wrong results in the end!
Comment 10 janus 2011-03-07 08:39:23 UTC
*** Bug 48011 has been marked as a duplicate of this bug. ***
Comment 11 Jakub Jelinek 2011-03-25 19:53:03 UTC
GCC 4.6.0 is being released, adjusting target milestone.
Comment 12 Paul Thomas 2012-01-02 12:46:15 UTC
Author: pault
Date: Mon Jan  2 12:46:08 2012
New Revision: 182796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182796
Log:
2012-01-02  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/51529
	* trans-array.c (gfc_array_allocate): Null allocated memory of
	newly allocted class arrays.

	PR fortran/46262
	PR fortran/46328
	PR fortran/51052
	* interface.c(build_compcall_for_operator): Add a type to the
	expression.
	* trans-expr.c (conv_base_obj_fcn_val): New function.
	(gfc_conv_procedure_call): Use base_expr to detect non-variable
	base objects and, ensuring that there is a temporary variable,
	build up the typebound call using conv_base_obj_fcn_val.
	(gfc_trans_class_assign): Pick out class procedure pointer
	assignments and do the assignment with no further prcessing.
	(gfc_trans_class_array_init_assign, gfc_trans_class_init_assign
	gfc_trans_class_assign): Move to top of file.
	* gfortran.h : Add 'base_expr' field to gfc_expr.
	* resolve.c (get_declared_from_expr): Add 'types' argument to
	switch checking of derived types on or off.
	(resolve_typebound_generic_call): Set the new argument.
	(resolve_typebound_function, resolve_typebound_subroutine):
	Set 'types' argument for get_declared_from_expr appropriately.
	Identify base expression, if not a variable, in the argument
	list of class valued calls. Assign it to the 'base_expr' field
	of the final expression. Strip away all references after the
	last class reference.


2012-01-02  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/46262
	PR fortran/46328
	PR fortran/51052
	* gfortran.dg/typebound_operator_7.f03: New.
	* gfortran.dg/typebound_operator_8.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03
    trunk/gcc/testsuite/gfortran.dg/typebound_operator_8.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/dump-parse-tree.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
Comment 13 Paul Thomas 2012-01-02 13:03:12 UTC
Fixed on trunk.

Thanks to everybody for the reports and testcases.

Paul