[cfe-dev] VLA changes in the last two weeks?
David Chisnall
csdavec at swansea.ac.uk
Thu Sep 3 06:47:51 PDT 2009
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.
More information about the cfe-dev
mailing list