[Patch, fortran] PR29641 [4.1/4.2/4.3 regression] ICE in gfc_get_derived_type

[Paul Richard Thomas]

:ADDPATCH fortran:

Jakub Jelinek posted this rather embarrassing PR - in spite of all the
testing a month ago, the rather simple testcase, attached, causes an
ICE because the derived type does not have a proc_name.  The fix is
utterly trivial - bail out with a NULL namespace if there is no parent
to search.  The testcase is the reporters, with the addition of a main
programme. Whilst the test is dg-do compile, the programme does run to
test functionality, if needed.

Regtested on Cygwin_NT/PIV - I intend to commit this tomorrow morning
under the obvious rule unless I receive any objections.  I will have
to follow it in a few days with commits to 4.2 and 4.1, since I
temporarily do not have anything other than trunk.  The same goes for
a couple of okayed patches that I will commit tomorrow.

Best regards

Paul

2006-10-31  Paul Thomas  <pault@gcc.gnu.org>

PR fortran/29641
* trans-types.c (gfc_get_derived_type): If the derived type
namespace has neither a parent nor a proc_name, set NULL for
the search namespace.

2006-10-31  Paul Thomas  <pault@gcc.gnu.org>

PR fortran/29641
* gfortran.dg/used_types_11.f90: New test.
-------------- next part --------------
Index: gcc/fortran/trans-types.c
===================================================================
*** gcc/fortran/trans-types.c	(r?vision 118179)
--- gcc/fortran/trans-types.c	(copie de travail)
*************** gfc_get_derived_type (gfc_symbol * deriv
*** 1482,1492 ****
  	 building anew so that potential dummy and actual arguments use the
  	 same TREE_TYPE.  If an equal type is found without a backend_decl,
  	 build the parent version and use it in the current namespace.  */
! 
!       /* Derived types in an interface body obtain their parent reference
! 	 through the proc_name symbol.  */
!       ns = derived->ns->parent ? derived->ns->parent
! 			       : derived->ns->proc_name->ns;
  
        for (; ns; ns = ns->parent)
  	{
--- 1482,1496 ----
  	 building anew so that potential dummy and actual arguments use the
  	 same TREE_TYPE.  If an equal type is found without a backend_decl,
  	 build the parent version and use it in the current namespace.  */
!       if (derived->ns->parent)
! 	ns = derived->ns->parent;
!       else if (derived->ns->proc_name)
! 	/* Derived types in an interface body obtain their parent reference
! 	   through the proc_name symbol.  */
! 	ns = derived->ns->proc_name->ns;
!       else
! 	/* Sometimes there isn't a parent reference!  */
! 	ns = NULL;
  
        for (; ns; ns = ns->parent)
  	{
Index: gcc/testsuite/gfortran.dg/used_types_11.f90
===================================================================
*** gcc/testsuite/gfortran.dg/used_types_11.f90	(r?vision 0)
--- gcc/testsuite/gfortran.dg/used_types_11.f90	(r?vision 0)
***************
*** 0 ****
--- 1,37 ----
+ ! { dg-do compile }
+ ! Tests the patch for PR 29641, in which an ICE would occur with
+ ! the ordering of USE statements below.
+ !
+ ! Contributed by Jakub Jelinek <jakub@gcc.gnu.org>
+ !
+ module A
+   type :: T
+     integer :: u
+   end type T
+ end module A
+ 
+ module B
+ contains
+   function foo()
+     use A
+     type(T), pointer :: foo
+     nullify (foo)
+   end function foo
+ end module B
+ 
+ subroutine bar()
+   use B             ! The order here is important
+   use A             ! If use A comes before use B, it works
+   type(T), pointer :: x
+   x => foo()
+ end subroutine bar
+ 
+   use B
+   use A
+   type(T), pointer :: x
+   type(T), target  :: y
+   x => y
+   print *, associated (x)
+   x => foo ()
+   print *, associated (x)
+ end
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Change.logs
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20061030/1a4dc800/attachment.ksh>