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
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.
> I'm pretty sure this is my fault. I'd bet for r206379. r206362 is OK, r206444 is not.
(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.
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
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.
GCC 4.9.0 has been released
GCC 4.9.1 has been released.
*** Bug 60529 has been marked as a duplicate of this bug. ***
*** Bug 61766 has been marked as a duplicate of this bug. ***
*** Bug 61819 has been marked as a duplicate of this bug. ***
GCC 4.9.2 has been released.
Is there any update on this? This regression currently prohibits moving to 4.9.x for my code :( Thanks a lot!
https://plus.google.com/115499135426714220931/posts/7HfURniQGH9
(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.
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
(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 :)
> Is this fix committed to the trunk? Not yet.
I think this PR is now fixed by r220654 for trunk (5.0) and r220659 (4.9).
> I think this PR is now fixed by r220654 for trunk (5.0) and r220659 (4.9). Closing as FIXED.