* [Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
2012-01-02 12:26 [Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets m.hekkelman at cmbi dot ru.nl
@ 2012-01-02 16:24 ` paolo.carlini at oracle dot com
2012-01-02 17:04 ` m.hekkelman at cmbi dot ru.nl
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: paolo.carlini at oracle dot com @ 2012-01-02 16:24 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
2012-01-02 12:26 [Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets m.hekkelman at cmbi dot ru.nl
2012-01-02 16:24 ` [Bug c++/51731] " paolo.carlini at oracle dot com
@ 2012-01-02 17:04 ` m.hekkelman at cmbi dot ru.nl
2012-01-02 17:10 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: m.hekkelman at cmbi dot ru.nl @ 2012-01-02 17:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
2012-01-02 12:26 [Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets m.hekkelman at cmbi dot ru.nl
2012-01-02 16:24 ` [Bug c++/51731] " paolo.carlini at oracle dot com
2012-01-02 17:04 ` m.hekkelman at cmbi dot ru.nl
@ 2012-01-02 17:10 ` jakub at gcc dot gnu.org
2012-01-02 19:08 ` m.hekkelman at cmbi dot ru.nl
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-01-02 17:10 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
2012-01-02 12:26 [Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets m.hekkelman at cmbi dot ru.nl
` (2 preceding siblings ...)
2012-01-02 17:10 ` jakub at gcc dot gnu.org
@ 2012-01-02 19:08 ` m.hekkelman at cmbi dot ru.nl
2012-01-02 19:32 ` jakub at gcc dot gnu.org
2012-01-03 7:45 ` m.hekkelman at cmbi dot ru.nl
5 siblings, 0 replies; 7+ messages in thread
From: m.hekkelman at cmbi dot ru.nl @ 2012-01-02 19:08 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
2012-01-02 12:26 [Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets m.hekkelman at cmbi dot ru.nl
` (3 preceding siblings ...)
2012-01-02 19:08 ` m.hekkelman at cmbi dot ru.nl
@ 2012-01-02 19:32 ` jakub at gcc dot gnu.org
2012-01-03 7:45 ` m.hekkelman at cmbi dot ru.nl
5 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-01-02 19:32 UTC (permalink / raw)
To: gcc-bugs
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."
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/51731] code generation bug in negative indices in arrays on 64-bit targets
2012-01-02 12:26 [Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets m.hekkelman at cmbi dot ru.nl
` (4 preceding siblings ...)
2012-01-02 19:32 ` jakub at gcc dot gnu.org
@ 2012-01-03 7:45 ` m.hekkelman at cmbi dot ru.nl
5 siblings, 0 replies; 7+ messages in thread
From: m.hekkelman at cmbi dot ru.nl @ 2012-01-03 7:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread