http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
Matt Hargett changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #21 from Matt Hargett
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
--- Comment #20 from AJ 2011-03-26 16:56:37 UTC ---
(In reply to comment #19)
ignore my comments. i can't confirm it sufficiently. i might be wrong.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
AJ changed:
What|Removed |Added
CC||aj664 at hotmail dot com
--- Comment #19 from AJ 20
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-07-07 10:08
---
*** Bug 44848 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-07-05 00:11
---
>* Makefile.in (expmed.o-warn): Add -Wno-error.
There is no comment in Makefile.in why this is there, can you add one. Also is
this a false warning from gcc or a true one, I cannot tell.
Note I also get
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-07 12:34
---
Fixed for 4.6.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-04-07 12:31
---
Subject: Bug 43270
Author: rguenth
Date: Wed Apr 7 12:31:32 2010
New Revision: 158058
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158058
Log:
2010-04-07 Richard Guenther
PR tree-optimizatio
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-03-06 14:28
---
Created an attachment (id=20036)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20036&action=view)
untested patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-03-06 14:27
---
Err - it's just because the code is broken:
tree low_bound, up_bound = array_ref_up_bound (ref);
low_sub = up_sub = TREE_OPERAND (ref, 1);
if (!up_bound || TREE_NO_WARNING (ref)
|| TREE_CODE (up_boun
--- Comment #12 from matt at use dot net 2010-03-06 01:31 ---
Changing contents[size] to contents[size + 10] or to contents[size+1] is
still not triggering the array-bounds warning in any of the compilers I tested
(previously mentioned). In my real code, it was an OB1 bug, so that's
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-03-06 00:23
---
Oh we ignore off by one errors in some cases too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
--- Comment #10 from matt at use dot net 2010-03-06 00:19 ---
Created an attachment (id=20033)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20033&action=view)
yet another example, that does not rely on zero-length arrays or on the array
being the 'last' field in the struct/class
--- Comment #9 from matt at use dot net 2010-03-06 00:18 ---
Alright. Even though PC-Lint now correctly warns, and GCC still does not, I
have updated the attached example yet again to avoid the next constraint you
mention.
GCC still does not detect the array-bounds issue, even when the
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-05 23:26 ---
As I mentioned, it is the array at the end of the struct which is where we
don't warn.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from matt at use dot net 2010-03-05 23:25 ---
Created an attachment (id=20032)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20032&action=view)
updated example that doesn't rely on zero-length arrays
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
--- Comment #6 from matt at use dot net 2010-03-05 23:24 ---
I see your point about supporting existing code that uses this feature in the
way you describe.
I modified the example to not rely upon zero-length array and have attached it.
(The bug in the original code didn't use it that w
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-05 22:22 ---
Well:
struct f
{
int t[0];
};
is invalid c/C++ :). But we accept it as an extension. Anyways the thing when
you do:
f *t = ..;
t->t[1] = 1;
We don't warn there on purpose as f::t might used as flexible array. W
--- Comment #4 from matt at use dot net 2010-03-05 22:17 ---
It's not the fact that it's zero-sized in and of itself, but rather the
assignment to contents[0] in the ctor should trigger the warning. Oddly,
PC-Lint warns of the zero-sized array, but not the actual overflow.
As a test, I
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-05 20:34 ---
Well this is semi on purpose. Though we are should reject the zero sized
arrays anyways.
The problem is here we have:
struct f
{
char a[0];
};
Which is common in GNU C/C++ to say f::a is a flexible array member.
--- Comment #2 from matt at use dot net 2010-03-05 20:33 ---
This occurs with both gcc 4.4.1 and 4.5.0.20100304.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
--- Comment #1 from matt at use dot net 2010-03-05 20:22 ---
Created an attachment (id=20031)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20031&action=view)
compilation unit that reproduces the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
21 matches
Mail list logo
