<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/110956>110956</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [SPARC] Asan test failure in TestCases/alloca_vla_interact.cpp
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            backend:Sparc,
            compiler-rt:asan
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            koachan
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          koachan
      </td>
    </tr>
</table>

<pre>
    Consolidating all the relevant stuff from the discussion at PR https://github.com/llvm/llvm-project/pull/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](https://github.com/llvm/llvm-project/pull/107223#issuecomment-2368018375), the test case fails on GCC too, on 32-bit SPARC. 

This is what the test does, [according to @chefmax7](https://github.com/llvm/llvm-project/pull/107223#issuecomment-2387494444):
> 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...
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy0Vt2O2zYTfRr6ZrCCTPlnfeELx_s5MZCvWGSD3AYUObLYpTgqSdl1n74Yymtvky2aoOjC0MoyNWfOmTNDqhjtwSOuxfydkPKZlG6VF1KK-cNEDamlsL48nNRkzust-UjOGpWsP4ByDlKLENDhUfkEMQ1NA02gLj83NuohRkseVILHT9Cm1EdRbYTcCbk72NQOdaGpE3Ln3PHl310f6FfUSchdPzgn5G5aLqWsoKEAqKLFACko_Wz9oRDlgyg3mybxw3aEsRFU3zuLRsgtZxJQyGUE8ggqKg8JYxpXx2Sdg0ZZl_PKwS7XRXn5jAjGBIzxSXmb7B8Y7mKvgr6Lg6cI_Gq1gc8Y01ZFjELulHOk1dejU1-tTxiUToXu-38OdmfOXnVW_3TQS-gYMSSWnEmh4RC_gageRPUAiXpWpLEOQcjdkdxN-Rj09_ozHK_R1PXWYbgL_JTl42wie2X3IwnKLTjrEWbzN8W9XOfvHjGAmJWBQmrF_EHI-39nGSErG-OAmroOfbqT1eK-nN5Xy7mQq4s5RjdoFXH0AZCH99stJCJeQR4qeVfbBE-Pm0_bAl6n_Lm1ke12Yi9dYxliMbYg5u-U1hQMN0siZqZbbDr1-_K_IXe_nK1ms9mMyV3dXP0PPlhOJ1II59xEnKlTiTs39uQj8s97ZvwMkTqEZDvMK_meeFmigNCd4f0HYE6DT0VR3BBud3sw5IVcJgjYYVdjuM4Jgyk3mtxCPaRxTmTl9te1_NupRQ-26x0yLdbuy8fN1VzQk43krT_w2o8fv_wfYksnNGBs02BAn6DGVh0thUxhfC23RHSUInTKq0OODTWmE6JngJt9I1ifCBxRD56t_lrK2x3_CbnJGEJuhNzkNMcPyxnVCWyKEJPSzxkbamQ6AYeI5gqegSx3CycZQch7W2ABqHQ7Ul_GCws4qQh9QI2GA5yBW2hWskuKDBPVEYu-FPKePbAos_bKG2jIuaxSfQZNYSx8Nua3IS7FHqNwkXOgN2v9vQRjmuP9RYJcopci8K4BHk-vRSE_Uv2rDiyDp1ErIVdv4t_unuibVj7lMhr0CQ1bWLeon8eZv3na_AJaeWiVNw5fG2o3-Ou3USad3BmsZ9Ejeo1ADdSU2jctE1WHN9-8mfIHOuFx9Lkj4i2M-TcBY-vOcEDP9NGMqu0_8TqbICJ2ERJPmxeXa-TB42mcO5mz8ueOQm7mTp1r5DdZBwX1cGASOWitshDoi6KAz3kTVNZcJkBr_fOIc5OSx9nY0a06IhyVG65YXCW21wte9ioeuYH9UTlrwNPp78q3F3LZXcZSGueAViNSH-hoDULGSKhbb7VyLxNkDLodE-1V0i1r0QdM6QzkzG005esjhkheOXeGPTSIDsiYEfFqmrdGPw-pPZzIGwxgm1cnCR6SrNVhjMJmqlkoj8BriqKYmHVlVtVKTXA9XcrlqppNV-WkXZsFVvNZ1TRK67KqFrqs9WI2n8lyucL75Xxi17KUs2lZVuV8Vk3LYqGmi2lTytWqmZuy4W7FTllX5J6lcJjkbWA9nZar-WLiVI0uXo50XGz0fAp44iMGH-3kVkj5ekOvNuNOnk99YZ23nHo4RJ4KNqZ4w0k2uXxYzFuhmD_A5nqcYgGHgGyzHzgRTIbg1j-9_WWeHPVC9biWfwYAAP__9Ht9SQ">