This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[Patch, fortran] PR38802 - Seg fault for RESULT with allocatable components
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: gfortran <fortran at gcc dot gnu dot org>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 7 Apr 2009 23:04:56 +0200
- Subject: [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" } }