Created attachment 22181 [details] module which generates the compiler crash described in PR Compiler crash using attached example... et: sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -o test test_4.f90 test_4.f90: In function ‘test_subroutine’: test_4.f90:24:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. ================== et: sjbespa$ /volumes/dev/gfortran-4.6-trunk/bin/gfortran -v Using built-in specs. COLLECT_GCC=/volumes/dev/gfortran-4.6-trunk/bin/gfortran COLLECT_LTO_WRAPPER=/Volumes/dev/gfortran-4.6-trunk/bin/../libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.4.0 Configured with: ../gfortran-4.6-src/configure --prefix=/volumes/dev/gfortran-4.6-trunk --enable-languages=fortran --disable-bootstrap Thread model: posix gcc version 4.6.0 20101027 (experimental) (GCC)
The ICE happens for: nam = vars(ivar)%name(1) where "name" is the PPC. It fails with 4.5 and 4.6. (4.4 does not support PPC.) ICEs at: ==7160== Invalid read of size 8 ==7160== at 0x57365F: gfc_conv_procedure_call (trans-expr.c:3539) ==7160== by 0x5742C1: gfc_conv_function_expr (trans-expr.c:3937) ==7160== by 0x56DD39: gfc_trans_assignment_1 (trans-expr.c:5675) ==7160== by 0x574AF9: gfc_trans_assignment (trans-expr.c:5847) That's the line: se->expr = info->descriptor;
Here is a slightly reduced/modified test case: implicit none abstract interface character function name_func (ivar) result (res) integer, intent(in) :: ivar end function end interface type var_type procedure(name_func), nopass, pointer :: name end type type(var_type), dimension(1) :: vars print *,vars(1)%name(1) end
Here is an even more compact version of the test case (getting rid of the INTERFACE statement): type t procedure(character), nopass, pointer :: ppc end type type(t),dimension(1) :: v print *,v(1)%ppc() end Apparently the procedure pointer component must be CHARACTER-valued in order to trigger the ICE. Also the object which the PPC is invoked on must be an array.
The ICE is fixed by the following patch: Index: gcc/fortran/trans-expr.c =================================================================== --- gcc/fortran/trans-expr.c (revision 167750) +++ gcc/fortran/trans-expr.c (working copy) @@ -3594,7 +3594,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * if (!se->direct_byref) { - if (sym->attr.dimension || (comp && comp->attr.dimension)) + if ((sym->attr.dimension && !comp) || (comp && comp->attr.dimension)) { if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS) { Will commit as obvious after bootstrapping.
Author: janus Date: Mon Dec 13 19:17:46 2010 New Revision: 167767 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167767 Log: 2010-12-13 Janus Weil <janus@gcc.gnu.org> PR fortran/46201 * trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer components called on a dimensionful base object. 2010-12-13 Janus Weil <janus@gcc.gnu.org> PR fortran/46201 * gfortran.dg/proc_ptr_comp_27.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
Fixed with r167767. Closing. Thanks for the report!
The tests in comments #2 and #3 compile now but segfault at run-time. Am I right to say that they are invalid because the pointers point to nowhere?
(In reply to comment #7) > The tests in comments #2 and #3 compile now but segfault at run-time. Am I > right to say that they are invalid because the pointers point to nowhere? Sure, they're not meant to be runtime tests.
> Sure, they're not meant to be runtime tests. I just wanted to be sure that I had understood the problem. Thanks