asan heap-use-after-free for GlobalISel/arm64-atomic.ll with --compile-twice in llvm::raw_ostream::flush()

[FlashSheridan]

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 (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

[FlashSheridan]

Also happened at current main (b5ff764) with a conventional build per the docs (plus the above sanitizer changes),
cmake -S llvm -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug
ninja -C build check-llvm