public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/51731] New: code generation bug in negative indices in arrays on 64-bit targets
@ 2012-01-02 12:26 m.hekkelman at cmbi dot ru.nl
2012-01-02 16:24 ` [Bug c++/51731] " paolo.carlini at oracle dot com
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: m.hekkelman at cmbi dot ru.nl @ 2012-01-02 12:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ 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 ` 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
end of thread, other threads:[~2012-01-03 7:45 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2012-01-02 19:32 ` jakub at gcc dot gnu.org
2012-01-03 7:45 ` m.hekkelman at cmbi dot ru.nl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).