Bug 53876 - [4.8 Regression] [OOP] ICE with class array
[4.8 Regression] [OOP] ICE with class array
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.8.0
: P4 normal
: 4.8.0
Assigned To: Paul Thomas
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-06 14:10 UTC by Prince Ogunbade
Modified: 2013-01-07 19:10 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-07-09 00:00:00


Attachments
Module containing types declaration and test program (2.43 KB, text/x-fortran)
2012-07-06 14:10 UTC, Prince Ogunbade
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Prince Ogunbade 2012-07-06 14:10:24 UTC
Created attachment 27751 [details]
Module containing types declaration and test program

The following error was encountered when I run the attached program. Apparently, this had already been reported and presumingly fixed but the bug still persists.

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 program in Ubuntu i686 and using the latest gfortran:
gcc version 4.8.0 20120624 (experimental) (GCC) 

Any way forward.

Thanks
Comment 1 janus 2012-07-09 12:24:41 UTC
(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!
Comment 2 janus 2012-07-09 12:44:48 UTC
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
Comment 3 Tobias Burnus 2012-08-02 15:39:10 UTC
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.
Comment 4 Paul Thomas 2012-12-15 16:27:12 UTC
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
Comment 5 Paul Thomas 2013-01-07 09:07:24 UTC
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
Comment 6 Paul Thomas 2013-01-07 19:10:39 UTC
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