[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-19 22:23 --- Fixed with r156049. Closing. Thanks for the report! -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-19 22:21 --- Subject: Bug 42804 Author: janus Date: Tue Jan 19 22:21:35 2010 New Revision: 156049 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156049 Log: gcc/fortran/ 2010-01-19 Janus Weil PR fortran/42804 * resolve.c (extract_compcall_passed_object): Set locus for passed-object argument. (extract_ppc_passed_object): Set locus and correctly remove PPC reference. gcc/testsuite/ 2010-01-19 Janus Weil PR fortran/42804 * gfortran.dg/proc_ptr_comp_pass_6.f90: New test. * gfortran.dg/typebound_call_12.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_pass_6.f90 trunk/gcc/testsuite/gfortran.dg/typebound_call_12.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-19 17:46 --- Here is the fix for PPCs, curing both the "must be scalar" error from the last comment as well as the missing-locus ICE (which, as expected, did appear also for PPCs after the other thing was fixed): Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 156040) +++ gcc/fortran/resolve.c (working copy) @@ -4831,11 +4832,12 @@ extract_ppc_passed_object (gfc_expr *e) po->expr_type = EXPR_VARIABLE; po->symtree = e->symtree; po->ref = gfc_copy_ref (e->ref); + po->where = e->where; /* Remove PPC reference. */ ref = &po->ref; while ((*ref)->next) -(*ref) = (*ref)->next; +ref = &(*ref)->next; gfc_free_ref_list (*ref); *ref = NULL; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #7 from janus at gcc dot gnu dot org 2010-01-19 17:24 --- We probably have the same trouble with procedure pointer components, which can also have passed-object arguments. However, when trying to construct an analogous PPC test case, I came across another bug. Here is the test case with a PPC instead of a TBP: MODULE ModA IMPLICIT NONE TYPE, PUBLIC :: A PROCEDURE(a_proc),pointer :: Proc END TYPE A CONTAINS SUBROUTINE a_proc(this, stat) CLASS(A), INTENT(INOUT) :: this INTEGER, INTENT(OUT) :: stat WRITE (*, *) 'a_proc' stat = 0 END SUBROUTINE a_proc END MODULE ModA PROGRAM ProgA USE ModA IMPLICIT NONE INTEGER :: ierr INTEGER :: i TYPE(A), ALLOCATABLE :: arr(:) ALLOCATE(arr(2)) DO i = 1, 2 arr(i)%proc => a_proc CALL arr(i)%Proc(ierr) END DO END PROGRAM ProgA Compiling this gives: CALL arr(i)%Proc(ierr) 1 Error: Passed-object at (1) must be scalar Now, the passed-object is obviously scalar (it's an element of an array), so this surely is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #6 from janus at gcc dot gnu dot org 2010-01-19 17:11 --- (In reply to comment #3) > The problem is that e(xpr)->where->lb == NULL. Exactly. What's important is that the expression "e" here is the passed-object argument. Now the problem really is that when we construct this passed-object argument, we do not set a locus for it. But this is easily fixed: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 156040) +++ gcc/fortran/resolve.c (working copy) @@ -4777,6 +4777,7 @@ extract_compcall_passed_object (gfc_expr* e) po->expr_type = EXPR_VARIABLE; po->symtree = e->symtree; po->ref = gfc_copy_ref (e->ref); + po->where = e->where; } if (gfc_resolve_expr (po) == FAILURE) -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-19 15:41:22 |2010-01-19 17:11:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #5 from janus at gcc dot gnu dot org 2010-01-19 16:39 --- Another observation: If I remove the CLASS argument, give the procedure the NOPASS attribute and call it like this, the ICE also goes away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #4 from janus at gcc dot gnu dot org 2010-01-19 16:35 --- If one replaces the TBP call by a direct call to the subroutine, like this: call a_proc(arr(i),ierr) then the ICE goes away (of course a_proc must be public for this to work). This means it is not a problem of the CLASS argument, but really connected to the type-bound call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-19 15:56 --- The problem is that e(xpr)->where->lb == NULL. The flow is: gfc_conv_procedure_call -> gfc_conv_derived_to_class -> gfc_conv_expr_reference -> gfc_conv_variable etc. I wonder whether the problem is that the CLASS struct has no line number information associated with - but that is just a blind shot. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-19 15:41 --- Confirm. Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0053e011 in gfc_trans_runtime_error_vararg (error=, where=0x13ea980, msgid=0x13ea3f0 "Index '%ld' of dimension 1 of array 'arr' below lower bound of %ld", ap=0x7fffcf10) at fortran/trans.c:393 393 line = LOCATION_LINE (where->lb->location); (gdb) bt #0 0x0053e011 in gfc_trans_runtime_error_vararg (error=, where=0x13ea980, msgid=0x13ea3f0 "Index '%ld' of dimension 1 of array 'arr' below lower bound of %ld", ap=0x7fffcf10) at fortran/trans.c:393 #1 0x0053e7a8 in gfc_trans_runtime_check (error=1 '\001', once=0 '\000', cond=0x2b94f3f0, pblock=0x7fffd310, where=0x13ea980, msgid=0x2cbb7960 "") at /projects/tob/gcc-trunk-checkout/gcc/fortran/trans.c:466 #2 0x00543f03 in gfc_conv_array_ref (se=0x7fffd310, ar=0x13eaa08, sym=, where=) at fortran/trans-array.c:2576 #3 0x0055f491 in gfc_conv_variable (se=0x7fffd310, expr=0x13ea930) at fortran/trans-expr.c:694 #4 0x0055ed3e in gfc_conv_expr_reference (se=0x7fffd310, expr=) at fortran/trans-expr.c:4520 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-mingw32 | GCC host triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 | Keywords||ice-on-valid-code Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-01-19 15:41:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #1 from ian_harvey at bigpond dot com 2010-01-19 14:06 --- Created an attachment (id=19655) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19655&action=view) Source code that demonstrates the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
