[Bug c/8268] no compile time array index checking
--- Comment #45 from mueller at gcc dot gnu dot org 2007-01-30 17:17 --- Subject: Bug 8268 Author: mueller Date: Tue Jan 30 17:17:39 2007 New Revision: 121346 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121346 Log: backport from mainline: 2007-01-21 Dirk Mueller [EMAIL PROTECTED] PR bootstrap/30511 * tree-vrp.c (check_array_bounds): do not warn about ADDR_EXPR's of ARRAY_REF's which are immediately used in binary expressions. 2007-01-19 Dirk Mueller [EMAIL PROTECTED] * config/i386.h (CONDITIONAL_REGISTER_USAGE): Store result of PIC_OFFSET_TABLE_REGNUM in temporary variable to avoid duplicate evaluation. 2007-01-18 Dirk Mueller [EMAIL PROTECTED] Richard Guenther [EMAIL PROTECTED] PR diagnostic/8268 * doc/invoke.texi (Warray-bounds): Document -Warray-bounds. * common.opt (Warray-bounds): Add new warning option. * c-opts.c (c_common_handle_option): Define -Warray-bounds if -Wall is given. * Makefile.in: make tree-vrp.o depend on toplev.h * tree-vrp.c (vrp_finalize): Call check_array_refs if * -Warray-bounds is enabled. (check_array_refs, check_array_bounds, check_array_ref): New. Added: branches/suse/gcc-4_2-branch/gcc/testsuite/g++.dg/warn/Warray-bounds-2.C - copied unchanged from r120898, trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-2.C branches/suse/gcc-4_2-branch/gcc/testsuite/g++.dg/warn/Warray-bounds.C - copied unchanged from r120898, trunk/gcc/testsuite/g++.dg/warn/Warray-bounds.C branches/suse/gcc-4_2-branch/gcc/testsuite/gcc.dg/Warray-bounds-2.c - copied unchanged from r120898, trunk/gcc/testsuite/gcc.dg/Warray-bounds-2.c branches/suse/gcc-4_2-branch/gcc/testsuite/gcc.dg/Warray-bounds.c - copied unchanged from r120898, trunk/gcc/testsuite/gcc.dg/Warray-bounds.c Modified: branches/suse/gcc-4_2-branch/gcc/Makefile.in branches/suse/gcc-4_2-branch/gcc/c-opts.c branches/suse/gcc-4_2-branch/gcc/common.opt branches/suse/gcc-4_2-branch/gcc/config/i386/i386.h branches/suse/gcc-4_2-branch/gcc/doc/invoke.texi branches/suse/gcc-4_2-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #43 from mueller at gcc dot gnu dot org 2007-01-18 13:00 --- Subject: Bug 8268 Author: mueller Date: Thu Jan 18 13:00:33 2007 New Revision: 120898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120898 Log: 2007-01-18 Dirk Mueller [EMAIL PROTECTED] · Richard Guenther [EMAIL PROTECTED] · PR diagnostic/8268 · * doc/invoke.texi (Warray-bounds): Document -Warray-bounds. · * common.opt (Warray-bounds): Add new warning option. · * c-opts.c (c_common_handle_option): Define -Warray-bounds · if -Wall is given. * Makefile.in: make tree-vrp.o depend on toplev.h · * tree-vrp.c (vrp_finalize): Call check_array_refs if -Warray-bounds · is enabled. · (check_array_refs, check_array_bounds, check_array_ref): New. · * gcc.dg/Warray-bounds.c: New testcase. * gcc.dg/Warray-bounds-2.c: New testcase. * g++.dg/warn/Warray-bounds.C: New testcase. * g++.dg/warn/Warray-bounds-2.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-2.C trunk/gcc/testsuite/g++.dg/warn/Warray-bounds.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-2.c trunk/gcc/testsuite/gcc.dg/Warray-bounds.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/c-opts.c trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #44 from mueller at gcc dot gnu dot org 2007-01-18 13:12 --- Fixed for 4.3. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #42 from mueller at gcc dot gnu dot org 2007-01-17 10:51 --- no, its going in real soon now (finally) :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #41 from dcb314 at hotmail dot com 2007-01-16 21:18 --- (In reply to comment #40) I've a patch, which is currently blocked by -fivopts bug Still blocked ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #39 from falk at debian dot org 2006-06-08 15:02 --- I'm not actually working on this at the moment -- falk at debian dot org changed: What|Removed |Added AssignedTo|falk at debian dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #40 from mueller at gcc dot gnu dot org 2006-06-08 15:50 --- I've a patch, which is currently blocked by -fivopts bug -- mueller at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #38 from mueller at gcc dot gnu dot org 2006-02-25 18:37 --- I think the anaylize_array_indexes has the problem of the taking address of array sentinel as well. I'll look into moving it to VRP pass. re segfault: I got the same, will fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #37 from dcb314 at hotmail dot com 2006-02-24 17:38 --- (In reply to comment #33) Created an attachment (id=10902) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10902action=view) [edit] updated patch. better patch. I'm going to post that one when regtesting completes. I tried your patch on gcc 4.2 current snapshot and I had to bodge it a bit to get it to compile. After that, it segfaulted during bootstrapping ;- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #32 from mueller at gcc dot gnu dot org 2006-02-23 09:59 --- Created an attachment (id=10899) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10899action=view) reworked patch Ok, based on Falk's patch, I've hammered on it long enough until there were no more false positives. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Attachment #10869|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #33 from mueller at gcc dot gnu dot org 2006-02-23 15:47 --- Created an attachment (id=10902) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10902action=view) updated patch. better patch. I'm going to post that one when regtesting completes. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Attachment #10899|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #34 from falk at debian dot org 2006-02-23 16:16 --- (In reply to comment #33) Created an attachment (id=10902) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10902action=view) [edit] updated patch. better patch. I'm going to post that one when regtesting completes. BTW, have you considered Sebastian's suggestion to put this into tree-data-ref.c/analyze_array_indexes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #35 from rguenth at gcc dot gnu dot org 2006-02-23 16:18 --- I suggested to put it in VRP so one can do analysis for non-constant indices. Possibly by splitting the warning like strict aliasing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #36 from law at redhat dot com 2006-02-23 16:31 --- Subject: Re: no compile time array index checking On Thu, 2006-02-23 at 16:18 +, rguenth at gcc dot gnu dot org wrote: --- Comment #35 from rguenth at gcc dot gnu dot org 2006-02-23 16:18 --- I suggested to put it in VRP so one can do analysis for non-constant indices. Possibly by splitting the warning like strict aliasing. Using the VRP information for array bound checking purposes has always been something we wanted to do. Though we always thought the first use would be for eliminating bounds checks rather than for warning purposes :-) This will bring to the forefront the need to either make VRP data persistent or at least mark array references VRP determines are safe, unsafe or unsure so that a later pass can issue the appropriate warnings (possibly after further analysis). Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #31 from mueller at gcc dot gnu dot org 2006-02-19 21:42
---
I see many false positives and negatives with the -Warray-bounds patch. I
haven't closely investigated the false positives yet, but one of the false
negatives is this:
=== Cut ===
struct bla {
bla();
int* foo[3];
};
bla::bla()
{
foo[3] = 0;
}
=== Cut ===
this one is caught by my patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #19 from dcb314 at hotmail dot com 2006-02-18 12:09 --- (In reply to comment #17) Created an attachment (id=10869) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10869action=view) [edit] patch I'm currently testing this patch. I tried out the suggested patch on gcc version 4.2, snapshot 20060211, and tried to build the compiler. It said ../../src/gcc-4.2-20060211/libiberty/cp-demangle.c: In function 'd_demangle': ../../src/gcc-4.2-20060211/libiberty/cp-demangle.c:3899: internal compiler error: tree check: expected catch_expr, have try_finally in array_offset_warning, at c-common.c:5893 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The source code line causing problems is array_offset_warning (CATCH_BODY (t)); Also, there seems to be some dead code after the break statement: + case EH_FILTER_EXPR: + array_offset_warning (EH_FILTER_FAILURE (t)); + break; + array_offset_warning (TREE_OPERAND (t, 0)); + array_offset_warning (TREE_OPERAND (t, 1)); Possibly a missing case ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-02-18 12:28
---
Also make sure not to trip on
typedef struct {
int len;
char str[4];
} String;
char foo(String *s)
{
return s-str[42];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #21 from mueller at gcc dot gnu dot org 2006-02-18 12:39 --- hmm, thanks. it should have looked like this: + case TRY_FINALLY_EXPR: + case TRY_CATCH_EXPR: +array_offset_warning (TREE_OPERAND (t, 0)); +array_offset_warning (TREE_OPERAND (t, 1)); +break; + case CATCH_EXPR: + array_offset_warning (CATCH_BODY (t)); + break; Anyway, I agree that the SSA pass after all const folding has happened is a much better approach than my quick hack, as long as it isn't significantly slower (compile time). I'm currently trying Falk's patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #22 from mueller at gcc dot gnu dot org 2006-02-18 12:42
---
Richard: Under which assumption? because the array size is = sizeof(int) ?
Why not suppressing the warning by changing the code to:
typedef struct {
int len;
char str[0];
} String;
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #23 from falk at debian dot org 2006-02-18 12:58 ---
(In reply to comment #21)
hmm, thanks. it should have looked like this:
+ case TRY_FINALLY_EXPR:
+ case TRY_CATCH_EXPR:
+array_offset_warning (TREE_OPERAND (t, 0));
+array_offset_warning (TREE_OPERAND (t, 1));
+break;
+ case CATCH_EXPR:
+ array_offset_warning (CATCH_BODY (t));
+ break;
Anyway, I agree that the SSA pass after all const folding has happened is a
much better approach than my quick hack, as long as it isn't significantly
slower (compile time). I'm currently trying Falk's patch.
The problem it had was with inlining: code like
static inline int f(int a[], int b) {
return a[b]; // line 2
}
int g(void) {
int a[2] = {1, 2};
return f(a, 2); // line 7
}
To really be helpful, the warning should say something like array access
out of bound in line 2 after inlining in line 7, but I don't know how
to achieve that. The uninitialized warning has the same problem by running
so late; it punts and just says a used uninitialized in g, which seems
kinda lame.
Anyway, the warning is probably still useful if this is not resolved...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #24 from rguenth at gcc dot gnu dot org 2006-02-18 13:15 --- (In reply to comment #22) We need to allow offsetting beyond the declared array size if this array is the last member of a structure. This is refered to as malloc trick to allocate variable sized structures with a flexible array member. Due to compilers lacking support for the correct char str[] declaration you will find all of char str[0] (GNU extension) char str[] char str[1] char str[4] (or whatever number) so in this case we need to allow all accesses, or with a separate warning flag only warn if the decl was not one of [0], [] or [1]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #25 from falk at debian dot org 2006-02-18 13:25 --- (In reply to comment #24) We need to allow offsetting beyond the declared array size if this array is the last member of a structure. This is refered to as malloc trick to allocate variable sized structures with a flexible array member. Due to compilers lacking support for the correct char str[] declaration you will find all of char str[0] (GNU extension) char str[] char str[1] char str[4] (or whatever number) so in this case we need to allow all accesses, or with a separate warning flag only warn if the decl was not one of [0], [] or [1]. I tried to handle this by never warning for any size-0 or size-1 array. Is there some way to check that this array is in fact the last member of a struct? That would clearly be better. I'd still consider warning for sizes 1, because it's probably rare enough to not justify the false negatives we get otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-02-18 13:44 --- I agree that the false positives would be acceptable. One could even warn for [0] and [1] arrays if std=c99 (I believe flexible array members were not in c89, but i didn't check). For a way to check if an array access can possibly cross structure extent you can look at tree-dfa.c:get_ref_base_and_extent which also accounts for flexible array members. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #27 from dcb314 at hotmail dot com 2006-02-18 14:33 --- (In reply to comment #21) hmm, thanks. it should have looked like this: I tried your second patch, and the compile of the compiler got as far as the following /home/dcb/gnu/42-20060211/working/./prev-gcc/xgcc -B/home/dcb/gnu/42-20060211/working/./prev-gcc/ -B/home/dcb/gnu/42-20060211/results/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src/gcc-4.2-20060211/gcc -I../../src/gcc-4.2-20060211/gcc/. -I../../src/gcc-4.2-20060211/gcc/../include -I../../src/gcc-4.2-20060211/gcc/../libcpp/include -I../../src/gcc-4.2-20060211/gcc/../libdecnumber -I../libdecnumber ../../src/gcc-4.2-20060211/gcc/real.c -o real.o../../src/gcc-4.2-20060211/gcc/real.c: In function 'real_to_integer2': ../../src/gcc-4.2-20060211/gcc/real.c:1385: error: array reference -1 below range min (0) ../../src/gcc-4.2-20060211/gcc/real.c: In function 'real_from_integer': ../../src/gcc-4.2-20060211/gcc/real.c:2050: error: array reference -1 below range min (0) ../../src/gcc-4.2-20060211/gcc/real.c: In function 'encode_ieee_quad': ../../src/gcc-4.2-20060211/gcc/real.c:3564: error: array reference 3 above range max (2) ../../src/gcc-4.2-20060211/gcc/real.c:3615: error: array reference 3 above range max (2) ../../src/gcc-4.2-20060211/gcc/real.c: In function 'decode_ieee_quad': ../../src/gcc-4.2-20060211/gcc/real.c:3693: error: array reference 3 above range max (2) ../../src/gcc-4.2-20060211/gcc/real.c:3719: error: array reference 3 above range max (2) ../../src/gcc-4.2-20060211/gcc/real.c:3745: error: array reference 3 above range max (2) It seems that a combination of the new warning and the Werror flag prevents compilation. On the other point about using arrayName[ 4] for the end of struct hack, I'd be entirely happy with false positives. Folks who want that hack can just say arrayName[ 1] to avoid the new warning anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #28 from giovannibajo at libero dot it 2006-02-18 14:48 --- Jakub, you have provided some infrastructure to compute object size and provide warnings for unsafe use of builtins. Do you believe that infrastructure could be reused/enhanced for this bug? -- giovannibajo at libero dot it changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #29 from jakub at gcc dot gnu dot org 2006-02-18 15:24 --- Yes, fairly easily. Just add another pass, probably into tree-object-size.c, where you: init_object_sizes (); and for each ARRAY_REF compute objsz = compute_builtin_object_size (TREE_OPERAND (array_ref, 0), 0) and if (objsz != (unsigned HOST_WIDE_INT) -1 compare_tree_int (TREE_OPERAND (array_ref, 1), objsz)) = 0) warning (...); When done with the pass, call fini_object_sizes ();. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
Re: [Bug c/8268] no compile time array index checking
rguenth at gcc dot gnu dot org wrote:-
Also make sure not to trip on
typedef struct {
int len;
char str[4];
} String;
char foo(String *s)
{
return s-str[42];
}
That definitely deserves a warning.
Neil.
[Bug c/8268] no compile time array index checking
--- Comment #30 from neil at daikokuya dot co dot uk 2006-02-19 00:52
---
Subject: Re: no compile time array index checking
rguenth at gcc dot gnu dot org wrote:-
Also make sure not to trip on
typedef struct {
int len;
char str[4];
} String;
char foo(String *s)
{
return s-str[42];
}
That definitely deserves a warning.
Neil.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #17 from mueller at gcc dot gnu dot org 2006-02-18 02:51 --- Created an attachment (id=10869) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10869action=view) patch I'm currently testing this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #18 from falk at debian dot org 2006-02-18 07:19 --- Created an attachment (id=10870) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10870action=view) alternative patch Hi, I've also been working on a patch, although as an SSA pass. It probably catches more, but there were some weird interactions with inlining yielding messages in unexpected places. I'll attach my (preliminary) patch, which also contains a test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-08 02:41 --- *** Bug 24728 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Larry dot Finger at lwfinger ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr 2005-08-22 12:38 --- (In reply to comment #14) (In reply to comment #9) If we really wanted to tackle this better a compile-time, we'd run a pass to look at all the ARRAY_REFs for those which have an out-of-range index. It wouldn't be terribly hard to stick one in just before we leave SSA form. I'll give this a try. Have a look at tree-data-ref.c:analyze_array_indexes The warning can be implemented in this function. seb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From falk at debian dot org 2005-08-21 00:05 --- (In reply to comment #9) If we really wanted to tackle this better a compile-time, we'd run a pass to look at all the ARRAY_REFs for those which have an out-of-range index. It wouldn't be terribly hard to stick one in just before we leave SSA form. I'll give this a try. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |falk at debian dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-18 14:02 --- *** Bug 22546 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From bangerth at ices dot utexas dot edu 2005-06-21 14:02 --- Subject: Re: no compile time array index checking Doesn't -fmudflap handle this? The idea was to get a compile-time error whenever possible. W. - Wolfgang Bangerth email:[EMAIL PROTECTED] www: http://www.ices.utexas.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21 14:05 --- (In reply to comment #10) The idea was to get a compile-time error whenever possible. It has to be a diagnostic/warning as this is just undefined and undefined code still has to compile as one of the DR says. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From trt at acm dot org 2005-06-21 15:55 --- Since there is mudflap, it is especially important to avoid false positives. One type occurs in code that never actually executes, e.g. conditional lookup: #define LOOKUP(i) (i XSIZE ? x[i]: 0) To defend against that, issue the warning only if skip_evaluation is zero. (For a more general fix, see http://gcc.gnu.org/ml/gcc/2004-10/msg00859.html) Another is taking the address one past the last element, e.g. int a[10]; int *aend = a[10]; // this is perfectly valid, and common -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From dcb314 at hotmail dot com 2005-06-20 08:10
---
I fiddled with the supplied patch, and got this
--- expr.c.sav 2005-06-18 14:45:34.0 +0100
+++ expr.c 2005-06-19 11:19:02.0 +0100
@@ -5537,6 +5537,20 @@
tree low_bound = (domain ? TYPE_MIN_VALUE (domain) : 0);
tree unit_size = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (array)));
+ if ((domain != 0) (TREE_CODE (index) == INTEGER_CST))
+ {
+if ((TREE_CODE (low_bound) == INTEGER_CST
+tree_int_cst_lt(index, low_bound))
+ || ((TYPE_MAX_VALUE (domain) != 0)
+(TREE_CODE (TYPE_MAX_VALUE (domain)) == INTEGER_CST)
+tree_int_cst_lt (TYPE_MAX_VALUE (domain), index)
+ /* Accesses after the end of arrays of size 0 (gcc
+ extension) and 1 are likely intentional. */
+!tree_int_cst_lt (TYPE_MAX_VALUE (domain),
+ build_int_2 (2, 0
+warning (array subscript out of range);
+ }
+
/* We assume all arrays have sizes that are a multiple of a byte.
First subtract the lower bound, if any, in the type of the
index, then convert to sizetype and multiply by the size of the
I tried it out on the gcc34, and it seemed to work fine, finding eight
bugs in the Linux kernel.
I don't know how to progress this patch to get it into the official sources for
the gcc34 series. Advice sought.
I tried out the patch on gcc400, and it didn't work. More work needed there.
--
What|Removed |Added
CC||dcb314 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From falk at debian dot org 2005-06-20 09:36 --- (In reply to comment #5) I fiddled with the supplied patch, and got this --- expr.c.sav2005-06-18 14:45:34.0 +0100 +++ expr.c2005-06-19 11:19:02.0 +0100 @@ -5537,6 +5537,20 @@ [...] I tried it out on the gcc34, and it seemed to work fine, finding eight bugs in the Linux kernel. I think popular opinion has changed now in that expr.c is not the right place for a warning after all, so it should rather be done in the frontend in c-typeck.c as originally proposed. Jeff, do you agree? (original thread: http://gcc.gnu.org/ml/gcc/2000-07/msg01000.html) -- What|Removed |Added CC||law at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From law at redhat dot com 2005-06-20 21:22 --- Subject: Re: no compile time array index checking On Mon, 2005-06-20 at 09:36 +, falk at debian dot org wrote: --- Additional Comments From falk at debian dot org 2005-06-20 09:36 --- (In reply to comment #5) I fiddled with the supplied patch, and got this --- expr.c.sav 2005-06-18 14:45:34.0 +0100 +++ expr.c 2005-06-19 11:19:02.0 +0100 @@ -5537,6 +5537,20 @@ [...] I tried it out on the gcc34, and it seemed to work fine, finding eight bugs in the Linux kernel. I think popular opinion has changed now in that expr.c is not the right place for a warning after all, so it should rather be done in the frontend in c-typeck.c as originally proposed. Jeff, do you agree? (original thread: http://gcc.gnu.org/ml/gcc/2000-07/msg01000.html) I would not agree at all. Bounds checking of this sort does not belong in the front-end. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From giovannibajo at libero dot it 2005-06-21 00:10 --- Doesn't -fmudflap handle this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Additional Comments From law at redhat dot com 2005-06-21 01:20 --- Subject: Re: no compile time array index checking On Tue, 2005-06-21 at 00:10 +, giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2005-06-21 00:10 --- Doesn't -fmudflap handle this? I would expect mudflap to issue a runtime warning. If we really wanted to tackle this better a compile-time, we'd run a pass to look at all the ARRAY_REFs for those which have an out-of-range index. It wouldn't be terribly hard to stick one in just before we leave SSA form. Doing it that way has a number of useful advantages -- we'll see a lot more ARRAY_REFs rather than pointer arithmetic (due to constant address propagation as well as ADDR_EXPR propagation). We'll also see more constant indices due to const propagation done by CCP, VRP and DOM. And (of course) it would just work for all the languages currently supported by GCC. I believe Jakub has done some work in this area that might be useful as a starting point. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
