Re: A question about detecting array bounds for case Warray-bounds-3.c

[Matthew Gretton-Dann]

On 26/09/11 10:03, Jonathan Wakely wrote:

On 26 September 2011 08:13, Jiangning Liu wrote:

PING...


-Original Message-
From: Jiangning Liu [mailto:jiangning@arm.com]
Sent: Thursday, September 22, 2011 10:19 AM
To: gcc@gcc.gnu.org
Cc: 'ja...@gcc.gnu.org'; 'muel...@gcc.gnu.org'; 'rgue...@gcc.gnu.org';
Matthew Gretton-Dann
Subject: A question about detecting array bounds for case Warray-
bounds-3.c

Hi,

For case gcc/testsuite/gcc.dg/Warray-bounds-3.c, obviously it is an
invalid C program, because the last iterations of all the loops cause
the access of arrays is beyond the max size of corresponding array
declarations. The condition of checking upper bound should be "<"
rather than "<=".


Which loops are you referring to?

   struct iovec iov[43];
...
   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;
 }

What's wrong with that?  The last element accessed is iov[42] which is ok.


This isn't about access to iov - but rather access to the arrays in 
struct S *time:


struct S
{
  const char *abday[7];
  const char *day[7];
  const char *abmon[12];
  const char *mon[12];
  const char *am_pm[2];
};

...

  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;
}

The last iteration (cnt == 7) will dereference time->abday[7] which is 
one past the end of the array.


As far as I understand it -Warray-bounds should be emitting a warning 
for this case, but PR31227 seemed to be about removing these warnings.


The PR comments do not explain why the array accesses are valid and I'm 
hoping someone can shed some light on the situation - what are we missing?


Thanks,

Matt

--
Matthew Gretton-Dann
Principal Engineer, PD Software - Tools, ARM Ltd

Re: Memory corruption due to word sharing

[Matthew Gretton-Dann]

On Fri, Feb 03, 2012 at 09:37:22AM +, Richard Guenther wrote:
> On Fri, 3 Feb 2012, DJ Delorie wrote:
> 
> > 
> > Jan Kara  writes:
> > >   we've spotted the following mismatch between what kernel folks expect
> > > from a compiler and what GCC really does, resulting in memory corruption 
> > > on
> > > some architectures. Consider the following structure:
> > > struct x {
> > > long a;
> > > unsigned int b1;
> > > unsigned int b2:1;
> > > };
> > 
> > If this structure were volatile, you could try
> > -fstrict-volatile-bitfields, which forces GCC to use the C type to
> > define the access width, instead of doing whatever it thinks is optimal.
> > 
> > Note: that flag is enabled by default for some targets already, most
> > notably ARM.
> 
> Note that -fstrict-volatile-bitfields does not work for
> 
> volatile struct S {
> int i : 1;
> char c;
> } s;
> int main()
> {
>   s.i = 1;
>   s.c = 2;
> }
> 
> where it accesses s.i using SImode.  -fstrict-volatile-bitfields
> falls foul of all the games bitfield layout plays and the
> irrelevantness of the declared bitfield type (but maybe the
> ARM ABI exactly specifies it that way).

Indeed the ARM ABI does - see Section 7.1.7.5 of the PCS available at:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042-/

In fact the example above is pretty much the same as that given in the ABI
docs, and it says that accessing s.i will also cause an access
to s.c, but not vice-versa.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer, PD Software, ARM Ltd.