[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from janus at gcc dot gnu.org --- Fixed with r267735. Closing.
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 --- Comment #8 from janus at gcc dot gnu.org --- Author: janus Date: Tue Jan 8 19:29:01 2019 New Revision: 267735 URL: https://gcc.gnu.org/viewcvs?rev=267735=gcc=rev Log: 2019-01-08 Janus Weil PR fortran/88047 * class.c (gfc_find_vtab): For polymorphic typespecs, the components of the class container may not be available (in case of invalid code). 2019-01-08 Janus Weil PR fortran/88047 * gfortran.dg/class_69.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/class_69.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #6) > Janus, could please you figure out why class_array_3.f03 is failing with > your patch? I think the problem is that for class arrays the proper array refs are only established at resolution stage, so that gfc_expr_attr does not yet work at parsing stage, leading to the ICE shown in comment #4. I see no simple way to change that. In consequence, I propose the following patch: @@ -2846,7 +2846,10 @@ gfc_find_vtab (gfc_typespec *ts) case BT_DERIVED: return gfc_find_derived_vtab (ts->u.derived); case BT_CLASS: - return gfc_find_derived_vtab (ts->u.derived->components->ts.u.derived); + if (ts->u.derived->components && ts->u.derived->components->ts.u.derived) + return gfc_find_derived_vtab (ts->u.derived->components->ts.u.derived); + else + return NULL; default: return find_intrinsic_vtab (ts); } It fixes the ICEs on comment #0 and comment #5 and regtests cleanly.
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 --- Comment #6 from Dominique d'Humieres --- > A related test case, also changed between 20180909 and 20180916 : Confirmed at r264350, not fixed by the patch in comment 2, but by the patch in comment 3. Janus, could please you figure out why class_array_3.f03 is failing with your patch?
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 --- Comment #5 from G. Steinmetz --- A related test case, also changed between 20180909 and 20180916 : $ cat z2.f90 program p type t integer :: n end type class(t) :: a, x x = a end $ gfortran-9-20180909 -c z2.f90 z2.f90:5:16: 5 |class(t) :: a, x |1 Error: CLASS variable 'a' at (1) must be dummy, allocatable or pointer z2.f90:5:19: 5 |class(t) :: a, x | 1 Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer z2.f90:6:3: 6 |x = a | 1 Error: Nonallocatable variable must not be polymorphic in intrinsic assignment at (1) - check that there is a matching specific subroutine for '=' operator $ gfortran-9-20181209 -c z2.f90 f951: internal compiler error: Segmentation fault 0xb2f31f crash_signal ../../gcc/toplev.c:326 0x5fb831 gfc_find_derived_vtab(gfc_symbol*) ../../gcc/fortran/class.c:2220 0x5ff91b gfc_find_vtab(gfc_typespec*) ../../gcc/fortran/class.c:2847 0x64d572 gfc_match_assignment() ../../gcc/fortran/match.c:1378 0x66f120 match_word ../../gcc/fortran/parse.c:65 0x66f120 decode_statement ../../gcc/fortran/parse.c:361 0x670c7a next_free ../../gcc/fortran/parse.c:1235 0x670c7a next_statement ../../gcc/fortran/parse.c:1467 0x67228b parse_spec ../../gcc/fortran/parse.c:3859 0x674d2c parse_progunit ../../gcc/fortran/parse.c:5674 0x6763a9 gfc_parse_file() ../../gcc/fortran/parse.c:6214 0x6bf27f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047
--- Comment #4 from Dominique d'Humieres ---
> Side note: In principle I would have preferred something like this:
> ...
I agree that the patch is more general than my ad hoc check that a particular
pointer is not dereferenced.
> But that ICEs on class_array_3.f03.
Yes: f951: internal compiler error: gfc_variable_attr(): Bad array reference
This comes from
case AR_UNKNOWN:
/* If any of start, end or stride is not integer, there will
already have been an error issued. */
int errors;
gfc_get_errors (NULL, );
if (errors == 0)
gfc_internal_error ("gfc_variable_attr(): Bad array reference");
}
and looks like a latent bug. Any chance for a quick fix?
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > The following patch restores the errors It doesn't seem to cause any regressions in the testsuite either. Feel free to commit this fix, Dominique. Side note: In principle I would have preferred something like this: diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c index f22241da60b..e40c23f2a5d 100644 --- a/gcc/fortran/match.c +++ b/gcc/fortran/match.c @@ -1374,7 +1374,8 @@ gfc_match_assignment (void) gfc_check_do_variable (lvalue->symtree); - if (lvalue->ts.type == BT_CLASS) + if (lvalue->ts.type == BT_CLASS && (rvalue->ts.type != BT_CLASS + || gfc_expr_attr (rvalue).class_ok)) gfc_find_vtab (>ts); return MATCH_YES; But that ICEs on class_array_3.f03.
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 --- Comment #2 from Dominique d'Humieres --- The following patch restores the errors --- ../_clean/gcc/fortran/match.c 2018-11-01 22:06:33.0 +0100 +++ gcc/fortran/match.c 2018-11-15 22:47:01.0 +0100 @@ -1374,7 +1374,8 @@ gfc_match_assignment (void) gfc_check_do_variable (lvalue->symtree); - if (lvalue->ts.type == BT_CLASS) + if (lvalue->ts.type == BT_CLASS && (rvalue->ts.type != BT_CLASS +|| rvalue->ts.u.derived->components)) gfc_find_vtab (>ts); return MATCH_YES; without breaking gfortran.dg/class_assign_2.f90 and gfortran.dg/class_assign_3.f90.
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-15 CC||janus at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Likely r264350 (pr84543, pr86484).
