https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
--- Comment #7 from drikosev at otenet dot gr --- Hi, The reduced test case which has been posted by janus (comment 1) crashes also 4.8.4 and gcc 5.0 (the latter was copied from trunc a few days ago). The backtrace I get agrees with that of Dominique's (comment 4). The problem is likely in function "check_interface0"; the locus of "p->sym" is invalid when gfc_error is called: gfc_error ("Procedure '%s' in %s at %L is neither function nor " "subroutine", p->sym->name, interface_name, &p->sym->declared_at); Likely, the reason is that there is a symbol only in the access statement but the expected function/subroutine hasn't been defined. Perhaps, one can avoid the segmentation fault with an addition argument in function "check_interface0". The argument will be not null only if called by function "check_sym_interfaces"; in which case it will be the symbol that appears in the access-stmt. I'm not really if we can reproduce the error for intrinsic assignment operators but the solution could be similar. Provided that such a patch will be implemented, the second error message for the example at comment 1 would look like: pr59016.f90:2.30: PUBLIC :: atomic_kind_type 1 Error: undefined function/subroutine for generic interface 'atomic_kind_type' at (1) ----------------------------------------------------------------------- PS: please also note that I've not run the regression tests!