subroutine fft(tab) type fft_tab_type complex, dimension(:), pointer :: omega end type fft_tab_type type(fft_tab_type), intent(in) :: tab i = ubound(tab%omega,1) end subroutine fft cd /home/lei/SPEC2004/benchspec/CPU2004/459.GemsFDTD/run/00000001/ ~/gcc/bin/gfortran -O0 -c bugreport.f90 bugreport.f90:0: internal compiler error: Segmentation fault
I see that one to (on i686-linux and sparc-solaris).
Confirmed, here is the backtrace: #0 0x00042320 in gfc_simplify_bound (array=0x1, dim=0x42304530, upper=1) at /Users/pinskia/ src/local/gcc/gcc/fortran/simplify.c:1799 #1 0x00020300 in do_simplify (specific=0x4152aaa8, e=0x42304110) at /Users/pinskia/src/local/ gcc/gcc/fortran/intrinsic.c:2620 #2 0x000207ac in gfc_intrinsic_func_interface (expr=0x4152aaa8, error_flag=1) at /Users/pinskia/ src/local/gcc/gcc/fortran/intrinsic.c:2896 #3 0x0003a3b4 in gfc_resolve_expr (e=0x42304110) at /Users/pinskia/src/local/gcc/gcc/fortran/ resolve.c:861
The specific problem statement appears to be line 1799/1801 in gfc_simplify_bound: return gfc_copy_expr (as->upper[i-1]); or return gfc_copy_expr (as->lower[i-1]); The problematic execution sequence is (apologies for any errors due to only fragmentary understanding of the data structures involved): * as is initially set to array->as, where array is the expression sent to gfc_simplify_bound; the symbol from array->symtree->n.sym is named as the derived variable e.g. "tab" in the example. This array spec is null (I presume it's not the right place to get it). * Because there are component references, the following loop walks them. * The first reference is the COMPONENT reference (the name associated with array->symtree->n.sym at this point is the derived type itself e.g. "fft_tab_type" in the example code); it then attempts to take the array spec from there. Unfortunately, this spec is ALSO null. * The second reference is the ARRAY reference; at this point it kicks out of the walk loop because there's nothing following. * The ref variable now points to a gfc_array_ref, and this is actually checked by the code -- if ref->type is not REF_ARRAY or if ref->u.ar.type is not AR_FULL, it kicks out of the routine with a NULL return value. * At this point, as is still null; I presume that with the appropriate logic, it could be taken from ref->u.ar, a simplistic fix like the following: if (! as) as = ref->u.ar.as; seems to fix the problem, with implications down the line unknown.
Further testing indicates that the bug is caused by an array in a derived type -- the pointer is not necessary. program test implicit none type test_type integer, dimension(5) :: a end type test_type type (test_type) :: tt integer i i = ubound(tt%a) end program test In this case, as originally takes on a non-null value (I presume because the type member is now an array rather than a pointer), but in the component walk, it is set to NULL via ref->u.c.sym->as. I think this may be instructive about the precise nature of the bug as originally reported.
Patch here: http://gcc.gnu.org/ml/fortran/2005-02/msg00357.html
Subject: Bug 19479 CVSROOT: /cvs/gcc Module name: gcc Changes by: tobi@gcc.gnu.org 2005-03-01 00:41:42 Modified files: gcc/fortran : ChangeLog simplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: bound_1.f90 Log message: fortran/ PR fortran/19479 * simplify.c (gfc_simplify_bound): Rename to ... (simplify_bound): ... this and overhaul. testsuite/ PR fortran/19479 * gfortran.dg/bound_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.339&r2=1.340 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/simplify.c.diff?cvsroot=gcc&r1=1.19&r2=1.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5099&r2=1.5100 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/bound_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
Subject: Bug 19479 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: tobi@gcc.gnu.org 2005-03-01 00:42:11 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: bound_1.f90 Log message: fortran/ PR fortran/19479 * simplify.c (gfc_simplify_bound): Rename to ... (simplify_bound): ... this and overhaul. testsuite/ PR fortran/19479 * gfortran.dg/bound_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.10&r2=1.5084.2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/bound_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
Subject: Bug 19479 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: tobi@gcc.gnu.org 2005-03-01 00:43:16 Modified files: gcc/fortran : ChangeLog simplify.c Log message: fortran/ PR fortran/19479 * simplify.c (gfc_simplify_bound): Rename to ... (simplify_bound): ... this and overhaul. testsuite/ PR fortran/19479 * gfortran.dg/bound_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.3&r2=1.335.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/simplify.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19&r2=1.19.2.1
Fixed on mainline and branch.