[Bug middle-end/37130] warning: array subscript is above array bounds.

[Bug middle-end/37130] warning: array subscript is above array bounds.

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2011-12-07
                 CC|                            |fxcoudert at gcc dot
                   |                            |gnu.org
      Known to work|                            |
            Version|4.3.1                       |4.5.0
         Resolution|FIXED                       |
     Ever Confirmed|0                           |1

--- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> 2011-12-07 07:12:54 UTC ---
I have the same issue with 4.3.5 and 4.4.6 on x86_64-apple-darwin11 when
compiling with "-m32 -O2 -W -Wall". It is fixed with 4.5.3 (at least). I'm
reopening as 4.4 is still an active branch.

[Bug middle-end/37130] warning: array subscript is above array bounds.

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.4.2                       |4.5.0

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-07 12:44:10 UTC ---
It's not a regression.

[Bug middle-end/37130] warning: array subscript is above array bounds.

[scott dot gccbugs dot 2009 at scottrix dot co dot uk]

------- Comment #6 from scott dot gccbugs dot 2009 at scottrix dot co dot uk  2010-02-12 16:16 -------
I get this on 4.4.3 for x86 32bit, is there a patch, or will I have to wait for
4.5 to be released ?


-- 


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

[Bug middle-end/37130] warning: array subscript is above array bounds.

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-02 19:30 -------
Works with 4.4 and 4.5.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
      Known to fail|                            |4.3.4
      Known to work|                            |4.4.2 4.5.0
         Resolution|                            |FIXED
   Target Milestone|---                         |4.4.2


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

[Bug middle-end/37130] warning: array subscript is above array bounds.

[enrio at online dot no]

------- Comment #4 from enrio at online dot no  2009-10-23 10:06 -------
In my example code there is a pointer to a struct that has an array as the
first member. I appears that the compiler treats the pointer as a pointer to
this first member, and flags a loop that writes outside the first member
already at the first iteration. The code uses an integer offset from the
pointer, and the pointer itself is not changed.

If the members are reordered so that an unsigned char member becomes the first
one, the warning goes away. (But the example comes from a driver, and the
struct maps hardware registers, so it cannot be reordered at a whim.)

If the loop is modified so that it begins within the array, the warning goes
away, even the iterator has a constant end condition - outside the array.

If the loop is modified so that it begins exactly at the first byte after the
array, there are four warnings rather than three. It makes me wonder if the
compiler is generating code that does access the memory locations intended.

Since we got the strict aliasing optimizations, we probably should learn to
rewrite such old code using a union, or properly accessing the structure
members one by one.  I just tried the union approach: 

union mac_u {
  struct mac_regs regs;
  u8 bytes[sizeof(struct mac_regs)];
};

I changed the function argument to a pointer to this union rather than to a
struct mac_regs, initialized the local pointer variable from the 'bytes' union
member, and the warning went away.  This appears to be the way to properly tell
the compiler how one plans to use the pointer.

Also if the pointer is incremented to point directly at the bytes of interest
rather than being indexed, the warning goes away.


-- 

enrio at online dot no changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |enrio at online dot no


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

[Bug middle-end/37130] warning: array subscript is above array bounds.

[enrio at online dot no]

------- Comment #3 from enrio at online dot no  2009-10-23 07:41 -------
Created an attachment (id=18877)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18877&action=view)
Code that warns, 50 lines, no #include. #ifdef for variations w/o warning


-- 


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

[Bug middle-end/37130] warning: array subscript is above array bounds.

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-08-16 22:54 -------
  __insertion_sort (&entry.node_id[0], &entry.node_id[16]);


The length is only 4.

One issue is that we don't reduce:
  D.8167 = &entry.node_id[0] + (unsigned int) num_side_vert * 4;
  if (&entry.node_id[0] != D.8167)

Into:
 if ((unsigned int)num_side_vert * 4 != 0)

So I think the other issue is that the code for std::sort assumes that it will
be a pointer and an array with a small size.

The warning is only partly bogus but since this is only runtime undefinedness,
this is valid code.  The function get_int better never return more than 4
really.


-- 


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