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]

Re: PATCH: PR fortran/33276: [4.3 Regression] 465.tonto in SPEC CPU 2006 fails to compile


On Sun, Sep 02, 2007 at 12:13:57PM +0200, Tobias Schlüter wrote:
> H.J. Lu wrote:
> >On Sun, Sep 02, 2007 at 01:12:21AM +0200, Tobias Schlüter wrote:
> >>H.J. Lu wrote:
> >>>frame.prev in expand_iterator may be uninitialized. In expand_iterator,
> >>>there are
> >>>
> >>>cleanup:
> >>> gfc_free_expr (start);
> >>> gfc_free_expr (end);
> >>> gfc_free_expr (step);
> >>>
> >>> mpz_clear (trip);
> >>> mpz_clear (frame.value);
> >>>
> >>> iter_stack = frame.prev;
> >>>
> >>> return t;
> >>>}
> >>>
> >>>But frame.prev may be uninitialized when one of goto cleanup is called.
> >>>This patch initializes frame.prev. Shouldn't gcc warn about this?
> >>Ok with a testcase.
> >>
> >
> >Here is a testcase.
> >
> >---
> >module foo
> >   type buffer_type
> >   integer(kind=kind(1)) :: item_end
> >   character(256) :: string
> >   end type
> >   type textfile_type
> >   type(buffer_type) :: buffer
> >   end type
> >contains
> >   function rest_of_line(self) result(res)
> >    type(textfile_type) :: self
> >     intent(inout) :: self
> >     character(128) :: res
> >     res = self%buffer%string(self%buffer%item_end+1: )
> >   end function
> >
> >   subroutine read_intvec_ptr(v)
> >      integer(kind=kind(1)), dimension(:), pointer :: v
> >      integer(kind=kind(1)) :: dim,f,l,i
> >
> >     if (dim>0) then; v = (/ (i, i=f,l)    /)
> >     end if
> >   end subroutine
> >end
> >---
> >
> >[hjl@gnu-27 build_base_o2.0000]$ /usr/gcc-4.3/bin/gfortran -S foo.f90
> >foo.f90:0: internal compiler error: Segmentation fault
> >Please submit a full bug report,
> >with preprocessed source if appropriate.
> >See <http://gcc.gnu.org/bugs.html> for instructions.
> >[hjl@gnu-27 build_base_o2.0000]$
> >
> >However, given the nature of this bug, I don't know if it will fail
> >for everyone.
> 
> As long as it succeeds for everyone after your patch, I don't see how 
> that could be an issue :-)
> 

I am checking in this. Tested on Linux/x86-64. It passed SPEC CPU
2000 and 2006.


H.J.
----
gcc/fortran/

2007-09-02  H.J. Lu  <hongjiu.lu@intel.com>

	PR fortran/33276
	* array.c (expand_iterator): Initialize frame.prev.

gcc/testsuite/

2007-09-02  H.J. Lu  <hongjiu.lu@intel.com>

	PR fortran/33276
	* gfortran.fortran-torture/compile/pr33276.f90: New.

--- gcc/fortran/array.c.foo	2007-08-01 17:14:30.000000000 -0700
+++ gcc/fortran/array.c	2007-09-01 15:57:03.000000000 -0700
@@ -1281,6 +1281,7 @@ expand_iterator (gfc_constructor *c)
 
   mpz_init (trip);
   mpz_init (frame.value);
+  frame.prev = NULL;
 
   start = gfc_copy_expr (c->iterator->start);
   if (gfc_simplify_expr (start, 1) == FAILURE)
--- gcc/testsuite/gfortran.fortran-torture/compile/pr33276.f90.foo	2007-09-02 05:15:30.000000000 -0700
+++ gcc/testsuite/gfortran.fortran-torture/compile/pr33276.f90	2007-09-02 05:14:17.000000000 -0700
@@ -0,0 +1,27 @@
+! PR fortran/33276
+! this used to crash due to an uninitialized variable in expand_iterator.
+
+module foo
+   type buffer_type
+   integer(kind=kind(1)) :: item_end
+   character(256) :: string
+   end type
+   type textfile_type
+   type(buffer_type) :: buffer
+   end type
+contains
+   function rest_of_line(self) result(res)
+    type(textfile_type) :: self
+     intent(inout) :: self
+     character(128) :: res
+     res = self%buffer%string(self%buffer%item_end+1: )
+   end function
+
+   subroutine read_intvec_ptr(v)
+      integer(kind=kind(1)), dimension(:), pointer :: v
+      integer(kind=kind(1)) :: dim,f,l,i
+
+     if (dim>0) then; v = (/ (i, i=f,l)    /)
+     end if
+   end subroutine
+end


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