The following causes an ICE with gfortran 4.9.0 r206484, but compiles successfully with r205975:
integer, dimension(:), allocatable :: c
end type umd
type(umd), dimension(1) :: u
end type mtd
class(mtd), intent(inout) :: s
end subroutine add
end module mtds
$ gfortran -v
Using built-in specs.
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
0x66454f gfc_array_deallocate(tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*)
0x6bc344 gfc_trans_do(gfc_code*, tree_node*)
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:
integer, allocatable :: c(:)
type(umd) :: u(1)
class(mtd), allocatable :: s
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
This is certainly wrong. Feeding it back to gfortran yields:
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
but for longer arrays we need to generate a loop:
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
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!
(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
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.
(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.
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?
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.