[cfe-dev] VLA changes in the last two weeks?

[David Chisnall]

On 3 Sep 2009, at 12:53, David Chisnall wrote:

> Hi,
>
> Has anyone done anything that might have broken VLAs in the last two
> weeks?  I have some code that was compiling and working with trunk on
> the 15th of August, but isn't today (unfortunately I can't be more
> specific; I haven't recompiled that file between then and now).
> Stepping through in gdb, the VLA address is the same as the address of
> the first argument.  Unfortunately, this is happening in a 600 line
> function and finding a reduced test case is proving problematic.

If I replace the VLA in question with an alloca(), the code works  
correctly.  It's difficult to tell why this is the case -  diff on IR  
produces a lot of false-positives due to the renaming - but it seems  
that the only significant difference between the version created as an  
alloca() and the version created as a VLA is that the alloca() version  
has a pointer allocated on the stack in the first BB and all  
subsequent accesses go via this, while the VLA version is used directly.

I'm not sure if it's relevant, but the line following the VLA that  
fails is also a VLA with the same name as a variable in the enclosing  
scope,[1] and that one appears to be allocated correctly, although gdb  
seems to be getting the size / type information from the version in  
the enclosing scope.

I wondered if the problem might be due to stacksave / stackrestore,  
but it seems that even commenting these two out (which, as I  
understand it, will make the stack grow potentially very big, but  
won't actually break things unless the stack overflows) in CGDecl.cpp  
makes no difference.

Suggestions for where to look next are most welcome...

David

[1] Which neither GCC nor clang seem to warn about.