This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]