Description
Consolidating all the relevant stuff from the discussion at PR #107223 for easier tracking.
After that PR is applied, there's one asan test that still fails:
AddressSanitizer-sparc-sunos :: TestCases/alloca_vla_interact.cpp
AddressSanitizer-sparc-sunos-dynamic :: TestCases/alloca_vla_interact.cpp
Assertion failed: q == top, file /vol/llvm/src/llvm-project/local/compiler-rt/test/asan/TestCases/alloca_vla_interact.cpp, line 45
Per @rorth, the test case fails on GCC too, on 32-bit SPARC.
This is what the test does, according to @chefmax7:
Hi, sorry for the late response, I took some time for me to restore my GH account...
I don't remember all the details, but from what I remember, when implementing VLA/alloca poisoning, LLVM showed different behavior for allocation slots management between VLAs/allocas into loop nest:
* for **VLA**, I saw its stack slot being reused between loop iterations (i.e. each VLA's alloca was preceded by `@llvm.stacksave.p0()` all and followed by corresponding `@llvm.stackrestore.p0(...)`. * for **alloca** I saw LLVM allocating a new stack slot on each loop iteration (no reuse).So the test case was indented to check that ASAN can handle poisoning/unpoisoning correctly in presence of both VLAs/allocas into same loop nest.
However, looking on freshly generated LLVM IR, it seems this difference is not the case anymore, maybe it was a bug in LLVM back then... That said, I think this test case doesn't have value anymore (and maybe it's even invalid now).
I'm sorry that I can't provide more technical details now, this patch is pretty old...
Personally I feel odd that the test fails on GCC too, but I wonder if there's something that can be done here...