Reported at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bf908dba87ce677a Valgrind shows: ==10280== Invalid read of size 8 ==10280== at 0x4B67E2: gfc_trans_pointer_assignment (trans-expr.c:4076) ==10280== by 0x4956AF: gfc_trans_code (trans.c:1111) ==10280== by 0x4AD5FB: gfc_generate_function_code (trans-decl.c:3887) trans-expr.c is: 4066 if (expr1->symtree->n.sym->attr.subref_array_pointer) 4067 { 4068 decl = expr1->symtree->n.sym->backend_decl; 4069 gfc_init_se (&rse, NULL); 4070 rse.descriptor_only = 1; 4071 gfc_conv_expr (&rse, expr2); 4072 tmp = gfc_get_element_type (TREE_TYPE (rse.expr)); 4073 tmp = fold_convert (gfc_array_index_type, size_in_bytes (tmp)); 4074 if (!INTEGER_CST_P (tmp)) 4075 gfc_add_block_to_block (&lse.post, &rse.pre); 4076 gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp); 4077 } module test implicit none !=================================================== type b integer :: j end type b !=================================================== type a type(b), dimension(4) :: i end type a !=================================================== contains !=================================================== subroutine test_sub(sorb,ipn) type(a), intent(in), target :: sorb integer, dimension(:), pointer :: ipn ipn=>sorb%i%j end subroutine test_sub !=================================================== end module test
More information. The problem is: GFC_DECL_SPAN(decl) which accesses DECL_LANG_SPECIFIC(node)->span however, DECL_LANG_SPECIFIC(node) == NULL as can be seen below. (gdb) p decl->decl_common.lang_specific $15 = (struct lang_decl *) 0x0 (gdb) pt decl->decl_common.lang_specific type = struct lang_decl { tree saved_descriptor; tree stringlen; tree addr; tree span; } *
Paul, do you have an idea? span is set in trans-decl.c's gfc_get_symbol_decl: if (sym->attr.subref_array_pointer) { [...] GFC_DECL_SPAN (decl) = span; I wondered whether in gfc_check_pointer_assign the attr.subref_array_pointer is set, but I indeed see: (gdb) p lvalue->symtree->n.sym->attr.subref_array_pointer $7 = 1
OK. I found it, though I'm not sure yet how to solve it best (maybe something else needs to be moved up as well?) - and I won't have time to work on this the next day(s?). gfc_get_symbol_decl (gfc_symbol * sym) [...] if ((sym->attr.dummy && ! sym->attr.function) || (sym->attr.result && byref)) { // We enter here as the POINTER is a DUMMY [...] return sym->backend_decl; } [...] if (sym->attr.subref_array_pointer) { tree span;
integer, dimension(:), pointer :: ipn ipn=>sorb%i%j I tried it with ipn being no dummy argument and it crashes as well. And I forgot to write the name of the initial reporter in comment 0. The credit for finding the bug goes to Sudeep Punnathanam.
Tobias, It's a bit tough to call it a regression, since the earlier versions of gfortran produced wrong code. Is this worth fixing for 4.4? If we get the array descriptor business sorted out, it should go away. Cheers Paul
This cures the ICE and allows correct code within the subroutine. 'span' is not transferred in the call and so wrong code is produced if the pointer is subsequently used in the caller. I can apply it if you like. Paul Sorry about the rudimentary diff - the VMware images do not carry much by way of developer's tools. trans-decl.c 1012,1030d1011 < < if (sym->attr.subref_array_pointer < && DECL_LANG_SPECIFIC (sym->backend_decl) == NULL) < gfc_allocate_lang_decl (sym->backend_decl); < < if (sym->attr.subref_array_pointer < && GFC_DECL_SPAN (sym->backend_decl) == NULL) < { < tree span; < GFC_DECL_SUBREF_ARRAY_P (sym->backend_decl) = 1; < span = build_decl (VAR_DECL, create_tmp_var_name ("span"), < gfc_array_index_type); < gfc_finish_var_decl (span, sym); < TREE_STATIC (span) = TREE_STATIC (sym->backend_decl); < DECL_ARTIFICIAL (span) = 1; < DECL_INITIAL (span) = build_int_cst (gfc_array_index_type, 0); < < GFC_DECL_SPAN (sym->backend_decl) = span; < }
Created attachment 16885 [details] pointer_assign_7.f90 - a test cae As fj pointed out: This PR might be a duplicate of PR 34640. The patch looks quite similar (identical?). The attached test case works when "type b" does not contain "character :: c" and fails if it does.
All routes to deal with this are way too invasive for this stage in the proceedings. This PR must wait for the array descriptor upgrade, so I am suspending it for now. Paul
I never accepted this to be a regression and now, when it is the only one, I feel that it is time to register that :-) It will, of course, be dealt with once I attack the array descriptor business. ice-on-invalid-code gives it quite enough importance. Paul
GCC 4.5.0 is being released. Deferring to 4.5.1.
As commented multiple times in PR34640, given the similarity of the testcase, the identical backtrace and the same assignee ...
(In reply to comment #11) > As commented multiple times in PR34640, given the similarity of the testcase, > the identical backtrace and the same assignee ... *** This bug has been marked as a duplicate of 34640 ***