[Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets

[Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets

[m.hekkelman at cmbi dot ru.nl]

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

             Bug #: 51731
           Summary: code generation bug in negative indices in arrays on
                    64-bit targets
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: m.hekkelman@cmbi.ru.nl


Created attachment 26217
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26217
source file containing a fully self contained bug description

When compiling the attached code with -O3 the generated code is incorrect as
can be seen by the output of the program. The problem was introduced in gcc
4.5, earlier versions did not have this problem.

[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-01-02 16:23:42 UTC ---
Maybe I'm just tired (sorry in case) but I really don't see how this can
possibly work: *negative* index?!? Can you explain?

[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets

[m.hekkelman at cmbi dot ru.nl]

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

--- Comment #2 from M.L. Hekkelman <m.hekkelman at cmbi dot ru.nl> 2012-01-02 17:03:46 UTC ---
Beste paolo.carlini,

maandag 2 januari 2012, 17:23:42, schreef je:

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

> --- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-01-02 16:23:42 UTC ---
> Maybe I'm just tired (sorry in case) but I really don't see how this can
> possibly work: *negative* index?!? Can you explain?

It  is  a  technique  that  dates back to, who knows when. It is even 
common practice to have a zero sized array in the struct, like this:

struct page
{
       char        keys[1024];
       int         offsets[0];
};

This  way you have a fixed size page you can write to disk containing 
non  terminated strings in keys and the direct offsets to the keys in 
the   offsets  arrays. Fill the page until the keys and offsets would 
collide with the addition of a new key.

E.g. the B-Tree implementation of the HFS file system in MacOS
Classic uses this.

I  have  used  code like this for many years now, and this code works 
with all compilers I'm aware off but not with gcc 4.5 and 4.6.

[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-02 17:10:17 UTC ---
Having a zero-sized array at the end of a struct is surely a commonly used
technique, close to standard flexible array members, but that is not what you
are doing.  Trying to reference data.e[-1] through data.e[-9] is of course not
valid C++ (nor C) when e is an array (it might be valid if e was a pointer and
pointed into the middle of some array).

[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets

[m.hekkelman at cmbi dot ru.nl]

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

--- Comment #4 from M.L. Hekkelman <m.hekkelman at cmbi dot ru.nl> 2012-01-02 19:08:10 UTC ---
Beste jakub,

maandag 2 januari 2012, 18:10:17, schreef je:

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

> Jakub Jelinek <jakub at gcc dot gnu.org> changed:

>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |RESOLVED
>                  CC|                            |jakub at gcc dot gnu.org
>          Resolution|                            |INVALID

> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-02 17:10:17 UTC ---
> Having a zero-sized array at the end of a struct is surely a commonly used
> technique, close to standard flexible array members, but that is not what you
> are doing.  Trying to reference data.e[-1] through data.e[-9] is of course not
> valid C++ (nor C) when e is an array (it might be valid if e was a pointer and
> pointed into the middle of some array).

Following your logic, if I rewrite the code from:

  return data.e[-1];

to

  int* ep = data.e;
  return ep[-1];

It  would  be  valid,  right? And you still believe the bug report is 
invalid?

[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-02 19:32:08 UTC ---
(In reply to comment #4)
> Following your logic, if I rewrite the code from:
> 
>   return data.e[-1];
> 
> to
> 
>   int* ep = data.e;
>   return ep[-1];
> 
> It  would  be  valid,  right? And you still believe the bug report is 
> invalid?

Of course that wouldn't be valid.
I meant that if you had say array
type e[10];
somewhere and
  type *ep = data.e + 9;
you can then access
  ep[0] + ep[-1] + ep[-9]
In C++03, please read [expr.add]/5 :
"If both the pointer operand and the result point to elements of the same array
object, or one past the last element of the array object, the evaluation shall
not produce an overflow; otherwise, the behavior is undefined."

[Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets

[m.hekkelman at cmbi dot ru.nl]

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

--- Comment #6 from M.L. Hekkelman <m.hekkelman at cmbi dot ru.nl> 2012-01-03 07:44:55 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > Following your logic, if I rewrite the code from:
> > 
> >   return data.e[-1];
> > 
> > to
> > 
> >   int* ep = data.e;
> >   return ep[-1];
> > 
> > It  would  be  valid,  right? And you still believe the bug report is 
> > invalid?
> 
> Of course that wouldn't be valid.
> I meant that if you had say array
> type e[10];
> somewhere and
>   type *ep = data.e + 9;
> you can then access
>   ep[0] + ep[-1] + ep[-9]
> In C++03, please read [expr.add]/5 :
> "If both the pointer operand and the result point to elements of the same array
> object, or one past the last element of the array object, the evaluation shall
> not produce an overflow; otherwise, the behavior is undefined."

I stand corrected.

Still, it would be nice if gcc would then issue a warning instead of only
giving incorrect results when -O3 is specified.