forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[clangd] Limit parallelism for clangd unittests #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This revision adds a simple icmp folder that performs the following folds to the LLVM dialect icmp op: - cmpi(eq/ne, x, x) -> true/false - cmpi(eq/ne, alloca, null) -> false/true - cmpi(eq/ne, null, alloca) -> cmpi(eq/ne, alloca, null)
…vm#65324) When a module variable is referenced inside an internal procedure, but the use statement for the module is inside the host, semantics may not create any symbols with HostAssocDetails directly under the internal procedure scope. So pft::getScopeVariableList, that is called in the bridge when lowering the internal procedure scope, failed to instantiate the module variables. This lead to "symbol is not mapped to any IR value" compile time errors. This patch fixes the issue by adding the variables to the list of "captured" global variables from the host program, so that they are instantiated as part of the `internalProcedureBindings` in the bridge. The rational of doing it that way instead of changing `getScopeVariableList` is that `getScopeVariableList` would have to import all the module variables used inside the host since it cannot know which ones are referenced inside the internal procedure from the semantics::Scope information. The fix in this patch only instantiates the module variables from the host that are actually referenced inside the internal procedure.
This patch adds attribute builders for all buildable attributes from the builtin dialect that did not previously have any. These builders can be used to construct attributes of a particular type identified by a string from a Python argument without knowing the details of how to pass that Python argument to the attribute constructor. This is used, for example, in the generated code of the Python bindings of ops. The list of "all" attributes was produced with: ( grep -h "ods_ir.AttrBuilder.get" $(find ../build/ -name "*_ops_gen.py") \ | cut -f2 -d"'" git grep -ho "^def [a-zA-Z0-9_]*" -- include/mlir/IR/CommonAttrConstraints.td \ | cut -f2 -d" " ) | sort -u Then, I only retained those that had an occurence in `mlir/include/mlir/IR`. In particular, this drops many dialect-specific attributes; registering those builders is something that those dialects should do. Finally, I removed those attrbiutes that had a match in `mlir/python/mlir/ir.py` already and implemented the remaining ones. The only ones that still miss a builder now are the following: * Represent more than one possible attribute type: - `Any.*Attr` (9x) - `IntNonNegative` - `IntPositive` - `IsNullAttr` - `ElementsAttr` * I am not sure what "constant attributes" are: - `ConstBoolAttrFalse` - `ConstBoolAttrTrue` - `ConstUnitAttr` * `Location` not exposed by Python bindings: - `LocationArrayAttr` - `LocationAttr` * `get` function not implemented in Python bindings: - `StringElementsAttr` This patch also fixes a compilation problem with `I64SmallVectorArrayAttr`. Reviewed By: makslevental, rkayaith Differential Revision: https://reviews.llvm.org/D159403
This finishes the work of replacing OperandMatchResultTy with ParseStatus, started in D154101. As a drive-by change, rename some RegNo variables to just Reg (a leftover from the days when RegNo had 'unsigned' type).
…65329) We want to work towards eliminating the `RecordStorageLocation` from `RecordValue`. These particular uses of `RecordValue::getChild()` can simply be replaced with `RecordStorageLocation::getChild()`.
…cs (llvm#65311) The main way I cross build lldb is to point CMake at an existing host build to get the native tablegen tools. This is what we had documented before. There is another option where you start from scratch and the host tools are built for you. This patch documents that and explains which one to choose. Added another arm64 example which uses this. So the frst one is the "automatic" build and the second is the traditional approach. For ease of copy paste and understanding, I've kept the full command in each section and noted the one difference between them. Along the way I updated some of the preamble to explain the two approaches and updated some language e.g. removing "just ...". Eveyone's "just" is different, doubly so when cross-compiling.
llvm#65301) The shape of certain elements of the AST can vary depending on the langugage. We currently only support C++.
This implements the first step of https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079 Make required Bazel and CMake preparatory changes which define the var for the customizable namespace and use it (pass it as a compile option -DLIBC_NAMESPACE=<...>). Differential Revision: https://reviews.llvm.org/D159112
`type_traits` and `utility` refer to each other in their implementations. Also `type_traits` starts to become too big to be manageable. This PR splits each function into individual files. FTR this is [how libcxx handles large headers as well](https://github.com/llvm/llvm-project/tree/main/libcxx/include/__type_traits).
In D158086, we limit all floating point scalar move and splat can't fuse vsetvli with different SEW, and this patch try to relax the constraint as possible by introducing new SEW demand type: SEWGreaterThanOrEqualAndLessThan64, that allow SEW fused with larger SEW, but constraint it can't fused with SEW=64. Reviewed By: rogfer01 Differential Revision: https://reviews.llvm.org/D158177
…vm#65314)" This reverts commit b793c7e. It broke the libc-x86_64-debian-gcc-fullbuild-dbg build bot. https://lab.llvm.org/buildbot/#/builders/250/builds/9776
We started seeing a lot of timeouts that align with the change in lit to execute gtests in shards. The logic there assumes tests are single-threaded, which is the case for most of the LLVM, hence they pick #shards ~ #cores (by slightly overshooting). There are enough unittests in clangd that rely on multi-threading, they can create arbitrarily many threads but we limit amount of meaningful work to ~4 thread per process. This change ensures that we're accounting for that paralelism when executing clangd tests and not overloading test executors. In theory the change overestimates the requirements, not all tests are multi-threaded, but it doesn't seem to be resulting in any regressions on my local runs. Fixes llvm#64964. Fixes clangd/clangd#1712.
This fixes LLDB windows buildbot after updates to TestBSDArchives.py. https://lab.llvm.org/buildbot/#/builders/219/builds/5408 I have marked new failing test as an expected failure on Windows.
…), c1 << c2) Assuming the ADD is nsw then it may be sign-extended to merge with a SHL op in a similar fold to the existing (shl (add x, c1), c2) -> (add (shl x, c2), c1 << c2) fold. This is most useful for helping to expose address math for X86, but has also touched several aarch64 test cases as well. Alive2: https://alive2.llvm.org/ce/z/2UpSbJ Differential Revision: https://reviews.llvm.org/D159198
…vm#65314) `type_traits` and `utility` refer to each other in their implementations. Also `type_traits` starts to become too big to be manageable. This PR splits each function into individual files. FTR this is [how libcxx handles large headers as well](https://github.com/llvm/llvm-project/tree/main/libcxx/include/__type_traits). The reland adds two missing functions : is_destructible_v and is_reference_v
To maintain the convention of Scudo names starting with "scudo:", which is used by some tooling to categorize memory usage. Reviewed By: Chia-hungDuan Differential Revision: https://reviews.llvm.org/D157102
…t x), c2), c1 << c2)" This reverts commit b027ce0. This commit breaks Transforms/InferAddressSpaces/AMDGPU/flat_atomic.ll.
… multiple times (llvm#65431) `HeaderIncludes` won't update `ExistingIncludes` during inserting. We need to manage it in tidy check. Fixed: llvm#65285
V implies Zvl128b, but a lot of the fixed vector tests also redundantly specify -riscv-v-vector-bits-min=128. This patch removes them where there isn't another minimum vlen being tested for, and for cases where Zve* is being used Zvl128b was added to maintain the old test diff (and because an awkward vlen probably isn't interesting to test for). Other places where -risc-v-vector-bits-min were being used were replaced with Zvl.
…o m_Group. NFCI (llvm#65457) m_x86_Features_Group always turn `mno-xxxx` into `-target-feature -xxxx`. In this case, we don't have `-gather/-scatter` but `+prefer-no-gather/scatter`. This patch solves unexpected warning when using `mno-gather/mno-scatter`: ``` '-gather' is not a recognized feature for this target (ignoring feature) '-scatter' is not a recognized feature for this target (ignoring feature) ```
Anything that produces a hlfir.expr should have an allocation side effect so that it is not removed by CSE (which would result in two hlfir.destroy operations for the same expression). Similarly for hlfir.associate, which has hlfir.end_associate. Also adds read effects on arguments which are pointer-like or boxes. I see no regressions from this change when running llvm-testsuite with optimization enabled, or from SPEC2017 rate benchmarks. To test this, I have added MLIR's pass for testing side effect interfaces to fir-opt. Differential Revision: https://reviews.llvm.org/D158662
Fix masking error in Thumb_Jump24 Fix halfword comparisons in asserts Add Data_Pointer32 to getEdgeKindName Reviewed By: sgraenitz Differential Revision: https://reviews.llvm.org/D157540
…#65449) scf.forall ops without shared outputs (i.e., fully bufferized ops) are lowered to scf.parallel. scf.forall ops are typically lowered by an earlier pass depending on the execution target. E.g., there are optimized lowerings for GPU execution. This new lowering is for completeness (convert-scf-to-cf can now lower all SCF loop constructs) and provides a simple CPU lowering strategy for testing purposes. scf.parallel is currently lowered to scf.for, which executes sequentially. The scf.parallel lowering could be improved in the future to run on multiple threads.
…eader. Differential Revision: https://reviews.llvm.org/D159463
kadircet
force-pushed
the
no_sharding_clangd
branch
2 times, most recently
from
September 6, 2023 12:00
6270821
to
d71adeb
Compare
kadircet
pushed a commit
that referenced
this pull request
Oct 5, 2023
This reverts commit a1e81d2. Revert "Fix test hip-offload-compress-zlib.hip" This reverts commit ba01ce6. Revert due to sanity fail at https://lab.llvm.org/buildbot/#/builders/5/builds/37188 https://lab.llvm.org/buildbot/#/builders/238/builds/5955 /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Driver/OffloadBundler.cpp:1012:25: runtime error: load of misaligned address 0xaaaae2d90e7c for type 'const uint64_t' (aka 'const unsigned long'), which requires 8 byte alignment 0xaaaae2d90e7c: note: pointer points here bc 00 00 00 94 dc 29 9a 89 fb ca 2b 78 9c 8b 8f 77 f6 71 f4 73 8f f7 77 73 f3 f1 77 74 89 77 0a ^ #0 0xaaaaba125f70 in clang::CompressedOffloadBundle::decompress(llvm::MemoryBuffer const&, bool) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Driver/OffloadBundler.cpp:1012:25 #1 0xaaaaba126150 in clang::OffloadBundler::ListBundleIDsInFile(llvm::StringRef, clang::OffloadBundlerConfig const&) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Driver/OffloadBundler.cpp:1089:7 Will reland after fixing it.
kadircet
pushed a commit
that referenced
this pull request
Jan 3, 2024
This has been flaky for a while, for example https://lab.llvm.org/buildbot/#/builders/96/builds/50350 ``` Command Output (stdout): -- lldb version 18.0.0git (https://github.com/llvm/llvm-project.git revision 3974d89) clang revision 3974d89 llvm revision 3974d89 "can't evaluate expressions when the process is running." ``` ``` PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. #0 0x0000ffffa46191a0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x529a1a0) #1 0x0000ffffa4617144 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x5298144) #2 0x0000ffffa46198d0 SignalHandler(int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x529a8d0) llvm#3 0x0000ffffab25b7dc (linux-vdso.so.1+0x7dc) llvm#4 0x0000ffffab13d050 /build/glibc-Q8DG8B/glibc-2.31/string/../sysdeps/aarch64/multiarch/memcpy_advsimd.S:92:0 llvm#5 0x0000ffffa446f420 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::PrivateSetRegisterValue(unsigned int, llvm::ArrayRef<unsigned char>) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f0420) llvm#6 0x0000ffffa446f7b8 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::GetPrimordialRegister(lldb_private::RegisterInfo const*, lldb_private::process_gdb_remote::GDBRemoteCommunicationClient&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f07b8) llvm#7 0x0000ffffa446f308 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::ReadRegisterBytes(lldb_private::RegisterInfo const*) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f0308) llvm#8 0x0000ffffa446ec1c lldb_private::process_gdb_remote::GDBRemoteRegisterContext::ReadRegister(lldb_private::RegisterInfo const*, lldb_private::RegisterValue&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50efc1c) llvm#9 0x0000ffffa412eaa4 lldb_private::RegisterContext::ReadRegisterAsUnsigned(lldb_private::RegisterInfo const*, unsigned long) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4dafaa4) llvm#10 0x0000ffffa420861c ReadLinuxProcessAddressMask(std::shared_ptr<lldb_private::Process>, llvm::StringRef) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4e8961c) llvm#11 0x0000ffffa4208430 ABISysV_arm64::FixCodeAddress(unsigned long) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4e89430) ``` Judging by the backtrace something is trying to read the pointer authentication address/code mask registers. This explains why I've not seen this issue locally, as the buildbot runs on Graviton 3 with has the pointer authentication extension. I will try to reproduce, fix and re-enable the test.
kadircet
pushed a commit
that referenced
this pull request
Jan 3, 2024
This PR adds support for thread names in lldb on Windows. ``` (lldb) thr list Process 2960 stopped thread llvm#53: tid = 0x03a0, 0x00007ff84582db34 ntdll.dll`NtWaitForMultipleObjects + 20 thread llvm#29: tid = 0x04ec, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'SPUW.6' thread llvm#89: tid = 0x057c, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'PPU[0x1000019] physics[main]' thread llvm#3: tid = 0x0648, 0x00007ff843c2cafe combase.dll`InternalDoATClassCreate + 39518 thread llvm#93: tid = 0x0688, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'PPU[0x100501d] uMovie::StreamingThread' thread #1: tid = 0x087c, 0x00007ff842e7a104 win32u.dll`NtUserMsgWaitForMultipleObjectsEx + 20 thread llvm#96: tid = 0x0890, 0x00007ff845830a14 ntdll.dll`NtWaitForAlertByThreadId + 20, name = 'PPU[0x1002020] HLE Video Decoder' <...> ```
kadircet
pushed a commit
that referenced
this pull request
Jan 4, 2024
The upstream test relies on jump-tables, which are lowered in dramatically different ways with later arm64e/ptrauth patches. Concretely, it's failing for at least two reasons: - ptrauth removes x16/x17 from tcGPR64 to prevent indirect tail-calls from using either register as the callee, conflicting with their usage as scratch for the tail-call LR auth checking sequence. In the 1/2_available_regs_left tests, this causes the MI scheduler to move the load up across some of the inlineasm register clobbers. - ptrauth adds an x16/x17-using pseudo for jump-table dispatch, which looks somewhat different from the regular jump-table dispatch codegen by itself, but also prevents compression currently. They seem like sensible changes. But they mean the tests aren't really testing what they're intented to, because there's always an implicit x16/x17 clobber when using jump-tables. This updates the test in a way that should work identically regardless of ptrauth support, with one exception, #1 above, which merely reorders the load/inlineasm w.r.t. eachother. I verified the tests still fail the live-reg assertions when applicable.
kadircet
pushed a commit
that referenced
this pull request
Feb 29, 2024
…ter partial ordering when determining primary template (llvm#82417) Consider the following: ``` struct A { static constexpr bool x = true; }; template<typename T, typename U> void f(T, U) noexcept(T::y); // #1, error: no member named 'y' in 'A' template<typename T, typename U> void f(T, U*) noexcept(T::x); // #2 template<> void f(A, int*) noexcept; // explicit specialization of #2 ``` We currently instantiate the exception specification of all candidate function template specializations when deducting template arguments for an explicit specialization, which results in a error despite `#1` not being selected by partial ordering as the most specialized template. According to [except.spec] p13: > An exception specification is considered to be needed when: > - [...] > - the exception specification is compared to that of another declaration (e.g., an explicit specialization or an overriding virtual function); Assuming that "comparing declarations" means "determining whether the declarations correspond and declare the same entity" (per [basic.scope.scope] p4 and [basic.link] p11.1, respectively), the exception specification does _not_ need to be instantiated until _after_ partial ordering, at which point we determine whether the implicitly instantiated specialization and the explicit specialization declare the same entity (the determination of whether two functions/function templates correspond does not consider the exception specifications). This patch defers the instantiation of the exception specification until a single function template specialization is selected via partial ordering, matching the behavior of GCC, EDG, and MSVC: see https://godbolt.org/z/Ebb6GTcWE.
kadircet
pushed a commit
that referenced
this pull request
May 24, 2024
…llvm#92855) This solves some ambuguity introduced in P0522 regarding how template template parameters are partially ordered, and should reduce the negative impact of enabling `-frelaxed-template-template-args` by default. When performing template argument deduction, we extend the provisional wording introduced in llvm#89807 so it also covers deduction of class templates. Given the following example: ```C++ template <class T1, class T2 = float> struct A; template <class T3> struct B; template <template <class T4> class TT1, class T5> struct B<TT1<T5>>; // #1 template <class T6, class T7> struct B<A<T6, T7>>; // #2 template struct B<A<int>>; ``` Prior to P0522, `#2` was picked. Afterwards, this became ambiguous. This patch restores the pre-P0522 behavior, `#2` is picked again. This has the beneficial side effect of making the following code valid: ```C++ template<class T, class U> struct A {}; A<int, float> v; template<template<class> class TT> void f(TT<int>); // OK: TT picks 'float' as the default argument for the second parameter. void g() { f(v); } ``` --- Since this changes provisional implementation of CWG2398 which has not been released yet, and already contains a changelog entry, we don't provide a changelog entry here.
kadircet
pushed a commit
that referenced
this pull request
May 24, 2024
The problematic program is as follows: ```shell #define pre_a 0 #define PRE(x) pre_##x void f(void) { PRE(a) && 0; } int main(void) { return 0; } ``` in which after token concatenation (`##`), there's another nested macro `pre_a`. Currently only the outer expansion region will be produced. ([compiler explorer link](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:___c,selection:(endColumn:29,endLineNumber:8,positionColumn:29,positionLineNumber:8,selectionStartColumn:29,selectionStartLineNumber:8,startColumn:29,startLineNumber:8),source:'%23define+pre_a+0%0A%23define+PRE(x)+pre_%23%23x%0A%0Avoid+f(void)+%7B%0A++++PRE(a)+%26%26+0%3B%0A%7D%0A%0Aint+main(void)+%7B+return+0%3B+%7D'),l:'5',n:'0',o:'C+source+%231',t:'0')),k:51.69491525423727,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((g:!((h:compiler,i:(compiler:cclang_assertions_trunk,filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'1',trim:'1',verboseDemangling:'0'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:2,lang:___c,libs:!(),options:'-fprofile-instr-generate+-fcoverage-mapping+-fcoverage-mcdc+-Xclang+-dump-coverage-mapping+',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x86-64+clang+(assertions+trunk)+(Editor+%231)',t:'0')),k:34.5741843594503,l:'4',m:28.903654485049834,n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compilerName:'x86-64+clang+(trunk)',editorid:1,fontScale:14,fontUsePx:'0',j:2,wrap:'1'),l:'5',n:'0',o:'Output+of+x86-64+clang+(assertions+trunk)+(Compiler+%232)',t:'0')),header:(),l:'4',m:71.09634551495017,n:'0',o:'',s:0,t:'0')),k:48.30508474576271,l:'3',n:'0',o:'',t:'0')),l:'2',m:100,n:'0',o:'',t:'0')),version:4)) ```text f: File 0, 4:14 -> 6:2 = #0 Decision,File 0, 5:5 -> 5:16 = M:0, C:2 Expansion,File 0, 5:5 -> 5:8 = #0 (Expanded file = 1) File 0, 5:15 -> 5:16 = #1 Branch,File 0, 5:15 -> 5:16 = 0, 0 [2,0,0] File 1, 2:16 -> 2:23 = #0 File 2, 1:15 -> 1:16 = #0 File 2, 1:15 -> 1:16 = #0 Branch,File 2, 1:15 -> 1:16 = 0, 0 [1,2,0] ``` The inner expansion region isn't produced because: 1. In the range-based for loop quoted below, each sloc is processed and possibly emit a corresponding expansion region. 2. For our sloc in question, its direct parent returned by `getIncludeOrExpansionLoc()` is a `<scratch space>`, because that's how `##` is processed. https://github.com/llvm/llvm-project/blob/88b6186af3908c55b357858eb348b5143f21c289/clang/lib/CodeGen/CoverageMappingGen.cpp#L518-L520 3. This `<scratch space>` cannot be found in the FileID mapping so `ParentFileID` will be assigned an `std::nullopt` https://github.com/llvm/llvm-project/blob/88b6186af3908c55b357858eb348b5143f21c289/clang/lib/CodeGen/CoverageMappingGen.cpp#L521-L526 4. As a result this iteration of for loop finishes early and no expansion region is added for the sloc. This problem gets worse with MC/DC: as the example shows, there's a branch from File 2 but File 2 itself is missing. This will trigger assertion failures. The fix is more or less a workaround and takes a similar approach as llvm#89573. ~~Depends on llvm#89573.~~ This includes llvm#89573. Kudos to @chapuni! This and llvm#89573 together fix llvm#87000: I tested locally, both the reduced program and my original use case (fwiw, Linux kernel) can run successfully. --------- Co-authored-by: NAKAMURA Takumi <[email protected]>
kadircet
pushed a commit
that referenced
this pull request
Aug 20, 2024
…lvm#104148) `hasOperands` does not always execute matchers in the order they are written. This can cause issue in code using bindings when one operand matcher is relying on a binding set by the other. With this change, the first matcher present in the code is always executed first and any binding it sets are available to the second matcher. Simple example with current version (1 match) and new version (2 matches): ```bash > cat tmp.cpp int a = 13; int b = ((int) a) - a; int c = a - ((int) a); > clang-query tmp.cpp clang-query> set traversal IgnoreUnlessSpelledInSource clang-query> m binaryOperator(hasOperands(cStyleCastExpr(has(declRefExpr(hasDeclaration(valueDecl().bind("d"))))), declRefExpr(hasDeclaration(valueDecl(equalsBoundNode("d")))))) Match #1: tmp.cpp:1:1: note: "d" binds here int a = 13; ^~~~~~~~~~ tmp.cpp:2:9: note: "root" binds here int b = ((int)a) - a; ^~~~~~~~~~~~ 1 match. > ./build/bin/clang-query tmp.cpp clang-query> set traversal IgnoreUnlessSpelledInSource clang-query> m binaryOperator(hasOperands(cStyleCastExpr(has(declRefExpr(hasDeclaration(valueDecl().bind("d"))))), declRefExpr(hasDeclaration(valueDecl(equalsBoundNode("d")))))) Match #1: tmp.cpp:1:1: note: "d" binds here 1 | int a = 13; | ^~~~~~~~~~ tmp.cpp:2:9: note: "root" binds here 2 | int b = ((int)a) - a; | ^~~~~~~~~~~~ Match #2: tmp.cpp:1:1: note: "d" binds here 1 | int a = 13; | ^~~~~~~~~~ tmp.cpp:3:9: note: "root" binds here 3 | int c = a - ((int)a); | ^~~~~~~~~~~~ 2 matches. ``` If this should be documented or regression tested anywhere please let me know where.
kadircet
pushed a commit
that referenced
this pull request
Aug 22, 2024
…104523) Compilers and language runtimes often use helper functions that are fundamentally uninteresting when debugging anything but the compiler/runtime itself. This patch introduces a user-extensible mechanism that allows for these frames to be hidden from backtraces and automatically skipped over when navigating the stack with `up` and `down`. This does not affect the numbering of frames, so `f <N>` will still provide access to the hidden frames. The `bt` output will also print a hint that frames have been hidden. My primary motivation for this feature is to hide thunks in the Swift programming language, but I'm including an example recognizer for `std::function::operator()` that I wished for myself many times while debugging LLDB. rdar://126629381 Example output. (Yes, my proof-of-concept recognizer could hide even more frames if we had a method that returned the function name without the return type or I used something that isn't based off regex, but it's really only meant as an example). before: ``` (lldb) thread backtrace --filtered=false * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10 frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25 frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12 frame llvm#3: 0x0000000100003968 a.out`std::__1::__function::__alloc_func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()[abi:se200000](this=0x000000016fdff280, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:171:12 frame llvm#4: 0x00000001000026bc a.out`std::__1::__function::__func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()(this=0x000000016fdff278, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:313:10 frame llvm#5: 0x0000000100003c38 a.out`std::__1::__function::__value_func<int (int, int)>::operator()[abi:se200000](this=0x000000016fdff278, __args=0x000000016fdff224, __args=0x000000016fdff220) const at function.h:430:12 frame llvm#6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10 frame llvm#7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10 frame llvm#8: 0x0000000183cdf154 dyld`start + 2476 (lldb) ``` after ``` (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10 frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25 frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12 frame llvm#6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10 frame llvm#7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10 frame llvm#8: 0x0000000183cdf154 dyld`start + 2476 Note: Some frames were hidden by frame recognizers ```
kadircet
pushed a commit
that referenced
this pull request
Aug 28, 2024
`JITDylibSearchOrderResolver` local variable can be destroyed before completion of all callbacks. Capture it together with `Deps` in `OnEmitted` callback. Original error: ``` ==2035==ERROR: AddressSanitizer: stack-use-after-return on address 0x7bebfa155b70 at pc 0x7ff2a9a88b4a bp 0x7bec08d51980 sp 0x7bec08d51978 READ of size 8 at 0x7bebfa155b70 thread T87 (tf_xla-cpu-llvm) #0 0x7ff2a9a88b49 in operator() llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:58 #1 0x7ff2a9a88b49 in __invoke<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:149:25 #2 0x7ff2a9a88b49 in __call<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:224:5 llvm#3 0x7ff2a9a88b49 in operator() libcxx/include/__functional/function.h:210:12 llvm#4 0x7ff2a9a88b49 in void std::__u::__function::__policy_invoker<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, ```
kadircet
pushed a commit
that referenced
this pull request
Sep 13, 2024
Static destructor can race with calls to notify and trigger tsan warning. ``` WARNING: ThreadSanitizer: data race (pid=5787) Write of size 1 at 0x55bec9df8de8 by thread T23: #0 pthread_mutex_destroy [third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1344](third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp?l=1344&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x1b12affb) (BuildId: ff25ace8b17d9863348bb1759c47246c) #1 __libcpp_recursive_mutex_destroy [third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h:91](third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h?l=91&cl=669089572):10 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d4e9) (BuildId: ff25ace8b17d9863348bb1759c47246c) #2 std::__tsan::recursive_mutex::~recursive_mutex() [third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp:52](third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp?l=52&cl=669089572):11 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d4e9) llvm#3 ~SmartMutex [third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h:28](third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h?l=28&cl=669089572):11 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaedfe) (BuildId: ff25ace8b17d9863348bb1759c47246c) llvm#4 (anonymous namespace)::PerfJITEventListener::~PerfJITEventListener() [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp:65](third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp?l=65&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaedfe) llvm#5 cxa_at_exit_callback_installed_at(void*) [third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:437](third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp?l=437&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x1b172cb9) (BuildId: ff25ace8b17d9863348bb1759c47246c) llvm#6 llvm::JITEventListener::createPerfJITEventListener() [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp:496](third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp?l=496&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcad8f5) (BuildId: ff25ace8b17d9863348bb1759c47246c) ``` ``` Previous atomic read of size 1 at 0x55bec9df8de8 by thread T192 (mutexes: write M0, write M1): #0 pthread_mutex_unlock [third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1387](third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp?l=1387&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x1b12b6bb) (BuildId: ff25ace8b17d9863348bb1759c47246c) #1 __libcpp_recursive_mutex_unlock [third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h:87](third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h?l=87&cl=669089572):10 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d589) (BuildId: ff25ace8b17d9863348bb1759c47246c) #2 std::__tsan::recursive_mutex::unlock() [third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp:64](third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp?l=64&cl=669089572):11 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d589) llvm#3 unlock [third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h:47](third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h?l=47&cl=669089572):16 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaf968) (BuildId: ff25ace8b17d9863348bb1759c47246c) llvm#4 ~lock_guard [third_party/crosstool/v18/stable/src/libcxx/include/__mutex/lock_guard.h:39](third_party/crosstool/v18/stable/src/libcxx/include/__mutex/lock_guard.h?l=39&cl=669089572):101 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaf968) llvm#5 (anonymous namespace)::PerfJITEventListener::notifyObjectLoaded(unsigned long, llvm::object::ObjectFile const&, llvm::RuntimeDyld::LoadedObjectInfo const&) [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp:290](https://cs.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp?l=290&cl=669089572):1 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaf968) llvm#6 llvm::orc::RTDyldObjectLinkingLayer::onObjEmit(llvm::orc::MaterializationResponsibility&, llvm::object::OwningBinary<llvm::object::ObjectFile>, std::__tsan::unique_ptr<llvm::RuntimeDyld::MemoryManager, std::__tsan::default_delete<llvm::RuntimeDyld::MemoryManager>>, std::__tsan::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo, std::__tsan::default_delete<llvm::RuntimeDyld::LoadedObjectInfo>>, std::__tsan::unique_ptr<llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>, llvm::DenseMapInfo<llvm::orc::JITDylib*, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>>>, std::__tsan::default_delete<llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>, llvm::DenseMapInfo<llvm::orc::JITDylib*, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>>>>>, llvm::Error) [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:386](https://cs.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp?l=386&cl=669089572):10 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bc404a8) (BuildId: ff25ace8b17d9863348bb1759c47246c) ```
kadircet
pushed a commit
that referenced
this pull request
Sep 13, 2024
…llvm#94981) This extends default argument deduction to cover class templates as well, applying only to partial ordering, adding to the provisional wording introduced in llvm#89807. This solves some ambuguity introduced in P0522 regarding how template template parameters are partially ordered, and should reduce the negative impact of enabling `-frelaxed-template-template-args` by default. Given the following example: ```C++ template <class T1, class T2 = float> struct A; template <class T3> struct B; template <template <class T4> class TT1, class T5> struct B<TT1<T5>>; // #1 template <class T6, class T7> struct B<A<T6, T7>>; // #2 template struct B<A<int>>; ``` Prior to P0522, `#2` was picked. Afterwards, this became ambiguous. This patch restores the pre-P0522 behavior, `#2` is picked again.
kadircet
pushed a commit
that referenced
this pull request
Sep 26, 2024
…ap (llvm#108825) This attempts to improve user-experience when LLDB stops on a verbose_trap. Currently if a `__builtin_verbose_trap` triggers, we display the first frame above the call to the verbose_trap. So in the newly added test case, we would've previously stopped here: ``` (lldb) run Process 28095 launched: '/Users/michaelbuch/a.out' (arm64) Process 28095 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = Bounds error: out-of-bounds access frame #1: 0x0000000100003f5c a.out`std::__1::vector<int>::operator[](this=0x000000016fdfebef size=0, (null)=10) at verbose_trap.cpp:6:9 3 template <typename T> 4 struct vector { 5 void operator[](unsigned) { -> 6 __builtin_verbose_trap("Bounds error", "out-of-bounds access"); 7 } 8 }; ``` After this patch, we would stop in the first non-`std` frame: ``` (lldb) run Process 27843 launched: '/Users/michaelbuch/a.out' (arm64) Process 27843 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = Bounds error: out-of-bounds access frame #2: 0x0000000100003f44 a.out`g() at verbose_trap.cpp:14:5 11 12 void g() { 13 std::vector<int> v; -> 14 v[10]; 15 } 16 ``` rdar://134490328
kadircet
pushed a commit
that referenced
this pull request
Sep 26, 2024
Random testing found that the Z3 wrapper does not support UnarySymExpr, which was added recently and not included in the original Z3 wrapper. For now, just avoid submitting expressions to Z3 to avoid compiler crashes. Some crash context ... clang -cc1 -analyze -analyzer-checker=core z3-unarysymexpr.c -analyzer-constraints=z3 Unsupported expression to reason about! UNREACHABLE executed at clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h:297! Stack dump: 3. <root>/clang/test/Analysis/z3-unarysymexpr.c:13:7: Error evaluating branch #0 <addr> llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) #1 <addr> llvm::sys::RunSignalHandlers() llvm#8 <addr> clang::ento::SimpleConstraintManager::assumeAux( llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::ento::NonLoc, bool) llvm#9 <addr> clang::ento::SimpleConstraintManager::assume( llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::ento::NonLoc, bool) Co-authored-by: einvbri <[email protected]>
kadircet
pushed a commit
that referenced
this pull request
Oct 28, 2024
When compiling for an SVE target we can use INDEX to generate constant fixed-length step vectors, e.g.: ``` uint32x4_t foo() { return (uint32x4_t){0, 1, 2, 3}; } ``` Currently: ``` foo(): adrp x8, .LCPI1_0 ldr q0, [x8, :lo12:.LCPI1_0] ret ``` With INDEX: ``` foo(): index z0.s, #0, #1 ret ``` The logic for this was already in `LowerBUILD_VECTOR`, though it was hidden under a check for `!Subtarget->isNeonAvailable()`. This patch refactors this to enable the corresponding code path unconditionally for constant step vectors (as long as we can use SVE for them).
kadircet
pushed a commit
that referenced
this pull request
Nov 1, 2024
…ates explicitly specialized for an implicitly instantiated class template specialization (llvm#113464) Consider the following: ``` template<typename T> struct A { template<typename U> struct B { static constexpr int x = 0; // #1 }; template<typename U> struct B<U*> { static constexpr int x = 1; // #2 }; }; template<> template<typename U> struct A<long>::B { static constexpr int x = 2; // llvm#3 }; static_assert(A<short>::B<int>::y == 0); // uses #1 static_assert(A<short>::B<int*>::y == 1); // uses #2 static_assert(A<long>::B<int>::y == 2); // uses llvm#3 static_assert(A<long>::B<int*>::y == 2); // uses llvm#3 ``` According to [temp.spec.partial.member] p2: > If the primary member template is explicitly specialized for a given (implicit) specialization of the enclosing class template, the partial specializations of the member template are ignored for this specialization of the enclosing class template. If a partial specialization of the member template is explicitly specialized for a given (implicit) specialization of the enclosing class template, the primary member template and its other partial specializations are still considered for this specialization of the enclosing class template. The example above fails to compile because we currently don't implement [temp.spec.partial.member] p2. This patch implements the wording, fixing llvm#51051.
kadircet
pushed a commit
that referenced
this pull request
Nov 7, 2024
We've found that basic profiling could help improving/optimizing when developing clang-tidy checks. This PR adds an extra command ``` set enable-profile (true|false) Set whether to enable matcher profiling. ``` which enables profiling queries on each file. Sample output: ``` $ cat test.cql set enable-profile true m binaryOperator(isExpansionInMainFile()) $ cat test.c int test(int i, int j) { return i + j; } $ clang-query --track-memory -f test.cql test.c -- Match #1: {{.*}}/test.c:2:10: note: "root" binds here 2 | return i + j; | ^~~~~ 1 match. ===-------------------------------------------------------------------------=== clang-query matcher profiling ===-------------------------------------------------------------------------=== Total Execution Time: 0.0000 seconds (0.0000 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- ---Mem--- --- Name --- 0.0000 (100.0%) 0.0000 (100.0%) 0.0000 (100.0%) 0.0000 (100.0%) 224 {{.*}}/test.c 0.0000 (100.0%) 0.0000 (100.0%) 0.0000 (100.0%) 0.0000 (100.0%) 224 Total ```
kadircet
pushed a commit
that referenced
this pull request
Nov 19, 2024
…tely from Linux (llvm#115722) This test fails on https://lab.llvm.org/staging/#/builders/197/builds/76/steps/18/logs/FAIL__lldb-shell__inline_sites_live_cpp because of a little difference in the lldb output. ``` # .---command stderr------------ # | C:\buildbot\as-builder-10\lldb-x-aarch64\llvm-project\lldb\test\Shell\SymbolFile\NativePDB\inline_sites_live.cpp:25:11: error: CHECK: expected string not found in input # | // CHECK: * thread #1, stop reason = breakpoint 1 # | ^ # | <stdin>:1:1: note: scanning from here # | (lldb) platform select remote-linux # | ^ # | <stdin>:28:27: note: possible intended match here # | * thread #1, name = 'inline_sites_li', stop reason = breakpoint 1.3 # | ^ # | ```
kadircet
pushed a commit
that referenced
this pull request
Nov 19, 2024
Add patterns to fold MOV (scalar, predicated) to MOV (imm, pred, merging) or MOV (imm, pred, zeroing) as appropriate. This affects the `@llvm.aarch64.sve.dup` intrinsics, which currently generate MOV (scalar, predicated) instructions even when the immediate forms are possible. For example: ``` svuint8_t mov_z_b(svbool_t p) { return svdup_u8_z(p, 1); } ``` Currently generates: ``` mov_z_b(__SVBool_t): mov z0.b, #0 mov w8, #1 mov z0.b, p0/m, w8 ret ``` Instead of: ``` mov_z_b(__SVBool_t): mov z0.b, p0/z, #1 ret ```
kadircet
pushed a commit
that referenced
this pull request
Nov 19, 2024
…onger cause a crash (llvm#116569) This PR fixes a bug introduced by llvm#110199, which causes any half float argument to crash the compiler on MIPS64. Currently compiling this bit of code with `llc -mtriple=mips64`: ``` define void @half_args(half %a) nounwind { entry: ret void } ``` Crashes with the following log: ``` LLVM ERROR: unable to allocate function argument #0 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: llc -mtriple=mips64 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function '@half_args' #0 0x000055a3a4013df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32d0df8) #1 0x000055a3a401199e llvm::sys::RunSignalHandlers() (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32ce99e) #2 0x000055a3a40144a8 SignalHandler(int) Signals.cpp:0:0 llvm#3 0x00007f00bde558c0 __restore_rt libc_sigaction.c:0:0 llvm#4 0x00007f00bdea462c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 llvm#5 0x00007f00bde55822 gsignal ./signal/../sysdeps/posix/raise.c:27:6 llvm#6 0x00007f00bde3e4af abort ./stdlib/abort.c:81:7 llvm#7 0x000055a3a3f80e3c llvm::report_fatal_error(llvm::Twine const&, bool) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x323de3c) llvm#8 0x000055a3a2e20dfa (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x20dddfa) llvm#9 0x000055a3a2a34e20 llvm::MipsTargetLowering::LowerFormalArguments(llvm::SDValue, unsigned int, bool, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::SDLoc const&, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const MipsISelLowering.cpp:0:0 llvm#10 0x000055a3a3d896a9 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30466a9) llvm#11 0x000055a3a3e0b3ec llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c83ec) llvm#12 0x000055a3a3e09e21 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c6e21) llvm#13 0x000055a3a2aae1ca llvm::MipsDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) MipsISelDAGToDAG.cpp:0:0 llvm#14 0x000055a3a3e07706 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c4706) llvm#15 0x000055a3a3051ed6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x230eed6) llvm#16 0x000055a3a35a3ec9 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x2860ec9) llvm#17 0x000055a3a35ac3b2 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x28693b2) llvm#18 0x000055a3a35a499c llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x286199c) llvm#19 0x000055a3a262abbb main (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x18e7bbb) llvm#20 0x00007f00bde3fc4c __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 llvm#21 0x00007f00bde3fd05 call_init ./csu/../csu/libc-start.c:128:20 llvm#22 0x00007f00bde3fd05 __libc_start_main@GLIBC_2.2.5 ./csu/../csu/libc-start.c:347:5 llvm#23 0x000055a3a2624921 _start /builddir/glibc-2.39/csu/../sysdeps/x86_64/start.S:117:0 ``` This is caused by the fact that after the change, `f16`s are no longer lowered as `f32`s in calls. Two possible fixes are available: - Update calling conventions to properly support passing `f16` as integers. - Update `useFPRegsForHalfType()` to return `true` so that `f16` are still kept in `f32` registers, as before llvm#110199. This PR implements the first solution to not introduce any more ABI changes as llvm#110199 already did. As of what is the correct ABI for halfs, I don't think there is a correct answer. GCC doesn't support halfs on MIPS, and I couldn't find any information on old MIPS ABI manuals either.
kadircet
pushed a commit
that referenced
this pull request
Dec 3, 2024
…lvm#116655) This is the first part of the effort to make parsing of clause modifiers more uniform and robust. Currently, when multiple modifiers are allowed, the parser will expect them to appear in a hard-coded order. Additionally, modifier properties (such as "ultimate") are checked separately for each case. The overall plan is 1. Extract all modifiers into their own top-level classes, and then equip them with sets of common properties that will allow performing the property checks generically, without refering to the specific kind of the modifier. 2. Define a parser (as a separate class) for each modifier. 3. For each clause define a union (std::variant) of all allowable modifiers, and parse the modifiers as a list of these unions. The intent is also to isolate parts of the code that could eventually be auto-generated. OpenMP modifier overhaul: #1/3
kadircet
pushed a commit
that referenced
this pull request
Dec 3, 2024
…abort (llvm#117603) Hey guys, I found that Flang's built-in ABORT function is incomplete when I was using it. Compared with gfortran's ABORT (which can both abort and print out a backtrace), flang's ABORT implementation lacks the function of printing out a backtrace. This feature is essential for debugging and understanding the call stack at the failure point. To solve this problem, I completed the "// TODO:" of the abort function, and then implemented an additional built-in function BACKTRACE for flang. After a brief reading of the relevant source code, I used backtrace and backtrace_symbols in "execinfo.h" to quickly implement this. But since I used the above two functions directly, my implementation is slightly different from gfortran's implementation (in the output, the function call stack before main is additionally output, and the function line number is missing). In addition, since I used the above two functions, I did not need to add -g to embed debug information into the ELF file, but needed -rdynamic to ensure that the symbols are added to the dynamic symbol table (so that the function name will be printed out). Here is a comparison of the output between gfortran 's backtrace and my implementation: gfortran's implemention output: ``` #0 0x557eb71f4184 in testfun2_ at /home/hunter/plct/fortran/test.f90:5 #1 0x557eb71f4165 in testfun1_ at /home/hunter/plct/fortran/test.f90:13 #2 0x557eb71f4192 in test_backtrace at /home/hunter/plct/fortran/test.f90:17 llvm#3 0x557eb71f41ce in main at /home/hunter/plct/fortran/test.f90:18 ``` my impelmention output: ``` Backtrace: #0 ./test(_FortranABacktrace+0x32) [0x574f07efcf92] #1 ./test(testfun2_+0x14) [0x574f07efc7b4] #2 ./test(testfun1_+0xd) [0x574f07efc7cd] llvm#3 ./test(_QQmain+0x9) [0x574f07efc7e9] llvm#4 ./test(main+0x12) [0x574f07efc802] llvm#5 /usr/lib/libc.so.6(+0x25e08) [0x76954694fe08] llvm#6 /usr/lib/libc.so.6(__libc_start_main+0x8c) [0x76954694fecc] llvm#7 ./test(_start+0x25) [0x574f07efc6c5] ``` test program is: ``` function testfun2() result(err) implicit none integer :: err err = 1 call backtrace end function testfun2 subroutine testfun1() implicit none integer :: err integer :: testfun2 err = testfun2() end subroutine testfun1 program test_backtrace call testfun1() end program test_backtrace ``` I am well aware of the importance of line numbers, so I am now working on implementing line numbers (by parsing DWARF information) and supporting cross-platform (Windows) support.
kadircet
added a commit
that referenced
this pull request
Dec 3, 2024
following ASAN failure is fixed with this patch. We store cleanups in EvalInfo, which are usually run with certain ScopeRAII objects. We can have temporaries in the cleanup stack, backed by CallStackFrame. If such temporaries aren't destroyed before the enclosing CallStackFrame, we end up accessing the freed temporary to run the cleanup. ``` ================================================================= ==553356==ERROR: AddressSanitizer: heap-use-after-free on address 0x7c63f05a65b0 at pc 0x561e4add6ae7 bp 0x7fff430f7770 sp 0x7fff430f7768 READ of size 4 at 0x7c63f05a65b0 thread T0 #0 0x561e4add6ae6 in clang::APValue::operator=(clang::APValue&&) third_party/llvm/llvm-project/clang/lib/AST/APValue.cpp:394:9 #1 0x561e4b41fd0b in (anonymous namespace)::Cleanup::endLifetime((anonymous namespace)::EvalInfo&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:749:27 #2 0x561e4b4d42a7 in (anonymous namespace)::ScopeRAII<((anonymous namespace)::ScopeKind)1>::cleanup((anonymous namespace)::EvalInfo&, bool, unsigned int) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1449:41 llvm#3 0x561e4b4246ec in destroy third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1427:17 llvm#4 0x561e4b4246ec in ~ScopeRAII third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1433:9 llvm#5 0x561e4b4246ec in EvaluateCond((anonymous namespace)::EvalInfo&, clang::VarDecl const*, clang::Expr const*, bool&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5185:1 llvm#6 0x561e4b41ea8c in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5555:17 llvm#7 0x561e4b423755 in EvaluateLoopBody((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5221:24 llvm#8 0x561e4b41d597 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5635:28 llvm#9 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#10 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#11 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#12 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#13 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#14 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#15 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#16 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#17 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#18 0x561e4b41f204 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5511:17 llvm#19 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#20 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#21 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#22 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#23 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#24 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#25 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#26 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#27 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#28 0x561e4b4ad3c2 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#29 0x561e4b4ad3c2 in (anonymous namespace)::IntExprEvaluator::VisitCastExpr(clang::CastExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:14877:10 llvm#30 0x561e4b49f192 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h llvm#31 0x561e4b3ff8af in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16339:41 llvm#32 0x561e4b4a0dd2 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#33 0x561e4b4a0dd2 in (anonymous namespace)::IntExprEvaluator::VisitUnaryOperator(clang::UnaryOperator const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:14795:10 llvm#34 0x561e4b49f0db in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h llvm#35 0x561e4b3ff8af in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16339:41 llvm#36 0x561e4b3fbe35 in EvaluateAsRValue((anonymous namespace)::EvalInfo&, clang::Expr const*, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16455:8 llvm#37 0x561e4b3fc278 in clang::Expr::EvaluateForOverflow(clang::ASTContext const&) const third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16903:11 llvm#38 0x561e4a020e69 in clang::Sema::CheckForIntOverflow(clang::Expr const*) third_party/crosstool/v18/stable/src/libcxx/include/__memory/uninitialized_algorithms.h llvm#39 0x561e4a021cd7 in clang::Sema::CheckCompletedExpr(clang::Expr*, clang::SourceLocation, bool) third_party/llvm/llvm-project/clang/lib/Sema/SemaChecking.cpp:12989:5 llvm#40 0x561e4a4b9d2e in clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool, bool, bool) third_party/llvm/llvm-project/clang/lib/Sema/SemaExprCXX.cpp:9225:3 llvm#41 0x561e4a372e20 in MakeFullExpr third_party/llvm/llvm-project/clang/include/clang/Sema/Sema.h:7292:9 llvm#42 0x561e4a372e20 in clang::Sema::ActOnCondition(clang::Scope*, clang::SourceLocation, clang::Expr*, clang::Sema::ConditionKind, bool) third_party/llvm/llvm-project/clang/lib/Sema/SemaExpr.cpp:20363:26 llvm#43 0x561e49b5407d in clang::Parser::ParseCXXCondition(clang::ActionResult<clang::Stmt*, true>*, clang::SourceLocation, clang::Sema::ConditionKind, bool, clang::Parser::ForRangeInfo*, bool) third_party/llvm/llvm-project/clang/lib/Parse/ParseExprCXX.cpp:2204:20 llvm#44 0x561e49c000a8 in clang::Parser::ParseParenExprOrCondition(clang::ActionResult<clang::Stmt*, true>*, clang::Sema::ConditionResult&, clang::SourceLocation, clang::Sema::ConditionKind, clang::SourceLocation&, clang::SourceLocation&) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:1376:12 llvm#45 0x561e49bf6c2f in clang::Parser::ParseIfStatement(clang::SourceLocation*) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:1587:9 llvm#46 0x561e49bf2d6d in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::ParsedAttributes&, clang::ParsedAttributes&) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:325:12 llvm#47 0x561e49bf0a6e in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:125:20 llvm#48 0x561e49bff57d in clang::Parser::ParseCompoundStatementBody(bool) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:1267:11 llvm#49 0x561e49c0136e in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:2577:21 llvm#50 0x561e49afa4fd in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1520:10 llvm#51 0x561e49ba6e44 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) third_party/llvm/llvm-project/clang/lib/Parse/ParseDecl.cpp:2460:17 llvm#52 0x561e49af8746 in clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1244:10 llvm#53 0x561e49af79f8 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1266:12 llvm#54 0x561e49af5d96 in clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1069:14 llvm#55 0x561e49b6c42c in clang::Parser::ParseInnerNamespace(llvm::SmallVector<clang::Parser::InnerNamespaceInfo, 4u> const&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) third_party/llvm/llvm-project/clang/lib/Parse/ParseDeclCXX.cpp:276:7 llvm#56 0x561e49b6c5d7 in clang::Parser::ParseInnerNamespace(llvm::SmallVector<clang::Parser::InnerNamespaceInfo, 4u> const&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) third_party/llvm/llvm-project/clang/lib/Parse/ParseDeclCXX.cpp:298:3 llvm#57 0x561e49b6b7c3 in clang::Parser::ParseNamespace(clang::DeclaratorContext, clang::SourceLocation&, clang::SourceLocation) third_party/llvm/llvm-project/clang/lib/Parse/ParseDeclCXX.cpp:253:3 llvm#58 0x561e49ba337a in clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, clang::SourceLocation*) third_party/llvm/llvm-project/clang/lib/Parse/ParseDecl.cpp llvm#59 0x561e49af563a in clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:985:14 llvm#60 0x561e49af3779 in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:758:12 llvm#61 0x561e49aec6ae in clang::ParseAST(clang::Sema&, bool, bool) third_party/llvm/llvm-project/clang/lib/Parse/ParseAST.cpp:171:20 llvm#62 0x561e496f13ae in clang::ASTFrontendAction::ExecuteAction() third_party/llvm/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1191:3 llvm#63 0x561e496f0874 in clang::FrontendAction::Execute() third_party/llvm/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1077:8 llvm#64 0x561e49644511 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) third_party/llvm/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1062:33 llvm#65 0x561e47ffe1b9 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) third_party/llvm/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:296:25 llvm#66 0x561e47fee631 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) third_party/llvm/llvm-project/clang/tools/driver/cc1_main.cpp:286:15 llvm#67 0x561e47fe9912 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) third_party/llvm/llvm-project/clang/tools/driver/driver.cpp:218:12 llvm#68 0x561e47fec7e6 in operator() third_party/llvm/llvm-project/clang/tools/driver/driver.cpp:360:14 llvm#69 0x561e47fec7e6 in int llvm::function_ref<int (llvm::SmallVectorImpl<char const*>&)>::callback_fn<clang_main(int, char**, llvm::ToolContext const&)::$_0>(long, llvm::SmallVectorImpl<char const*>&) third_party/llvm/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:12 #70 0x561e498bc531 in operator() third_party/llvm/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:69:12 llvm#71 0x561e498bc531 in operator() third_party/llvm/llvm-project/clang/lib/Driver/Job.cpp:437:34 llvm#72 0x561e498bc531 in void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::__u::optional<llvm::StringRef>>, std::__u::basic_string<char, std::__u::char_traits<char>, std::__u::allocator<char>>*, bool*) const::$_0>(long) third_party/llvm/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:12 llvm#73 0x561e4ff969e8 in operator() third_party/llvm/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:69:12 llvm#74 0x561e4ff969e8 in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) third_party/llvm/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:426:3 llvm#75 0x561e498bb331 in clang::driver::CC1Command::Execute(llvm::ArrayRef<std::__u::optional<llvm::StringRef>>, std::__u::basic_string<char, std::__u::char_traits<char>, std::__u::allocator<char>>*, bool*) const third_party/llvm/llvm-project/clang/lib/Driver/Job.cpp:437:12 llvm#76 0x561e49860e38 in clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const third_party/llvm/llvm-project/clang/lib/Driver/Compilation.cpp:196:15 llvm#77 0x561e49861154 in clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::__u::pair<int, clang::driver::Command const*>>&, bool) const third_party/llvm/llvm-project/clang/lib/Driver/Compilation.cpp:250:19 llvm#78 0x561e49886037 in clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::__u::pair<int, clang::driver::Command const*>>&) third_party/llvm/llvm-project/clang/lib/Driver/Driver.cpp:1968:5 llvm#79 0x561e47fe8c7d in clang_main(int, char**, llvm::ToolContext const&) third_party/llvm/llvm-project/clang/tools/driver/driver.cpp:396:21 llvm#80 0x561e47fe6ae7 in main blaze-out/k8-opt-asan/bin/third_party/llvm/llvm-project/clang/clang-driver.cpp:17:10 llvm#81 0x7fb3f13c33d3 in __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x613d3) (BuildId: 9a996398ce14a94560b0c642eb4f6e94) llvm#82 0x561e47f0a229 in _start /usr/grte/v5/debug-src/src/csu/../sysdeps/x86_64/start.S:120 0x7c63f05a65b0 is located 48 bytes inside of 104-byte region [0x7c63f05a6580,0x7c63f05a65e8) freed by thread T0 here: #0 0x561e47fe5342 in operator delete(void*, unsigned long) third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:155:3 #1 0x561e4b4c2fcc in __libcpp_operator_delete<void *, unsigned long> third_party/crosstool/v18/stable/src/libcxx/include/new:286:3 #2 0x561e4b4c2fcc in __do_deallocate_handle_size<> third_party/crosstool/v18/stable/src/libcxx/include/new:310:10 llvm#3 0x561e4b4c2fcc in __libcpp_deallocate third_party/crosstool/v18/stable/src/libcxx/include/new:323:12 llvm#4 0x561e4b4c2fcc in deallocate third_party/crosstool/v18/stable/src/libcxx/include/__memory/allocator.h:135:7 llvm#5 0x561e4b4c2fcc in deallocate third_party/crosstool/v18/stable/src/libcxx/include/__memory/allocator_traits.h:313:9 llvm#6 0x561e4b4c2fcc in std::__u::__tree<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::__map_value_compare<std::__u::pair<void const*, unsigned int>, std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::less<std::__u::pair<void const*, unsigned int>>, true>, std::__u::allocator<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>>>::destroy(std::__u::__tree_node<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, void*>*) third_party/crosstool/v18/stable/src/libcxx/include/__tree:1549:5 llvm#7 0x561e4b400340 in ~__tree third_party/crosstool/v18/stable/src/libcxx/include/__tree:1539:3 llvm#8 0x561e4b400340 in ~map third_party/crosstool/v18/stable/src/libcxx/include/map:1138:112 llvm#9 0x561e4b400340 in (anonymous namespace)::CallStackFrame::~CallStackFrame() third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1524:1 llvm#10 0x561e4b49697b in HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, (anonymous namespace)::CallRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6742:1 llvm#11 0x561e4b400cca in HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, llvm::ArrayRef<clang::Expr const*>, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6753:10 llvm#12 0x561e4b45cfae in (anonymous namespace)::RecordExprEvaluator::VisitCXXConstructExpr(clang::CXXConstructExpr const*, clang::QualType) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:10792:10 llvm#13 0x561e4b45dae7 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::RecordExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#14 0x561e4b3f963e in EvaluateRecord third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:10917:50 llvm#15 0x561e4b3f963e in EvaluateInPlace(clang::APValue&, (anonymous namespace)::EvalInfo&, (anonymous namespace)::LValue const&, clang::Expr const*, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16425:14 llvm#16 0x561e4b3ff0b3 in EvaluateCallArg(clang::ParmVarDecl const*, clang::Expr const*, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6403:8 llvm#17 0x561e4b440530 in EvaluateArgs(llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, clang::FunctionDecl const*, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6442:10 llvm#18 0x561e4b4a503e in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8298:12 llvm#19 0x561e4b4a503e in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#20 0x561e4b4a503e in (anonymous namespace)::IntExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:12700:33 llvm#21 0x561e4b49f1a5 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h llvm#22 0x561e4b3ff8af in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16339:41 llvm#23 0x561e4b424658 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#24 0x561e4b424658 in EvaluateCond((anonymous namespace)::EvalInfo&, clang::VarDecl const*, clang::Expr const*, bool&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5182:8 llvm#25 0x561e4b41ea8c in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5555:17 llvm#26 0x561e4b423755 in EvaluateLoopBody((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5221:24 llvm#27 0x561e4b41d597 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5635:28 llvm#28 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#29 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#30 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#31 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#32 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#33 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#34 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#35 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#36 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#37 0x561e4b41f204 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5511:17 llvm#38 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#39 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#40 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#41 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#42 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#43 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#44 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#45 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#46 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#47 0x561e4b4ad3c2 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#48 0x561e4b4ad3c2 in (anonymous namespace)::IntExprEvaluator::VisitCastExpr(clang::CastExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:14877:10 llvm#49 0x561e4b49f192 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h previously allocated by thread T0 here: #0 0x561e47fe46bd in operator new(unsigned long) third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:86:3 #1 0x561e4b424d00 in __libcpp_operator_new<unsigned long> third_party/crosstool/v18/stable/src/libcxx/include/new:277:10 #2 0x561e4b424d00 in __libcpp_allocate third_party/crosstool/v18/stable/src/libcxx/include/new:301:10 llvm#3 0x561e4b424d00 in allocate third_party/crosstool/v18/stable/src/libcxx/include/__memory/allocator.h:120:32 llvm#4 0x561e4b424d00 in allocate third_party/crosstool/v18/stable/src/libcxx/include/__memory/allocator_traits.h:281:16 llvm#5 0x561e4b424d00 in __construct_node<const std::__u::piecewise_construct_t &, std::__u::tuple<std::__u::pair<const void *, unsigned int> &&>, std::__u::tuple<> > third_party/crosstool/v18/stable/src/libcxx/include/__tree:1820:21 llvm#6 0x561e4b424d00 in std::__u::pair<std::__u::__tree_iterator<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::__tree_node<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, void*>*, long>, bool> std::__u::__tree<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::__map_value_compare<std::__u::pair<void const*, unsigned int>, std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::less<std::__u::pair<void const*, unsigned int>>, true>, std::__u::allocator<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>>>::__emplace_unique_key_args<std::__u::pair<void const*, unsigned int>, std::__u::piecewise_construct_t const&, std::__u::tuple<std::__u::pair<void const*, unsigned int>&&>, std::__u::tuple<>>(std::__u::pair<void const*, unsigned int> const&, std::__u::piecewise_construct_t const&, std::__u::tuple<std::__u::pair<void const*, unsigned int>&&>&&, std::__u::tuple<>&&) third_party/crosstool/v18/stable/src/libcxx/include/__tree:1787:25 llvm#7 0x561e4b424a03 in operator[] third_party/crosstool/v18/stable/src/libcxx/include/map:1531:8 llvm#8 0x561e4b424a03 in (anonymous namespace)::CallStackFrame::createLocal(clang::APValue::LValueBase, void const*, clang::QualType, (anonymous namespace)::ScopeKind) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1963:21 llvm#9 0x561e4b42bd95 in clang::APValue& (anonymous namespace)::CallStackFrame::createTemporary<clang::Expr>(clang::Expr const*, clang::QualType, (anonymous namespace)::ScopeKind, (anonymous namespace)::LValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1944:10 llvm#10 0x561e4b3ffd17 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16367:27 llvm#11 0x561e4b40429c in handleLValueToRValueConversion((anonymous namespace)::EvalInfo&, clang::Expr const*, clang::QualType, (anonymous namespace)::LValue const&, clang::APValue&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:4518:12 llvm#12 0x561e4b496e9c in handleTrivialCopy((anonymous namespace)::EvalInfo&, clang::ParmVarDecl const*, clang::Expr const*, clang::APValue&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6469:10 llvm#13 0x561e4b494fdd in HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, (anonymous namespace)::CallRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6582:12 llvm#14 0x561e4b400cca in HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, llvm::ArrayRef<clang::Expr const*>, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6753:10 llvm#15 0x561e4b45cfae in (anonymous namespace)::RecordExprEvaluator::VisitCXXConstructExpr(clang::CXXConstructExpr const*, clang::QualType) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:10792:10 llvm#16 0x561e4b45dae7 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::RecordExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#17 0x561e4b3f963e in EvaluateRecord third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:10917:50 llvm#18 0x561e4b3f963e in EvaluateInPlace(clang::APValue&, (anonymous namespace)::EvalInfo&, (anonymous namespace)::LValue const&, clang::Expr const*, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16425:14 llvm#19 0x561e4b3ff0b3 in EvaluateCallArg(clang::ParmVarDecl const*, clang::Expr const*, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6403:8 llvm#20 0x561e4b440530 in EvaluateArgs(llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, clang::FunctionDecl const*, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6442:10 llvm#21 0x561e4b4a503e in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8298:12 llvm#22 0x561e4b4a503e in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#23 0x561e4b4a503e in (anonymous namespace)::IntExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:12700:33 llvm#24 0x561e4b49f1a5 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h llvm#25 0x561e4b3ff8af in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16339:41 llvm#26 0x561e4b424658 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#27 0x561e4b424658 in EvaluateCond((anonymous namespace)::EvalInfo&, clang::VarDecl const*, clang::Expr const*, bool&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5182:8 llvm#28 0x561e4b41ea8c in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5555:17 llvm#29 0x561e4b423755 in EvaluateLoopBody((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5221:24 llvm#30 0x561e4b41d597 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5635:28 llvm#31 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#32 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#33 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#34 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#35 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#36 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#37 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#38 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#39 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#40 0x561e4b41f204 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5511:17 llvm#41 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#42 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#43 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#44 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#45 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#46 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 ```
kadircet
pushed a commit
that referenced
this pull request
Dec 6, 2024
…ne symbol size as symbols are created (llvm#117079)" This reverts commit ba668eb. Below test started failing again on x86_64 macOS CI. We're unsure if this patch is the exact cause, but since this patch has broken this test before, we speculatively revert it to see if it was indeed the root cause. ``` FAIL: lldb-shell :: Unwind/trap_frame_sym_ctx.test (1692 of 2162) ******************** TEST 'lldb-shell :: Unwind/trap_frame_sym_ctx.test' FAILED ******************** Exit Code: 1 Command Output (stderr): -- RUN: at line 7: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/clang --target=specify-a-target-or-use-a-_host-substitution --target=x86_64-apple-darwin22.6.0 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -fmodules-cache-path=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/call-asm.c /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/trap_frame_sym_ctx.s -o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp + /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/clang --target=specify-a-target-or-use-a-_host-substitution --target=x86_64-apple-darwin22.6.0 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -fmodules-cache-path=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/call-asm.c /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/trap_frame_sym_ctx.s -o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp clang: warning: argument unused during compilation: '-fmodules-cache-path=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell' [-Wunused-command-line-argument] RUN: at line 8: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/lldb --no-lldbinit -S /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/lit-lldb-init-quiet /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp -s /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test -o exit | /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/FileCheck /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test + /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/lldb --no-lldbinit -S /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/lit-lldb-init-quiet /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp -s /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test -o exit + /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/FileCheck /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test:21:10: error: CHECK: expected string not found in input ^ <stdin>:26:64: note: scanning from here frame #1: 0x0000000100003ee9 trap_frame_sym_ctx.test.tmp`tramp ^ <stdin>:27:2: note: possible intended match here frame #2: 0x00007ff7bfeff6c0 ^ Input file: <stdin> Check file: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test -dump-input=help explains the following input dump. Input was: <<<<<< . . . 21: 0x100003ed1 <+0>: pushq %rbp 22: 0x100003ed2 <+1>: movq %rsp, %rbp 23: (lldb) thread backtrace -u 24: * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 25: * frame #0: 0x0000000100003ecc trap_frame_sym_ctx.test.tmp`bar 26: frame #1: 0x0000000100003ee9 trap_frame_sym_ctx.test.tmp`tramp check:21'0 X error: no match found 27: frame #2: 0x00007ff7bfeff6c0 check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check:21'1 ? possible intended match 28: frame llvm#3: 0x0000000100003ec6 trap_frame_sym_ctx.test.tmp`main + 22 check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 29: frame llvm#4: 0x0000000100003ec6 trap_frame_sym_ctx.test.tmp`main + 22 check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 30: frame llvm#5: 0x00007ff8193cc41f dyld`start + 1903 check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 31: (lldb) exit check:21'0 ~~~~~~~~~~~~ >>>>>> ```
kadircet
pushed a commit
that referenced
this pull request
Dec 6, 2024
## Description This PR fixes a segmentation fault that occurs when passing options requiring arguments via `-Xopenmp-target=<triple>`. The issue was that the function `Driver::getOffloadArchs` did not properly parse the extracted option, but instead assumed it was valid, leading to a crash when incomplete arguments were provided. ## Backtrace ```sh llvm-project/build/bin/clang++ main.cpp -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target=powerpc64le-ibm-linux-gnu -o PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: llvm-project/build/bin/clang++ main.cpp -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target=powerpc64le-ibm-linux-gnu -o 1. Compilation construction 2. Building compilation actions #0 0x0000562fb21c363b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (llvm-project/build/bin/clang+++0x392f63b) #1 0x0000562fb21c0e3c SignalHandler(int) Signals.cpp:0:0 #2 0x00007fcbf6c81420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) llvm#3 0x0000562fb1fa5d70 llvm::opt::Option::matches(llvm::opt::OptSpecifier) const (llvm-project/build/bin/clang+++0x3711d70) llvm#4 0x0000562fb2a78e7d clang::driver::Driver::getOffloadArchs(clang::driver::Compilation&, llvm::opt::DerivedArgList const&, clang::driver::Action::OffloadKind, clang::driver::ToolChain const*, bool) const (llvm-project/build/bin/clang+++0x41e4e7d) llvm#5 0x0000562fb2a7a9aa clang::driver::Driver::BuildOffloadingActions(clang::driver::Compilation&, llvm::opt::DerivedArgList&, std::pair<clang::driver::types::ID, llvm::opt::Arg const*> const&, clang::driver::Action*) const (.part.1164) Driver.cpp:0:0 llvm#6 0x0000562fb2a7c093 clang::driver::Driver::BuildActions(clang::driver::Compilation&, llvm::opt::DerivedArgList&, llvm::SmallVector<std::pair<clang::driver::types::ID, llvm::opt::Arg const*>, 16u> const&, llvm::SmallVector<clang::driver::Action*, 3u>&) const (llvm-project/build/bin/clang+++0x41e8093) llvm#7 0x0000562fb2a8395d clang::driver::Driver::BuildCompilation(llvm::ArrayRef<char const*>) (llvm-project/build/bin/clang+++0x41ef95d) llvm#8 0x0000562faf92684c clang_main(int, char**, llvm::ToolContext const&) (llvm-project/build/bin/clang+++0x109284c) llvm#9 0x0000562faf826cc6 main (llvm-project/build/bin/clang+++0xf92cc6) llvm#10 0x00007fcbf6699083 __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:342:3 llvm#11 0x0000562faf923a5e _start (llvm-project/build/bin/clang+++0x108fa5e) [1] 2628042 segmentation fault (core dumped) main.cpp -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -o ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.