Re: [patch] fix wrong gimple code with ptr to forward vla

["Joseph S. Myers" <joseph at codesourcery dot com>]

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
joseph@codesourcery.com