Bug 38471 - ICE with subreference pointer assignment
Summary: ICE with subreference pointer assignment
Status: RESOLVED DUPLICATE of bug 34640
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P4 normal
Target Milestone: 4.5.1
Assignee: Paul Thomas
Keywords: ice-on-valid-code
Depends on: 37577
Blocks: 32834 39304
  Show dependency treegraph
Reported: 2008-12-10 11:05 UTC by Tobias Burnus
Modified: 2010-05-18 22:28 UTC (History)
4 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2009-04-04 12:49:17

pointer_assign_7.f90 - a test cae (398 bytes, text/plain)
2008-12-11 16:18 UTC, Tobias Burnus

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2008-12-10 11:05:34 UTC
Reported at

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
  subroutine test_sub(sorb,ipn)
    type(a), intent(in), target :: sorb
    integer, dimension(:), pointer :: ipn

  end subroutine test_sub
end module test
Comment 1 Tobias Burnus 2008-12-10 15:35:24 UTC
More information. The problem is:
which accesses
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;
} *
Comment 2 Tobias Burnus 2008-12-10 18:08:34 UTC
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
Comment 3 Tobias Burnus 2008-12-10 18:25:43 UTC
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;
Comment 4 Tobias Burnus 2008-12-11 10:12:47 UTC
    integer, dimension(:), pointer :: ipn

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.
Comment 5 Paul Thomas 2008-12-11 10:52:06 UTC

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.


Comment 6 Paul Thomas 2008-12-11 11:21:02 UTC
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.


Sorry about the rudimentary diff - the VMware images do not carry much by way of developer's tools.


<       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;
< 	}
Comment 7 Tobias Burnus 2008-12-11 16:18:03 UTC
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.
Comment 8 Paul Thomas 2008-12-22 21:55:01 UTC
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.

Comment 9 Paul Thomas 2009-07-10 17:33:44 UTC
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.

Comment 10 Richard Biener 2010-04-06 11:19:42 UTC
GCC 4.5.0 is being released.  Deferring to 4.5.1.
Comment 11 Daniel Franke 2010-05-18 22:26:40 UTC
As commented multiple times in PR34640, given the similarity of the testcase, the identical backtrace and the same assignee ...
Comment 12 Daniel Franke 2010-05-18 22:28:20 UTC
(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 ***