This is the mail archive of the
mailing list for the GCC project.
Re: [patch] fix wrong gimple code with ptr to forward vla
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Olivier Hainque <hainque at adacore dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 1 Sep 2006 20:50:30 +0000 (UTC)
- Subject: Re: [patch] fix wrong gimple code with ptr to forward vla
- References: <20060901093351.GA10557@cardhu.act-europe.fr> <44F897CB.firstname.lastname@example.org>
On Fri, 1 Sep 2006, Mark Mitchell wrote:
> I think that this is a more fundamental problem. Since we only have one node
> for a type, the first use of a pointer type may point to a variable-length
> array whose size isn't known at the point the pointer type is used.
> On that basis, I thin Jakub's patch is suspect for PR 21536, and that we
> should not recur on pointer types. Perhaps the middle-end should just ignore
> the bounds for VLAs, and treat them as unknown, at least in some situations.
I think front ends should be responsible for making sure that VLA sizes
get evaluated at the right time and replacing them with temporary
variables, rather than relying on SAVE_EXPRs getting evaluated at a
sensible time. The core gimplifier should then expect all array sizes to
be either constant or a reference to a variable, and all it would do with
them is arrange for stack space to be allocated / deallocated as required;
the front end would have made sure that the internal variable has the
right value at each point.
The right time needs some care to define; for example, in
(a(), (int (*)[b()])c()) + d()
you must call a() before calling b() to work out the type of the comma
expression; while the operands of '+' can be evaluated in either order (or
interleaved), you can't work out how much to multiply d() by for the
pointer addition until after a() and b() have been called.
Joseph S. Myers