This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Undefined behavior in genautomata.c?
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Richard Henderson'" <rth at redhat dot com>,"'Sebastian Pop'" <sebastian dot pop at cri dot ensmp dot fr>
- Cc: "'Gabriel Dos Reis'" <gdr at integrable-solutions dot net>,<gcc at gcc dot gnu dot org>,"'Vladimir Makarov'" <vmakarov at redhat dot com>
- Date: Mon, 19 Sep 2005 11:33:51 +0100
- Subject: RE: Undefined behavior in genautomata.c?
----Original Message----
>From: Richard Henderson
>Sent: 19 September 2005 11:26
> On Mon, Sep 19, 2005 at 12:07:45PM +0200, Sebastian Pop wrote:
>> By the way, how is this different than detecting a bound on: ...
>> int foo[1335];
> ...
>> some_struct{ int foo[1335];} s;
>
> Because here the variables are *known* to have a specific size.
>
> Similarly with static and global variables, though you must be
> careful for
>
> struct S { struct B b; int x[]; };
> struct T { struct S s; int x2[10]; } t;
>
> where (&t.s) is used as an S in places that expect it, with 10
> data elements allocated for the flexible array member.
>
> In the case of the (fake) flexible array member, you do not know
> how large the object allocated from malloc was unless you can
> track down the actual malloc call.
Do you suppose the idiom is common enough that VRP could special-case
"arrays of size 1 at the end of a struct" ? And still obtain the benefits
of the optimisation in 99.99% of all non-variable-length-tail-array cases?
cheers,
DaveK
--
Can't think of a witty .sigline today....