The following program causes an internal compiler error. If the single reference to NF3 in the MVBITS argument list is changed to "3" the program compiles and executes. Dick Hendrickson module yg0009_stuff ! fails on Windows XP ! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC) type unseq integer I end type contains SUBROUTINE YG0009(TDA2L,NF4,NF3,NF1,MF1,MF4,MF3) TYPE(UNSEQ) TDA2L(4,3) CALL MVBITS (TDA2L(4:1:-1,1:3)%I,2, $ 4, TDA2L(4:1:-1,1:NF3)%I, 3) ! these also ICE, but seem needlessly complex ! TYPE(UNSEQ) TDA2L(NF4,NF3) ! ! CALL MVBITS (TDA2L(NF4:NF1:MF1,NF1:NF3)%I,2, ! $ 4, TDA2L(-MF4:-MF1:-NF1,-MF1:-MF3)%I, 3) ! but, you might as well try them in your spare time ;) END SUBROUTINE end module yg0009_stuff program try_yg0009 use yg0009_stuff type(unseq) tda2l(4,3) call yg0009(tda2l,4,3,1,-1,-4,-3) end C:\gfortran>gfortran try_yg0009.f try_yg0009.f: In function 'yg0009': try_yg0009.f:12: internal compiler error: in gfc_trans_allocate_array_storage, a t fortran/trans-array.c:558 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
Confirm. Working: 4.4.0 20081029 (experimental) [trunk revision 141421] Failing: 4.4.0 20081103 (experimental) [trunk revision 141544] (assuming that my tree was clean back then)
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141516 ?
Slightly reduced test case below. If the FROM= and TO= arguments ("A()%I") are not the same, the program does not ICE. Neither does it if one changes the bound "N2" to "2" (but it does if one changes the second argument to "(2:1:-1)"). Thus the problem seems to be closely linked with needing to create a copy of the second argument. That is related to PR 38887, where unpacking the copied 2nd argument generated an ICE at run time. module yg0009_stuff implicit none type unseq integer I end type contains SUBROUTINE YG0009(A,N2) TYPE(UNSEQ) A(2) TYPE(UNSEQ) B(2) integer :: N2 CALL MVBITS (A(1:2)%I,1, 1, A(1:N2)%I, 1) END SUBROUTINE end module yg0009_stuff
Some more data: Using printf("Node: tmp = %s\n", tree_code_name[TREE_CODE (tmp)]); printf("Node: desc = %s\n", tree_code_name[TREE_CODE (gfc_get_element_type (TREE_TYPE (desc)))]); gcc_assert (tmp == gfc_get_element_type (TREE_TYPE (desc))); one sees: Node: tmp = record_type Node: desc = integer_type desc gets its type via "gfc_get_array_type_bounds()" in gfc_trans_create_temp_array. And then gfc_get_element_type (TREE_TYPE (desc)) And "tmp" via the following: if (fsym->attr.intent == INTENT_INOUT) initial = parmse.expr; else initial = NULL_TREE; in gfc_conv_elemental_dependencies which then in gfc_trans_allocate_array_storage gets accessed as: tmp = TREE_TYPE (initial); /* Pointer to descriptor. */ gcc_assert (TREE_CODE (tmp) == POINTER_TYPE); tmp = TREE_TYPE (tmp); /* The descriptor itself. */ tmp = gfc_get_element_type (tmp);
(In reply to comment #2) > http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141516 ? > Seems to be my fault, quite plausibly :D I will work on this.
(In reply to comment #4) > in gfc_conv_elemental_dependencies which then in > gfc_trans_allocate_array_storage gets accessed as: > tmp = TREE_TYPE (initial); /* Pointer to descriptor. */ > gcc_assert (TREE_CODE (tmp) == POINTER_TYPE); > tmp = TREE_TYPE (tmp); /* The descriptor itself. */ > tmp = gfc_get_element_type (tmp); This is very likely the problem here; I guess 'tmp' should get integer_type instead of record_type, too, and the code above misses to do so. When I wrote this fragment, it was more or less just a trial-and-error process as I (still) don't know the backend-stuff quite well; I will try to get the correct sequence which will hopefully fix this problem.
Subject: Bug 38883 Author: domob Date: Tue Jan 27 18:07:54 2009 New Revision: 143707 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143707 Log: 2009-01-27 Daniel Kraft <d@domob.eu> PR fortran/38883 * trans-stmt.c (gfc_conv_elemental_dependencies): Create temporary for the real type needed to make it work for subcomponent-references. 2009-01-27 Daniel Kraft <d@domob.eu> PR fortran/38883 * gfortran.dg/mvbits_6.f90: New test. * gfortran.dg/mvbits_7.f90: New test. * gfortran.dg/mvbits_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/mvbits_6.f90 trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90 trunk/gcc/testsuite/gfortran.dg/mvbits_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk.
Subject: Bug 38883 Author: hjl Date: Thu Jan 29 17:43:14 2009 New Revision: 143765 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143765 Log: 2009-01-29 H.J. Lu <hongjiu.lu@intel.com> 2009-01-28 Richard Guenther <rguenther@suse.de> PR middle-end/38908 * g++.dg/warn/Wuninitialized-2.C: New testcase. 2009-01-27 Daniel Kraft <d@domob.eu> PR fortran/38883 * gfortran.dg/mvbits_6.f90: New test. * gfortran.dg/mvbits_7.f90: New test. * gfortran.dg/mvbits_8.f90: New test. 2009-01-21 Daniel Kraft <d@domob.eu> PR fortran/38887 * gfortran.dg/mvbits_5.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-2.C - copied unchanged from r143764, trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-2.C branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_5.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_5.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_6.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_6.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_7.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_7.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/mvbits_8.f90 - copied unchanged from r143764, trunk/gcc/testsuite/gfortran.dg/mvbits_8.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog