Bug 59765

Summary: [4.9/5 Regression] [OOP] ICE on valid with finalizable array components
Product: gcc Reporter: Andrew Benson <abensonca>
Component: fortranAssignee: Paul Thomas <pault>
Status: RESOLVED FIXED    
Severity: normal CC: andrew, burnus, damian, janus, mikael, pault, sfilippone, xarthisius.kk
Priority: P4 Keywords: ice-on-valid-code
Version: 4.9.0   
Target Milestone: 4.9.3   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2014-01-10 00:00:00
Bug Depends on:    
Bug Blocks: 37336    

Description Andrew Benson 2014-01-10 19:51:48 UTC
The following causes an ICE with gfortran 4.9.0 r206484, but compiles successfully with r205975:

module mtds
  type umd
     integer, dimension(:), allocatable :: c
  end type umd
  type mtd
     type(umd), dimension(1) :: u
  end type mtd
contains
  subroutine add(s)
    class(mtd), intent(inout) :: s
  end subroutine add
end module mtds


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/nfs/04/osu7985/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/nfs/04/osu7985/Galacticus/Tools --enable-languages=c++,c,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20140109 (experimental) (GCC) 

$ gfortran -c tmp1.F90 -o tmp1.o 
tmp1.F90: In function ‘__final_mtds_Mtd’:
tmp1.F90:10:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:145
     class(mtd), intent(inout) :: s
 ^
0x65cd8d gfc_conv_descriptor_data_get(tree_node*)
        ../../trunk/gcc/fortran/trans-array.c:145
0x66454f gfc_array_deallocate(tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*)
        ../../trunk/gcc/fortran/trans-array.c:5335
0x6bedfd gfc_trans_deallocate(gfc_code*)
        ../../trunk/gcc/fortran/trans-stmt.c:5421
0x658c27 trans_code
        ../../trunk/gcc/fortran/trans.c:1782
0x6bc344 gfc_trans_simple_do
        ../../trunk/gcc/fortran/trans-stmt.c:1427
0x6bc344 gfc_trans_do(gfc_code*, tree_node*)
        ../../trunk/gcc/fortran/trans-stmt.c:1590
0x658cea trans_code
        ../../trunk/gcc/fortran/trans.c:1732
0x6827be gfc_generate_function_code(gfc_namespace*)
        ../../trunk/gcc/fortran/trans-decl.c:5605
0x65a6c1 gfc_generate_module_code(gfc_namespace*)
        ../../trunk/gcc/fortran/trans.c:1956
0x61689d translate_all_program_units
        ../../trunk/gcc/fortran/parse.c:4523
0x61689d gfc_parse_file()
        ../../trunk/gcc/fortran/parse.c:4733
0x654815 gfc_be_parse_file
        ../../trunk/gcc/fortran/f95-lang.c:188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


The ICE goes away if I do any of the following:

* Change "class(mtd)" to "type(mtd)"

* Make the "u" component of "mtd" allocatable, or make it a scalar

* Make the "c" component of "umd" non-allocatable
Comment 1 janus 2014-01-10 22:14:34 UTC
Confirmed. Slightly reduced test case:

  type umd
      integer, allocatable :: c(:)
  end type
  type mtd
      type(umd) :: u(1)
  end type
  class(mtd), allocatable :: s
end


I'm pretty sure this is my fault. I'd bet for r206379.
Comment 2 Dominique d'Humieres 2014-01-10 22:18:42 UTC
> I'm pretty sure this is my fault. I'd bet for r206379.

r206362 is OK, r206444 is not.
Comment 3 janus 2014-01-10 22:26:23 UTC
(In reply to Dominique d'Humieres from comment #2)
> > I'm pretty sure this is my fault. I'd bet for r206379.
> 
> r206362 is OK, r206444 is not.

... and indeed reverting r206379 makes the ICE go away. However I don't think there is anything wrong with that revision. It probably just exposed a lower lying problem.
Comment 4 janus 2014-01-10 22:59:01 UTC
I think what happens is something like the following:

generate_finalization_wrapper currently produces code like this on the test case:

type(mtd), pointer :: ptr
deallocate(ptr%u(:)%c)

This is certainly wrong. Feeding it back to gfortran yields:

  deallocate(ptr%u%c)
             1
Error: Component to the right of a part reference with nonzero rank must not have the ALLOCATABLE attribute at (1)


For the test case here it is sufficient to just use

deallocate(ptr%u(1)%c)

but for longer arrays we need to generate a loop:

do i=...
  deallocate(ptr%u(i)%c)
end do
Comment 5 janus 2014-01-10 23:10:03 UTC
In particular this code in finalize_component produces a full-array reference for array components:

  if (comp->attr.dimension || comp->attr.codimension
      || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)
	  && (CLASS_DATA (comp)->attr.dimension
	      || CLASS_DATA (comp)->attr.codimension)))
    {
      ref->next = gfc_get_ref ();
      ref->next->type = REF_ARRAY;
      ref->next->u.ar.dimen = 0;
      ref->next->u.ar.as = comp->ts.type == BT_CLASS ? CLASS_DATA (comp)->as
							: comp->as;
      e->rank = ref->next->u.ar.as->rank;
      ref->next->u.ar.type = e->rank ? AR_FULL : AR_ELEMENT;
    }


Either we have to scalarize this later on (this is currently not implemented, because this is forbidden in actual Fortran code, see comment 4), or we have to generate a loop directly instead of the full-array expression.
Comment 6 Jakub Jelinek 2014-04-22 11:36:35 UTC
GCC 4.9.0 has been released
Comment 7 Jakub Jelinek 2014-07-16 13:29:36 UTC
GCC 4.9.1 has been released.
Comment 8 Dominique d'Humieres 2014-07-17 17:20:40 UTC
*** Bug 60529 has been marked as a duplicate of this bug. ***
Comment 9 Dominique d'Humieres 2014-07-17 17:24:36 UTC
*** Bug 61766 has been marked as a duplicate of this bug. ***
Comment 10 Dominique d'Humieres 2014-07-17 17:30:11 UTC
*** Bug 61819 has been marked as a duplicate of this bug. ***
Comment 11 Jakub Jelinek 2014-10-30 10:39:40 UTC
GCC 4.9.2 has been released.
Comment 12 Alexander Vogt 2014-12-10 11:52:15 UTC
Is there any update on this? This regression currently prohibits moving to 4.9.x for my code :(

Thanks a lot!
Comment 14 Mikael Morin 2015-02-03 14:59:55 UTC
(In reply to janus from comment #5)
> Either we have to scalarize this later on (this is currently not
> implemented, because this is forbidden in actual Fortran code, see comment
> 4), or we have to generate a loop directly instead of the full-array
> expression.

For what it's worth, class.c's finalizer_insert_packed call generates a scalarization loop "by hand"; maybe part of it can be reused.
Comment 15 Paul Thomas 2015-02-08 15:39:12 UTC
This is one and the same as PR64932 for which I have just posted a fix. Thanks to Dominique for noticing this.

Since it is a regression, I will be posting to 4.9 and 5.0.

Cheers


Paul
Comment 16 Alipasha 2015-02-10 04:04:36 UTC
(In reply to Paul Thomas from comment #15)
> This is one and the same as PR64932 for which I have just posted a fix.
> Thanks to Dominique for noticing this.
> 
> Since it is a regression, I will be posting to 4.9 and 5.0.
> 
> Cheers
> 
> 
> Paul

Is this fix committed to the trunk? I just updated to 

GNU Fortran (GCC) 5.0.0 20150210 (experimental)

and still get the ICE with the test case:

in gfc_conv_descriptor_data_get, at fortran/trans-array.c:157
...

Thank you for looking into this :)
Comment 17 Dominique d'Humieres 2015-02-10 04:35:59 UTC
> Is this fix committed to the trunk?

Not yet.
Comment 18 Dominique d'Humieres 2015-02-14 10:29:57 UTC
I think this PR is now fixed by r220654 for trunk (5.0) and r220659 (4.9).
Comment 19 Dominique d'Humieres 2015-02-15 16:03:00 UTC
> I think this PR is now fixed by r220654 for trunk (5.0) and r220659 (4.9).

Closing as FIXED.