Hide Forgot
Created attachment 1192960 [details] reproducer.tar This is a simple crash on apparently valid code. The crash happens due to no fields declared to a sequence type; adding a field or removing the sequence attribute prevents the crash. A simple patch could be to add: if (dt1 == dt2) return 1; if (!dt1 || !dt2) return 0; to gfc_compare_derived_types before the for loop: 389 int 390 gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2) [...] 421 dt1 = derived1->components; 422 dt2 = derived2->components; 423 424 /* Since subtypes of SEQUENCE types must be SEQUENCE types as well, a 425 simple test can speed things up. Otherwise, lots of things have to 426 match. */ 427 for (;;) 428 { 429 if (strcmp (dt1->name, dt2->name) != 0) 430 return 0; 431 432 if (dt1->attr.access != dt2->attr.access) 433 return 0; or a slightly less readable variant: if (!dt1 || !dt2) return dt1 == dt2; Simple reproducer derived from user issue attached.
The ICE was fixed in <https://gcc.gnu.org/r235999>. But since that revision I get: $ ./f951 -quiet t.f90 t.f90:6:12: call sub(tst) 1 Error: Type mismatch in argument ‘test’ at (1); passed TYPE(test_t) to TYPE(test_t) You said "apparently valid code", but did you really mean "valid"? I don't know Fortran to gauge whether this is or isn't valid. In any case, the revision is pretty recent and doesn't seem to be backportable.
I said apparently valid code because the specification appears to not tell about empty types: TYPE [[ , access specification ] :: ] type name [ PRIVATE ] [ SEQUENCE ] [ type specification [[ , POINTER ] :: ] component specification list ] ... END TYPE [ type name ] The type mismatch error is expected. The user just believes that the ICE should not happen.
Sure, the ICE is definitely a bug, but if the type mismatch error is expected, then this would be ICE-on-invalid, and such bugs have a rather low priority.
I just tested on rawhide, with this minor change, to make the types compatible: mod.f90: - integer(4) type +! integer(4) type and test.sh (to avoid link failure): - gfortran t.f90 + gfortran -c t.f90 and it compiles and generates .o files.
The related test passes on all architectures with gcc-4.8.5-14.el7. VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2094