[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

2009-01-29 Thread hjl at gcc dot gnu dot org 


--- Comment #9 from hjl at gcc dot gnu dot org  2009-01-29 17:43 ---
Subject: Bug 38883

Author: hjl
Date: Thu Jan 29 17:43:14 2009
New Revision: 143765

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143765
Log:
2009-01-29  H.J. Lu  hongjiu...@intel.com

2009-01-28  Richard Guenther  rguent...@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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

2009-01-27 Thread domob at gcc dot gnu dot org 


--- Comment #7 from domob at gcc dot gnu dot org  2009-01-27 18:08 ---
Subject: Bug 38883

Author: domob
Date: Tue Jan 27 18:07:54 2009
New Revision: 143707

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

2009-01-27 Thread domob at gcc dot gnu dot org 


--- Comment #8 from domob at gcc dot gnu dot org  2009-01-27 18:10 ---
Fixed on trunk.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

2009-01-25 Thread domob at gcc dot gnu dot org 


--- Comment #6 from domob at gcc dot gnu dot org  2009-01-25 08:36 ---
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

2009-01-20 Thread domob at gcc dot gnu dot org 


--- Comment #5 from domob at gcc dot gnu dot org  2009-01-20 09:47 ---
(In reply to comment #2)
 http://gcc.gnu.org/viewcvs?root=gccview=revrev=141516  ?
 

Seems to be my fault, quite plausibly :D  I will work on this.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-01-16 21:38:10 |2009-01-20 09:47:12
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

2009-01-18 Thread burnus at gcc dot gnu dot org 


--- Comment #3 from burnus at gcc dot gnu dot org  2009-01-18 14:28 ---
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


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4 Regression] Internal   |[4.4 Regression] ICE for
   |Compiler Error for MVBITS   |MVBITS with derived type
   |with derived type argument  |argument that has run-time
   |that has run-time subscripts|subscripts


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883

[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts

2009-01-18 Thread burnus at gcc dot gnu dot org 


--- Comment #4 from burnus at gcc dot gnu dot org  2009-01-18 19:16 ---
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);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883