Bug 38471

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 ***