Patchwork Fix array access beyond bounds in test cases

login
register
mail settings
Submitter Siddhesh Poyarekar
Date Nov. 9, 2012, 7:12 a.m.
Message ID <20121109124218.05b22661@spoyarek>
Download mbox | patch
Permalink /patch/197959/
State New
Headers show

Comments

Siddhesh Poyarekar - Nov. 9, 2012, 7:12 a.m.
Hi,

I found that some test cases access arrays beyond their bounds.  I
looked up their originating bugzillas and found that the test
cases for pr22506 and pr34005 were likely to be typos since the
original test cases in the report do not have this problem.  For
pr31227 however, I am inclined to think that the test case is
incorrect.  I am not sure what the test case verifies since the array
accesses are obviously beyond bounds.

Regards,
Siddhesh

testsuite/ChangeLog:

2012-11-09  Siddhesh Poyarekar  <siddhesh@redhat.com>

	* gcc.dg/Warray-bounds-3.c (bar): Keep array access within
	bounds for ABDAY, DAY, ABMON, MON, AM_PM.
	* gcc.dg/vect/pr22506.c (foo): Reduce loop iterations to within
	array bounds.
	* gcc.dg/vect/pr34005.c (XdmcpUnwrap): Likewise.
Jeff Law - Nov. 9, 2012, 6:57 p.m.
On 11/09/2012 12:12 AM, Siddhesh Poyarekar wrote:
> Hi,
>
> I found that some test cases access arrays beyond their bounds.  I
> looked up their originating bugzillas and found that the test
> cases for pr22506 and pr34005 were likely to be typos since the
> original test cases in the report do not have this problem.  For
> pr31227 however, I am inclined to think that the test case is
> incorrect.  I am not sure what the test case verifies since the array
> accesses are obviously beyond bounds.
>
> Regards,
> Siddhesh
>
> testsuite/ChangeLog:
>
> 2012-11-09  Siddhesh Poyarekar  <siddhesh@redhat.com>
>
> 	* gcc.dg/Warray-bounds-3.c (bar): Keep array access within
> 	bounds for ABDAY, DAY, ABMON, MON, AM_PM.
> 	* gcc.dg/vect/pr22506.c (foo): Reduce loop iterations to within
> 	array bounds.
> 	* gcc.dg/vect/pr34005.c (XdmcpUnwrap): Likewise.
For 31227 it's checking that an address formed by first computing an 
address outside the array, then adding an offset with the end result 
pointing at a valid location inside the array doesn't generate an 
incorrect warning.

This style of address computation can sometimes be advantageous for the 
loop optimizers to generate (my recollection is it's invalid C/C++ at 
the source level).

The off-by-one aspects of 31227 ought to be corrected.

Ok for the trunk,
jeff
Siddhesh Poyarekar - Nov. 9, 2012, 7:14 p.m.
On Fri, 09 Nov 2012 11:57:44 -0700, Jeff wrote:
> The off-by-one aspects of 31227 ought to be corrected.
> 
> Ok for the trunk,

I don't have write access (not sure if I qualify for it yet with just a
couple of trivial patches so far) so I need someone to commit for me.

Thanks,
Siddhesh
Jeff Law - Nov. 9, 2012, 7:56 p.m.
On 11/09/2012 12:14 PM, Siddhesh Poyarekar wrote:
> On Fri, 09 Nov 2012 11:57:44 -0700, Jeff wrote:
>> The off-by-one aspects of 31227 ought to be corrected.
>>
>> Ok for the trunk,
>
> I don't have write access (not sure if I qualify for it yet with just a
> couple of trivial patches so far) so I need someone to commit for me.
OK.  I took care of committing for you.

jeff

Patch

diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-3.c b/gcc/testsuite/gcc.dg/Warray-bounds-3.c
index 19cdb8e..773f463 100644
--- a/gcc/testsuite/gcc.dg/Warray-bounds-3.c
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-3.c
@@ -34,31 +34,31 @@  bar (struct S *time)
   iov[1].iov_base = (void *) "def";
   iov[1].iov_len = 3;
 
-  for (cnt = 0; cnt <= 7; ++cnt)
+  for (cnt = 0; cnt < 7; ++cnt)
     {
       iov[2 + cnt].iov_base = (void *) (time->abday[cnt] ?: "");
       iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
     }
 
-  for (; cnt <= 14; ++cnt)
+  for (; cnt < 14; ++cnt)
     {
       iov[2 + cnt].iov_base = (void *) (time->day[cnt - 7] ?: "");
       iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
     }
 
-  for (; cnt <= 26; ++cnt)
+  for (; cnt < 26; ++cnt)
     {
       iov[2 + cnt].iov_base = (void *) (time->abmon[cnt - 14] ?: "");
       iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
     }
 
-  for (; cnt <= 38; ++cnt)
+  for (; cnt < 38; ++cnt)
     {
       iov[2 + cnt].iov_base = (void *) (time->mon[cnt - 26] ?: "");
       iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
     }
 
-  for (; cnt <= 40; ++cnt)
+  for (; cnt < 40; ++cnt)
     {
       iov[2 + cnt].iov_base =  (void *) (time->am_pm[cnt - 38] ?: "");
       iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
diff --git a/gcc/testsuite/gcc.dg/vect/pr22506.c b/gcc/testsuite/gcc.dg/vect/pr22506.c
index 5a2d749..a618e32 100644
--- a/gcc/testsuite/gcc.dg/vect/pr22506.c
+++ b/gcc/testsuite/gcc.dg/vect/pr22506.c
@@ -7,8 +7,8 @@  void foo()
 {
     int i;
 
-    for (i=0; i<5; ++i) x[i]=0;
-    for (i=0; i<4; ++i) ;
+    for (i=0; i<3; ++i) x[i]=0;
+    for (i=0; i<2; ++i) ;
 }
 
 /* { dg-final { cleanup-tree-dump "vect" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/pr34005.c b/gcc/testsuite/gcc.dg/vect/pr34005.c
index 813f950..86c3832 100644
--- a/gcc/testsuite/gcc.dg/vect/pr34005.c
+++ b/gcc/testsuite/gcc.dg/vect/pr34005.c
@@ -8,7 +8,8 @@  void XdmcpUnwrap (unsigned char *output, int k)
   int i;
   unsigned char blocks[2][8];
   k = (k == 0) ? 1 : 0;
-  for (i = 0; i < 32; i++)
+
+  for (i = 0; i < 8; i++)
     output[i] = blocks[k][i];
 }