User account creation filtered due to spam.

Bug 38883 - [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts
Summary: [4.4 Regression] ICE for MVBITS with derived type argument that has run-time ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P4 normal
Target Milestone: 4.4.0
Assignee: Daniel Kraft
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2009-01-16 20:47 UTC by Dick Hendrickson
Modified: 2009-01-27 18:10 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work: 4.3.2
Known to fail: 4.4.0
Last reconfirmed: 2009-01-20 09:47:12


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2009-01-16 20:47:22 UTC
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.
Comment 1 Tobias Burnus 2009-01-16 21:38:09 UTC
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)
Comment 3 Tobias Burnus 2009-01-18 14:28:39 UTC
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
Comment 4 Tobias Burnus 2009-01-18 19:16:14 UTC
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);
Comment 5 Daniel Kraft 2009-01-20 09:47:12 UTC
(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.
Comment 6 Daniel Kraft 2009-01-25 08:36:37 UTC
(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.
Comment 7 Daniel Kraft 2009-01-27 18:08:39 UTC
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

Comment 8 Daniel Kraft 2009-01-27 18:10:44 UTC
Fixed on trunk.
Comment 9 hjl@gcc.gnu.org 2009-01-29 17:43:44 UTC
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