[Bug fortran/54778] [OOP] an ICE on invalid OO code
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
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
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
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
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
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 ...