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

    <tr>
        <th>Summary</th>
        <td>
            asan heap-use-after-free for GlobalISel/arm64-atomic.ll with --compile-twice
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

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

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

<pre>
    AddressSanitizer reports heap-use-after-free for the standard test CodeGen/AArch64/GlobalISel/arm64-atomic.ll (among others) when run with --compile-twice:
```
../target-llvm/build-final/bin/llc  --compile-twice  llvm/test/CodeGen/AArch64/GlobalISel/arm64-atomic.ll
=================================================================
==56174==ERROR: AddressSanitizer: heap-use-after-free on address 0x0001278116f0 at pc 0x000104c66cc0 bp 0x00016b1a5910 sp 0x00016b1a5908
READ of size 8 at 0x0001278116f0 thread T0
    #0 0x104c66cbc in llvm::raw_ostream::flush() raw_ostream.h:188
…
    #21 0x109df9094 in llvm::PMDataManager::~PMDataManager()+0xb8 (llc:arm64+0x1051a1094)
…
    #28 0x109e0276c in (anonymous namespace)::MPPassManager::~MPPassManager()+0x8 (llc:arm64+0x1051aa76c)
…
```
I’ll attach the full output and version.  A similar issue was originally found in a Lit test on an asan build of our fork, which we run over our own code with --compile-twice and a dozen other extra verification options. It reproduced on the upstream version with the following Lit invocation:

`
../target-llvm/build-final/bin/llvm-lit -avv "-Dllc=llc  --compile-twice" llvm/test/CodeGen/AArch64/GlobalISel/arm64-atomic.ll
`

Running the tests with --compile-twice over the full CodeGen directory reported 19,109 failures, though some tests can legitimately fail due to change of output from --compile-twice.  (The last failure, XCore/zextfree.ll, also reported heap-use-after-free.)  Use after free is alarming, however, so we would appreciate feedback on whether the fault lies with --compile-twice, llc, or asan.

### Configuration
MacOS 12.6.3 21G419 on M1 Max
This was built from source that differed from llvmorg-15.0.4 (the branch point for our fork) only by the addition of CMake options for AddressSanitizer with recommended options from https://clang.llvm.org/docs/AddressSanitizer.html#usage:
```
git diff llvmorg-15.0.4
…
+++ b/llvm/CMakeLists.txt
@@ -13,6 +13,9 @@ if(POLICY CMP0116)
   cmake_policy(SET CMP0116 OLD)
 endif()
 
+add_compile_options(-O1 -g -fsanitize=address -fno-omit-frame-pointer)
+add_link_options(-fsanitize=address)
```
The CMake invocation was from a modification of our open-source LLVM-builder [utility](https://github.com/matter-labs/era-compiler-llvm-builder) (hence the vendor fields in the --version output, attached), but that shouldn’t affect execution — let me know if you have any trouble reproducing this.

[AddressSanitizer- heap-use-after-free --compile-twice GlobalISel arm64-atomic.ll ~PMDataManager.txt](https://github.com/llvm/llvm-project/files/10996282/AddressSanitizer-.heap-use-after-free.--compile-twice.GlobalISel.arm64-atomic.ll.PMDataManager.txt)

</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzUV0Fv2zwS_TXMZSCBomzFOvjgOHVRIEGLprvYPRUjaWRxQ5EGSdlxD_vbF6TkuHbdb1FgLwsIrUNSwzfD995Q6JzcaqIlmz-w-eMdDr4zdrlR6LqXjqxsUN9VpjkuV01jybkX1NLLH2TB0s5Y76Aj3CWDowRbTzZpLRG0xoLvCJxH3aBtwJPzsDYNfSTNxGa1snVXzJjYfFSmQvXphRQTG7R9MUvQm17WqVLAxAJ7o7dgfEfWMVHCoSMNdtBwkL6DJKlNv5OKEn-QNbF8xfgj4ytW8OmJf6YpExuPdks-UWrfM7GpBqmapJUaw8aVDKiUquE6JMD0QsiAic2f5jDhyR__75-fEpkX2f1s_Pnh69fPX1m-gmt-hLFb1DAacFwK_I1znon7RZYVLQf0sKunQT6ri6KuOVS7aaSoMpyXGQd3OcIXI7KvH1aPYFpw8gfBIgS7Cu87S9jAt4kTAABM5Bz427RbVYPU43HnK5avLB6-G-ct4TTQqsF1TCwCD3-aTDuWr7LFhIN9EGzB2aq42EZkcZ-yaUtezi73-fL8iB6fUeM2lo3lq39fjsUtmXjgb9UiiEKpmuWryLQ4mvF5hhkvZ2HZX6FYjCiIi_siZhsUpo0-9mZwoLEnt8OaQpiI4_nLF3TuEtrl2Bna75HhfVH_DtmVUj9N02WpFKD3WHfRSNpBKTCD3w0eUDewJ-uk0SnACpzspUIL0rmB4IAOjJXboGx1hNYMugmZIjxJP_pQoKAGdKgh2kCgjRlscK1XJtZw6GTdwYGiz5g92ThrDhpq09BN54mgEBrzg_ToVkBv3mIAKltZo5dGg9mF_1wKn3ywT2uaoaYm4Ak5DruRT6fkxo1i9kYpc5B6G3OQem_GgGe_e6_ln_ndvk-U9JDgfg9MiOQxnl_8dy3Yiv9isEL8b_zwhHTS7qB1yC7kGuK62zWOR_HOhmlnaKSl2ht7nDoSNZCVTKwzXkKLUg2WXDhV35lh24Ez_WmTGjUo2kove_QUyIJSQTMQeAN1h3pLIzUi7Vpr-mtIaZDV4ltHoND503Zht3-sTfix-UFvPvheSF2sAZUzZ5w3_DEN5gJ_cwRxDKJnSgeo0PZSb0OQzhxoH7S3BmcCTw9mUA3gbmeplugJWqKmwvo1UOvQUeRjLBwOyoOSdLvCIWI4e7EGY6NA0gt-iXx8YG10K7eDHVkYJ5-x_vwCmUiLNAeRfZxlZdj9OYNnfBuXfOuki_oMZJwK6sxgawLfoYdGti1ZasaZwDNjt0k2T3k6C3UOGVQWdd3Bzkjt4zXjLNywnzpCdYypYtPIUXQtrJ_xlU7qi2_9cpuJ5bBUm74n3QRRnlYHLJ33OxfUJjZMbGqFepsGfKmxWyY2jaldUMBV0LTzvWIiHxxuf3s32cox8at8b5uleBgfqCb5BgWG5J6k8y71b35aOONsxiHJcibWBTDxEH-VME3IlonFl89Pn9b_hPXzF55lxbtBA0Dd4yt93xkl6yMTi5cP306r4PPT43kl6SZGOo-848Sm-T5x6_tUSiYWyecMki0krZtqxPLH020gabVJTC990lrsKYlHHFheXgRVUr_-HPFGqPMrl6UOOh2pcLbQyMd4xgi9aX7y6rEnmB3pZCLp09Pfn5NopGSBzR8GL5X0RzZ_ZGJxSZGt9N1QpbUJJ9SjD_JWWAWWkMWT6mx051PIwOAQiHQUBMGedGMstJJU40IPC4NJcmoPoy9FV4mNkprYitdQDX4UlOuCMej3nuoB25ZqD_RG9RDTPM3NQJGHnuBVmwPIFo5mgA73obMdwVszVIrem9Zo1tJd2sP84VoByc0r4LWvn_sFXH8BXF6EIsH_W7UnWcTK7qz5F9WhT7VShTawyXhZFmIhbsg1SW_58bXjn8GmV2DTX7GeiHjXLPOmzEu8o2VW3JecFyLjd92yIdHyRZ1VNWb31NT3s3sq2wp5RgWngt_JpeAi53lWCJEXc56WosqpKkssW5rNqGUzTj1K9e5Hd_EetCyyWSHuFFakXPy6E0LTYbwkMSHCx55dTvTbOjbjKlrIexQvvaJlvCT97gvvL7_dbvWXu8Gq5R8fXYQczi6m9J8AAAD__735nTE">