Skip to content
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
wants to merge 26 commits into from

Conversation

kadircet
Copy link
Owner

@kadircet kadircet commented Sep 6, 2023

No description provided.

gysit and others added 26 commits September 6, 2023 08:58
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
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.
@kadircet kadircet force-pushed the no_sharding_clangd branch 2 times, most recently from 6270821 to d71adeb Compare September 6, 2023 12:00
@kadircet kadircet closed this Sep 11, 2023
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.