See https://github.com/llvm/llvm-project/issues/135401 for the full flakiness report.
It fails on stage2/asan_ubsan check with:
```
+ /home/b/sanitizer-x86_64-linux-fast/build/llvm_build_asan_ubsan/bin/clang-repl -Xcc -fno-rtti -Xcc -fno-sized-deallocation
JIT session error: In graph incr_module_23-jitted-objectbuffer, section .text.startup: relocation target "_ZN1AD2Ev" at address 0x79618c48d040 is out of range of Delta32 fixup at 0x75618b40d02d (<anonymous block> @ 0x75618b40d010 + 0x1d)
error: Failed to materialize symbols: { (main, { $.incr_module_23.__inits.0, __orc_init_func.incr_module_23, a2 }) }
error: Failed to materialize symbols: { (main, { __orc_init_func.incr_module_23 }) }
The error message ("out of range of Delta32") appears similar to #102858, another Interpreter test that is flaky with ASan.
```
Recent test history on the x86_64-linux-fast bot:
- https://lab.llvm.org/buildbot/#/builders/169/builds/10339: fail
- 10340: buildbot logistical problem
- https://lab.llvm.org/buildbot/#/builders/169/builds/10341: fail
- https://lab.llvm.org/buildbot/#/builders/169/builds/10342: fail
- 10343: pass
- 10344: pass
- https://lab.llvm.org/buildbot/#/builders/169/builds/10345: fail
- 10346: pass
...
At least on my Windows machine, these two tests fail due to not being
able to look up `??3@YAXPEAX_K@Z` (which is
`void __cdecl operator delete(void *, unsigned __int64)` in demangled)
after 130e93cc26ca. Since they don't test anything related to sized
deallocation, just disable sized allocation for them.
Possibly fixes#95451.
Until now the IncrExecutor was created lazily on the first execution
request. In order to process the PTUs that come from initialization, we
have to do it upfront implicitly.
An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizations stripped it from the Module. The added test case
shows the problem; before this patch, it would fail with:
Symbols not found: [ _ZN1AD0Ev, _ZN1AD1Ev ]
This reapplies commit f8dadefd4a, reverted in commit 0e17372b38, but
disables RTTI in the test to avoid problems on Windows.
Differential Revision: https://reviews.llvm.org/D156537
An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizations stripped it from the Module. The added test case
shows the problem; before this patch, it would fail with:
Symbols not found: [ _ZN1AD0Ev, _ZN1AD1Ev ]
Differential Revision: https://reviews.llvm.org/D156537
