[Bug tree-optimization/31227] New: [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[Bug tree-optimization/31227] New: [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[jakub at gcc dot gnu dot org]

typedef __SIZE_TYPE__ size_t;

extern size_t strlen (const char *);

struct iovec
{
  void *iov_base;
  size_t iov_len;
};

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

extern void foo (size_t, struct iovec *);

void
bar (struct S *time)
{
  struct iovec iov[43];
  size_t cnt;
  iov[0].iov_base = (void *) "abc";
  iov[0].iov_len = 3;

  iov[1].iov_base = (void *) "def";
  iov[1].iov_len = 3;

  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)
    {
      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)
    {
      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)
    {
      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)
    {
      iov[2 + cnt].iov_base =  (void *) (time->am_pm[cnt - 38] ?: "");
      iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
    }

  foo (2 + cnt, iov);
}

issues at -O2 -Wall bogus warnings:
/tmp/w.c:24: warning: array subscript is above array bounds
/tmp/w.c:24: warning: array subscript is above array bounds

Apparently tree loop optimizations decide to use &time->abmon[14] and
&time->mon[30] pointers (which are outside of the range of the arrays) and then
dereferences that pointer - 112B (96B is the size of abmon array and 16B are
extra 2 pointers because the other array is biased by 2).

The testcase is extracted from glibc.


-- 
           Summary: [4.3 Regression] -Warray-bounds doesn't play together
                    with loop optimizations
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jakub at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227

[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2007-03-16 19:17 -------
Another testcase, this time from glibc's malloc.c:
struct malloc_chunk {
  long prev_size;
  long size;
  struct malloc_chunk* fd;
  struct malloc_chunk* bk;
};
typedef struct malloc_chunk* mchunkptr;
struct malloc_state {
  mchunkptr        top;
  mchunkptr        last_remainder;
  mchunkptr        bins[128 * 2 - 2];
};
#define bin_at(m, i) \
  (mchunkptr) (((char *) &((m)->bins[((i) - 1) * 2]))                         \
             - __builtin_offsetof (struct malloc_chunk, fd))

void malloc_init_state(struct malloc_state *av)
{
  int     i;
  mchunkptr bin;

  for (i = 1; i < 128; ++i) {
    bin = bin_at(av,i);
    bin->fd = bin->bk = bin;
  }
}
at -O2 -Wall this warns:
warning: array subscript is below array bounds


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227

[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2007-03-16 21:45 -------
  # cnt_67 = PHI <27(13)>
<L22>:;
  D.1796_118 = &time_14(D)->mon[27];
  ivtmp.56_8 = (unsigned int) D.1796_118;
  D.1797_117 = &iov[27];
  ivtmp.59_7 = (unsigned int) D.1797_117;

  # ivtmp.59_76 = PHI <ivtmp.59_112(17), ivtmp.59_7(14)>
  # ivtmp.56_62 = PHI <ivtmp.56_61(17), ivtmp.56_8(14)>
  # cnt_105 = PHI <cnt_60(17), 27(14)>
<L18>:;
  D.1671_51 = MEM[index: ivtmp.56_62, offset: 0x0ffffff98];
  if (D.1671_51 != 0B) goto <L19>; else goto <L21>;

The proper way to warn about &time_14(D)->mon[27] (even if it's invalid C
and arguably invalid IL) is to look at the possible dereference sites.

Of course a MEM without base but using (unsigned int)&time_14(D)->mon[27]
as index and a negative offset doesn't make this easy.

This looks related to PR26726.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at gcc dot gnu dot
                   |                            |org
  BugsThisDependsOn|                            |26726
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-03-16 21:45:23
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227

[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227

[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[mueller at gcc dot gnu dot org]

------- Comment #3 from mueller at gcc dot gnu dot org  2007-03-21 09:05 -------
both are caused by our well known offender -fivopts. 

the problem why the existing workarounds don't work is because the adress is
first converted to unsigned int before +/- modification is done. the traversal
stops at the type conversion. I'm currently working on fixing that. 


-- 

mueller at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |mueller at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227

[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[mueller at gcc dot gnu dot org]

------- Comment #4 from mueller at gcc dot gnu dot org  2007-03-21 14:16 -------
Created an attachment (id=13242)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13242&action=view)
patch

this is the patch I'm currently testing. would be nice if you could confirm
that this is also fixing your obj-c++ bootstrap problem (which I cannot
reproduce). 

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227

[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[mueller at gcc dot gnu dot org]

-- 

mueller at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227

[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2007-03-21 14:53 -------
obj-c++ bootstrap is actually where the warning triggered correctly, this
was on trunk checkout from yesterday and some tree codes were >= 256,
while an array had just 256 entries and thus e.g.
  tree_contains_struct[CLASS_METHOD_DECL][TS_DECL_NON_COMMON] = 1;
(where CLASS_METHOD_DECL == 259 and TS_DECL_NON_COMMON == 1
and extern unsigned char tree_contains_struct[256][64];)
is supposed to warn.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227

[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[mueller at gcc dot gnu dot org]

------- Comment #6 from mueller at gcc dot gnu dot org  2007-04-18 21:09 -------
Subject: Bug 31227

Author: mueller
Date: Wed Apr 18 21:09:21 2007
New Revision: 123958

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123958
Log:
2007-04-18  Dirk Mueller  <dmueller@suse.de>

       PR diagnostic/31227
       * tree-vrp.c (search_for_addr_array): New.
       (check_array_bounds): Suppress warning about
       address taken of array refs if its not de-referenced.

       * gcc.dg/Warray-bounds-3.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/Warray-bounds-3.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vrp.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227

[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations

[mueller at gcc dot gnu dot org]

------- Comment #7 from mueller at gcc dot gnu dot org  2007-04-18 21:10 -------
Fixed in 4.3.


-- 

mueller at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227