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.
David
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.