This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch, fortran] PR38802 - Seg fault for RESULT with allocatable components


This is verging on obvious.  Without the patch, the result in the test
case is nullified too early and then nullified again, after the
automatic array has been established.

First:

  D.1065 = D.1062;
  S.35 = 0;
  while (1)
    {
      if (S.35 > D.1065) goto L.7;
      (*__result.0)[S.35].mons.data = 0B;
      S.35 = S.35 + 1;
    }

when D.1062 (   D.1062 = size.23 - 1; a bit later) has not been
initialized.  Then, later on:

    t_2.24.mons.data = 0B;
    D.1036 = t_2.24;
    {
      integer(kind=8) D.1038;
      integer(kind=8) S.25;

      D.1038 = stride.21;
      S.25 = 1;
      while (1)
        {
          if (S.25 > D.1034) goto L.4;
          (*__result.0)[S.25 * D.1038 + D.1033] = D.1036;
          S.25 = S.25 + 1;
        }
      L.4:;
    }

which is correct but repeats the effect of the first loop.  The fix is
to eliminate the first, which is accomplished by the modification of
one line.

Bootstrapped and regtested on x86_64/FC9 - OK for trunk?

Paul

2009-04-07  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/38863
	* trans-array.c (gfc_trans_deferred_array): Return if this
	is a result variable.

2009-04-07  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/38863
	* gfortran.dg/alloc_comp_result_1.f90: New test.
Index: gcc/fortran/trans-array.c
===================================================================
--- gcc/fortran/trans-array.c	(revision 145648)
+++ gcc/fortran/trans-array.c	(working copy)
@@ -5825,8 +5825,8 @@
       gfc_trans_vla_type_sizes (sym, &fnblock);
     }
 
-  /* Dummy and use associated variables don't need anything special.  */
-  if (sym->attr.dummy || sym->attr.use_assoc)
+  /* Dummy, use associated and result variables don't need anything special.  */
+  if (sym->attr.dummy || sym->attr.use_assoc || sym->attr.result)
     {
       gfc_add_expr_to_block (&fnblock, body);
 
Index: gcc/testsuite/gfortran.dg/alloc_comp_result_1.f90
===================================================================
--- gcc/testsuite/gfortran.dg/alloc_comp_result_1.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/alloc_comp_result_1.f90	(revision 0)
@@ -0,0 +1,33 @@
+! { dg-do run }
+! Test the fix for PR38802, in which the nulling of the result 'p'
+! in 'a_fun' would cause a segfault.
+!
+! Posted on the gfortran list by Marco Restelli http://gcc.gnu.org/ml/fortran/2009-01/
+
+!
+module mod_a
+  implicit none
+  public :: a_fun, t_1, t_2
+  private
+  type t_1
+    real :: coeff
+  end type t_1
+  type t_2
+    type(t_1), allocatable :: mons(:)
+  end type t_2
+contains
+  function a_fun(r) result(p)
+    integer, intent(in) :: r
+    type(t_2) :: p(r+1)
+    p = t_2 ([t_1 (99)])
+  end function a_fun
+end module mod_a
+
+program test
+  use mod_a, only: a_fun, t_1, t_2
+  implicit none
+  type(t_2) x(1)
+  x = a_fun(0)
+  if (any (x(1)%mons%coeff .ne. 99)) call abort
+end program test
+! { dg-final { cleanup-modules "mod_a" } }

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]