Hi, the attached code started to ICE with gfortran 4.3.0 shortly after 20070416: % gfortran -c gfcbug64.f90 gfcbug64.f90:12: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Cheers, -ha
Created attachment 13763 [details] Demo code
Herald, Both cases work for me on latest trunk. x86-64 I tried several compiler switches as well, no problems.
I can only partially reproduce this: I don't get a crash, but valgrind shows: ==12017== Conditional jump or move depends on uninitialised value(s) ==12017== at 0x45229B: gfc_resolve_expr (resolve.c:3272) ==12017== by 0x40BC7C: resolve_array_bound (array.c:218) ==12017== by 0x40BD2C: gfc_resolve_array_spec (array.c:252) ==12017== by 0x456B6C: resolve_symbol (resolve.c:6438) where resolve.c:3272: gcc_assert (expr && sym == expr->symtree->n.sym); There are no valgrind errors with 4.2.0.
Reduced testcase and backtrace: module gfcbug64_mod1 contains function copy (d) real, intent(in) :: d(:) real :: copy(size (d)) copy = d end function copy end module gfcbug64_mod1 module gfcbug64_mod2 contains subroutine foo (x_o) real, intent(in) :: x_o(5) integer :: s(size (x_o)) contains subroutine bar () use gfcbug64_mod1, only: copy end subroutine bar end subroutine foo end module gfcbug64_mod2 Program received signal SIGSEGV, Segmentation fault. 0x08095f00 in gfc_resolve_expr (e=0x88d1920) at ../../../gcc/gcc/fortran/resolve.c:3265 3265 gcc_assert (expr && sym == expr->symtree->n.sym); (gdb) bt #0 0x08095f00 in gfc_resolve_expr (e=0x88d1920) at ../../../gcc/gcc/fortran/resolve.c:3265 #1 0x08051f8b in resolve_array_bound (e=0x88d1920, check_constant=0) at ../../../gcc/gcc/fortran/array.c:218 #2 0x0805202b in gfc_resolve_array_spec (as=0x88d1858, check_constant=0) at ../../../gcc/gcc/fortran/array.c:252 #3 0x0809acac in resolve_symbol (sym=0x88d0c08) at ../../../gcc/gcc/fortran/resolve.c:6444 #4 0x080a5327 in traverse_ns (st=0x88d0c90, func=0x809ab40 <resolve_symbol>) at ../../../gcc/gcc/fortran/symbol.c:2731 #5 0x080983fa in resolve_types (ns=0x88d0800) at ../../../gcc/gcc/fortran/resolve.c:7403 #6 0x080984c7 in resolve_types (ns=0x88d0218) at ../../../gcc/gcc/fortran/resolve.c:7414 #7 0x080984c7 in resolve_types (ns=0x888d1b0) at ../../../gcc/gcc/fortran/resolve.c:7414 #8 0x0809ab1c in gfc_resolve (ns=0x888d1b0) at ../../../gcc/gcc/fortran/resolve.c:7477 #9 0x0808e6ec in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3256 #10 0x080b005d in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:301 #11 0x08312f28 in toplev_main (argc=2, argv=0xbff77ce4) at ../../../gcc/gcc/toplev.c:1051 Due to the backtrace, I'd think this is related to PR30746. Adding Paul Thomas as CC.
Regression testing shows that it was introduced between 2007-05-11-r124613 and 2007-05-12-r124634. There were two Fortran patches checked in during that period: http://gcc.gnu.org/viewcvs?view=rev&revision=124613 r124613 | pault | 2007-05-11 08:19:57 +0200 (Fri, 11 May 2007) | 12 lines 2007-05-11 Paul Thomas <pault@gcc.gnu.org> PR fortran/31474 (decl.c) http://gcc.gnu.org/viewcvs?view=rev&revision=124615 r124615 | pault | 2007-05-11 13:42:56 +0200 (Fri, 11 May 2007) | 19 lines 2007-05-11 Paul Thomas <pault@gcc.gnu.org> PR fortran/30878 (resolve.c, symbol.c, trans-io.c) http://gcc.gnu.org/viewcvs?view=rev&revision=124633 r124633 | pault | 2007-05-12 08:19:43 +0200 (Sat, 12 May 2007) | 15 lines 2007-05-12 Paul Thomas <pault@gcc.gnu.org> PR fortran/30746 (resolve.c, match.h, gfortran.h)
> r124633 | pault | 2007-05-12 08:19:43 +0200 (Sat, 12 May 2007) | 15 lines > 2007-05-12 Paul Thomas <pault@gcc.gnu.org> > PR fortran/30746 (resolve.c, match.h, gfortran.h) The assert is triggered in check_host_association() which was introduced in this revision - that's why I added Paul as CC :)
One of the problems is that gfc_match_rvalue (&expr); does not set expr to NULL by default or when an error occurs. Therefore gcc_assert (expr && sym == expr->symtree->n.sym); does not fail but crashes randomly. One probably should fix gfc_match_rvalue rather than using simply expr = NULL in check_host_association.
> One probably should fix gfc_match_rvalue rather than using simply expr = NULL > in check_host_association. At least setting result = NULL at the top of gfc_match_rvalue is wrong. (I don't know whether a single test case passes afterwards.) I think I stick to gfc_expr *expr = NULL; in check_host_association. The ICE fails for old_sym->name == "size", i.e. for the intrinsic function SIZE. While "old_sym != sym", they are both in the (old_)sym->module "(intrinsic)".
This does the job: Index: /svn/trunk/gcc/fortran/resolve.c =================================================================== --- /svn/trunk/gcc/fortran/resolve.c (revision 125970) +++ /svn/trunk/gcc/fortran/resolve.c (working copy) @@ -3229,7 +3229,8 @@ check_host_association (gfc_expr *e) return e->expr_type == EXPR_FUNCTION; old_sym = e->symtree->n.sym; - if (gfc_current_ns->parent + if (!old_sym->attr.use_assoc + && gfc_current_ns->parent && gfc_current_ns->parent->parent && old_sym->ns != gfc_current_ns) { and we probably need to exclude intrinsics, I suppose. I'll think about it. Paul
Subject: Bug 32464 Author: pault Date: Mon Jun 25 18:27:59 2007 New Revision: 126000 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126000 Log: 2007-06-25 Paul Thomas <pault@gcc.gnu.org> PR fortran/32464 * resolve.c (check_host_association): Return if the old symbol is use associated. Introduce retval to reduce the number of evaluations of the first-order return value. PR fortran/31494 * match.c (gfc_match_call): If a host associated symbol is not a subroutine, build a new symtree/symbol in the current name space. 2007-06-25 Paul Thomas <pault@gcc.gnu.org> PR fortran/32464 * gfortran.dg/host_assoc_function_2.f90: New test. PR fortran/31494 * gfortran.dg/host_assoc_call_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/host_assoc_call_1.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_function_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk. Thanks for the report, Harald. Paul