This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
- From: "drikosev at otenet dot gr" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 29 Mar 2015 19:32:00 +0000
- Subject: [Bug fortran/59016] f951: internal compiler error: Segmentation fault
- Auto-submitted: auto-generated
- References: <bug-59016-4 at http dot gcc dot gnu dot org/bugzilla/>
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!