This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gfortran, patch] fix runtime out-of-bounds checking
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Fran?ois-Xavier Coudert <fxcoudert at gmail dot com>
- Cc: patch <gcc-patches at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Date: Thu, 15 Jun 2006 19:23:59 -0700
- Subject: Re: [gfortran, patch] fix runtime out-of-bounds checking
- References: <19c433eb0606070843p58c2f71eicfd0161216498666@mail.gmail.com>
On Wed, Jun 07, 2006 at 05:43:39PM +0200, Fran?ois-Xavier Coudert wrote:
> :ADDPATCH fortran:
>
> Today, as part of my bounds-checking series, here is a patch that
> fixes runtime bounds-checking. Currently, the front-end generates
> errors for valid code (for example, for zero-sized sections), which
> this patch corrects. I also added a check for zero-stride, and checks
> for the last element of sections. I also fixed the text of the
> messages, from "bounds mismatch" to "Array reference out of bounds".
>
> In fact, this patch generates code for the same checks than my
> previous patch for compile-time checks did.
>
> Bootstrapped and regtested on i686-linux, tested that it didn't
> introduce regressions for the testcase run with -fbounds-check. I also
> manually checked that runtime errors are obtained on all the erroneous
> statements of my compile-time testcase
> (http://gcc.gnu.org/ml/fortran/2006-06/msg00071.html).
>
> OK for mainline and 4.1?
>
OK with minor changes.
Index: trans-array.c
===================================================================
--- trans-array.c (revision 114461)
+++ trans-array.c (working copy)
- /* Check lower bound. */
- bound = gfc_conv_array_lbound (desc, dim);
- tmp = info->start[n];
- tmp = fold_build2 (LT_EXPR, boolean_type_node, tmp, bound);
+ /* This is the run-time equivalent of resolve.c's
+ check_dimension(). The logical is more readable there
+ that it is here, with all the trees. */
s/that/than
+ /* Compute the last element of the range, which is not
+ necessarily "end" (think 0:5:3, which doesn't contain 5)
+ and check it against both lower and upper bounds. */
In my mailer the above comment appears malformed. Can you check it?
--
Steve