[Bug fortran/54778] [OOP] an ICE on invalid OO code

2016-11-16 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54778

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug fortran/54778] [OOP] an ICE on invalid OO code

2012-10-02 Thread janus at gcc dot gnu.org


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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from janus at gcc dot gnu.org 2012-10-02 21:07:43 UTC ---

Fixed with r192005. Closing.



Thanks again for the report!


[Bug fortran/54778] [OOP] an ICE on invalid OO code

2012-10-02 Thread janus at gcc dot gnu.org


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



--- Comment #4 from janus at gcc dot gnu.org 2012-10-02 21:02:20 UTC ---

Author: janus

Date: Tue Oct  2 21:02:16 2012

New Revision: 192005



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192005

Log:

2012-10-02  Janus Weil  



PR fortran/54778

* interface.c (matching_typebound_op): Check for 'class_ok' attribute.



2012-10-02  Janus Weil  



PR fortran/54778

* gfortran.dg/class_53.f90: New.



Added:

trunk/gcc/testsuite/gfortran.dg/class_53.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/interface.c

trunk/gcc/testsuite/ChangeLog


[Bug fortran/54778] [OOP] an ICE on invalid OO code

2012-10-02 Thread janus at gcc dot gnu.org


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



--- Comment #3 from janus at gcc dot gnu.org 2012-10-02 19:31:40 UTC ---

Btw, here is a slightly simpler version of the test case with the same

symptoms:





implicit none



type :: arr_t

  real :: at

end type



type(arr_t) :: this

class(arr_t) :: elem



elem = this



end


[Bug fortran/54778] [OOP] an ICE on invalid OO code

2012-10-02 Thread janus at gcc dot gnu.org


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



--- Comment #2 from janus at gcc dot gnu.org 2012-10-02 19:00:34 UTC ---

(In reply to comment #1)

> Regtesting now ...



Finished successfully. Will commit as obvious.


[Bug fortran/54778] [OOP] an ICE on invalid OO code

2012-10-02 Thread janus at gcc dot gnu.org


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



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Keywords||ice-on-invalid-code

   Last reconfirmed||2012-10-02

 CC||janus at gcc dot gnu.org

 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1

Summary|an ICE on invalid OO code   |[OOP] an ICE on invalid OO

   ||code



--- Comment #1 from janus at gcc dot gnu.org 2012-10-02 16:12:50 UTC ---

Thanks for reporting. I can reproduce this on 4.7 and trunk.





Here is a patch to fix it:



Index: gcc/fortran/interface.c

===

--- gcc/fortran/interface.c(revision 191869)

+++ gcc/fortran/interface.c(working copy)

@@ -3386,7 +3386,8 @@ matching_typebound_op (gfc_expr** tb_base,



 if (base->expr->ts.type == BT_CLASS)

   {

-if (CLASS_DATA (base->expr) == NULL)

+if (CLASS_DATA (base->expr) == NULL

+|| !gfc_expr_attr (base->expr).class_ok)

   continue;

 derived = CLASS_DATA (base->expr)->ts.u.derived;

   }





With this I get:



c0.f90:14.2:



  function elem(this, i)

  1

Error: CLASS variable 'elem' at (1) must be dummy, allocatable or pointer

c0.f90:18.4:



elem = this%elements(i)

1

Error: Variable must not be polymorphic in intrinsic assignment at (1) - check

that there is a matching specific subroutine for '=' operator





Regtesting now ...