Sebastian Pop <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| >
| > If VRP is doing what you described in the comment as "its work", then
| > VRP is broken. Period. The fix is to fix VRP. It is such a C
| > idomatic construct than I would not have expected any "optimizer" to
| > break it. And that is very worrisome and scary.
| >
|
| Okay, VRP is not that broken in mainline, but only on a patch that I'm
| working on.
|
| By the way, how is this different than detecting a bound on:
|
| {
| int foo[1335];
|
| for (i = 0; i < some_param; i++)
| foo[i];
| }
|
| vs.
|
| {
| some_struct{ int foo[1335];} s;
|
| for (i = 0; i < some_param; i++)
| s.foo[i];
| }
There is a difference between what invariants you can derive by
looking at the declaration of an *object* -- like the automatic
objects in your example -- and invariants you can derive by looking
only at a structure definition in isolation. In particular, a
structure can be used to define both an automatic object (for which
usually much stronger properties can be derived) and object from free
store -- which are not "declared object", consequently you have much
more "tricks" going on there:
typedef struct {
int data[1];
} foo;
foo* p = (foo *) malloc (sizeof (foo) + N * sizeof (int));
// there are enough room for N ints, and the store is properly
// aligned.
for (int i = 0; i < N; ++i)
p->data[i] = frobnicate (N, i);
The majority of C programs (I know of) that implement arrays use
similar trick.
-- Gaby
