(In reply to comment #0)
> oop_class_array.f90: In function ‘display_population’:
> oop_class_array.f90:111:0: internal compiler error: in gfc_add_modify_loc, at
> fortran/trans.c:161
>         CALL self%indv(i)%display()
>  ^

I can confirm this ICE with trunk. However, gfortran 4.7.1 compiles the test case cleanly, so apparently it is a regression. With 4.7 one gets a segfault at runtime (invalid memory reference on line 106).

Thanks for the bug report!

Here is a reduced test case for the ICE (4.8 regression):


  IMPLICIT NONE

  TYPE :: individual
    REAL, DIMENSION(:), ALLOCATABLE :: genes
  END TYPE

  CLASS(individual), DIMENSION(:), ALLOCATABLE :: indv
  INTEGER :: i

  CALL display_indv(indv(1))

CONTAINS

  SUBROUTINE display_indv(self)
    CLASS(individual),  INTENT(IN) :: self
  END SUBROUTINE

END

The ICE occurs for:
  CALL display_indv(indv(1))
in gfc_conv_class_to_class, which is called for e == "indiv->_data(1)".

Namely for:

  /* Set the data.  */
  ctree = gfc_class_data_get (var);
   ...
  gfc_add_modify (&parmse->pre, ctree, parmse->expr);


That's the line:
  class.1._data = indv._data.data
                 + (sizetype) ((indv._data.offset + 1)
                  * (integer(kind=8)) indv._vptr->_size);

The problem is that the LHS and the RHS have a different type. Both are pointers to a record_type, which contains "genes" (type "array1_real(kind=4)") as component.

However, the decl for both the record type and the "genes" type is different (only their respective canonical type is the same).

I wonder whether it has something to do with restricted and not. (See also PR 45586). Though, as marking all variables as TARGET doesn't help, I might also be off track.

Tobias,

Your analysis is completely correct.

> 
>   /* Set the data.  */
>   ctree = gfc_class_data_get (var);

Inserting
      parmse->expr = fold_convert (TREE_TYPE (ctree), parmse->expr);

before this line fixes the problem.
>   gfc_add_modify (&parmse->pre, ctree, parmse->expr);
> 
> 
....snip...

> The problem is that the LHS and the RHS have a different type. Both are
> pointers to a record_type, which contains "genes" (type "array1_real(kind=4)")
> as component.
> 
> However, the decl for both the record type and the "genes" type is different
> (only their respective canonical type is the same).

which is why the above works.
 
> I wonder whether it has something to do with restricted and not. (See also PR
> 45586). Though, as marking all variables as TARGET doesn't help, I might also
> be off track.

I will try to understand why the regression occurred.  However, the above fix is perfectly OK.

The testcase of comment 2 works with the above.  The original needs a call to the constructor before the assignment in the main program to avoid the runtime fault.

After I have got the unlimited polymorphic patch out of the way, I will submit this fix (my tree is too poluted right no :-) )

Cheers

Paul

Fixed by http://gcc.gnu.org/viewcvs?view=revision&revision=194953

It did not register here because I screwed up on the ChangeLog Format (I really am rusty  :-) ).  I'll fix this tonight.

Thanks for the report.

Paul

Author: pault
Date: Mon Jan  7 19:10:32 2013
New Revision: 194994

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

	PR fortran/53876
	PR fortran/54990
	PR fortran/54992
	* ChangeLog: Correct format error in revision 194953

2013-01-07  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/53876
	PR fortran/54990
	PR fortran/54992
	* ChangeLog: Correct format error in revision 194953

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/testsuite/ChangeLog