[Bug fortran/53876] New: ICE: OOP Class array

[Bug fortran/53876] New: ICE: OOP Class array

[pogos77 at hotmail dot com]

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

             Bug #: 53876
           Summary: ICE: OOP Class array
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: pogos77@hotmail.com


Created attachment 27751
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27751
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

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-07-09
                 CC|                            |janus at gcc dot gnu.org
            Summary|ICE: OOP Class array        |[4.8 Regression] [OOP] ICE
                   |                            |with class array
     Ever Confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org 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!

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 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

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 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.

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |pault at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> 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

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> 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

[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> 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