--- 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=gcc&view=rev&rev=121346
Log:
backport from mainline:
2007-01-21 Dirk Mueller <[EMAIL
--- 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
Statu
--- 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=gcc&view=rev&rev=120898
Log:
2007-01-18 Dirk Mueller <[EMAIL PROTECTED]>
· R
--- 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
--- 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
--- 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
--
--- 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
--- 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/bug
--- 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=10902&action=view) [edit]
> updated patch.
>
> better patch. I'm going to post that one when regtesting co
--- 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 sugge
--- 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
--- 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=10902&action=view) [edit]
> updated patch.
>
> better patch. I'm going to post that one when regtesting compl
--- 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=10902&action=view)
updated patch.
better patch. I'm going to post that one when regtesting completes.
--
mueller at gcc dot
--- 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=10899&action=view)
reworked patch
Ok, based on Falk's patch, I've hammered on it long enough until there were no
more false posi
--- 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* f
--- 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)
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.
--- 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
--- 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 li
--- 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
--- 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 a
--- 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
--- 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 wit
--- 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_warn
--- 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
--- 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));
+
--- 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
--- 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=10869&action=view) [edit]
> patch
>
> I'm currently testing this patch.
I tried out the suggested patch o
--- 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=10870&action=view)
alternative patch
Hi,
I've also been working on a patch, although as an SSA pass. It probably catches
more, but there
--- 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=10869&action=view)
patch
I'm currently testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
--- 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
-
--- 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-
--- 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 st
--- 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
--- 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 th
--- 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
--- 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.
---
--- 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 ---
--- 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
--- 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 t
--- 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 @@
--- 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 ?
42 matches
Mail list logo
