Add memcpm test #13
Closed
Add memcpm test #13
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Code Object V2 has been deprecated for more than a year now. We can safely remove it from LLVM. - [clang] Remove support for the `-mcode-object-version=2` option. - [lld] Remove/refactor tests that were still using COV2 - [llvm] Update AMDGPUUsage.rst - Code Object V2 docs are left for informational purposes because those code objects may still be supported by the runtime/loaders for a while. - [AMDGPU] Remove COV2 emission capabilities. - [AMDGPU] Remove `MetadataStreamerYamlV2` which was only used by COV2 - [AMDGPU] Update all tests that were still using COV2 - They are either deleted or ported directly to code object v4 (as v3 is also planned to be removed soon).
Now that VPInstruction can manage fast math flags via VPRecipeWithIRFlags, use them directly to model the fast-math flags of the select created for the final reduction value instead of adding them late.
One big issue with DirectXShaderCompiler was test coverage: DXIL and SPIR-V backends had their own tests. When a bug was found in one, the other wasn't always checked. This lead to unequal support of HLSL for both backends. We'd like to avoid those issues here, hence the test-sharing. By default, all the tests in this folder are marked as requiring DirectX. But as SPIR-V support grows, each test drop this requirement, and check the SPIR-V behavior. I would have preferred to mark new tests as XFAIL for SPIR-V by default, so we could differentiate real unsupported tests (as SPIR-V has no equivalent), from newly added tests. But the way LIT is built, I don't think this is possible. --------- Signed-off-by: Nathan Gauër <brioche@google.com>
This transform has caused a few issues with operations that can naturally be extended. This patch just adds a debug option for disabling the transform, useful for testing cases where it might not be profitable.
…based Code Coverage (1/3)" This seems to cause Clang to crash, see comments on the code review. Reverting until the problem can be investigated. > Part 1 of 3. This includes the LLVM back-end processing and profile > reading/writing components. compiler-rt changes are included. > > Differential Revision: https://reviews.llvm.org/D138846 This reverts commit a50486f.
This has been deprecated in favor of CMake's CMAKE_MSVC_RUNTIME_LIBRARY in c6bd873 . Current release branch still contains it in deprecated status so no existing end-users will be affected.
…6308)" This reverts commit a7b78ca. With updates to the tests. TestWatchTaggedAddress.py: Updated the expected watchpoint types, though I'm not sure there should be a differnt default for the two ways of setting them, that needs to be confirmed. TestStepOverWatchpoint.py: Skipped this everywhere because I think what used to happen is you couldn't put 2 watchpoints on the same address (after alignment). I guess that this is now allowed because modify watchpoints aren't accounted for, but likely should be. Needs investigating.
…llvm#66213) Support for SPIRV added, updated test SPV_INTEL_optnone.ll using the script. Previously https://reviews.llvm.org/D157858
Don't generate enums from the main VectorOps.td file as that transitively includes enums from Arith. --------- Co-authored-by: Nicolas Vasilache <ntv@google.com>
…))) -> (assertzext x) fold Noticed on D159533 and I've finally deal with the x86 regressions - MatchingStackOffset wasn't peeking through AssertZext nodes while trying to find CopyFromReg/Load sources, it was only removing them if they were part of a (trunc (assertzext x)) pattern.
Precommit test ahead of https://reviews.llvm.org/D159533 for ISD::FSHR / AMDGPUISD::PERM combine
In order to reduce noise for a MR.
… compiler To get the bot back to green as we figure out how to handle piping data into a test running behind a SSH executor.
The wide stream tests should be marked as `UNSUPPORTED: no-wide-characters`, not XFAIL.
Check isSafeToExpand() before expanding the exit count. Otherwise we may incorrectly speculate a udiv. Fixes llvm#66986.
This adds the ability to read streaming SVE registers, ZA, SVCR and SVG from core files. Streaming SVE is in a new note NT_ARM_SSVE but otherwise has the same format as SVE. So I've done the same as I did for live processes and reused the existing SVE state with an extra state for the mode variable. ZA is in a note NT_ARM_ZA and again the handling matches live processes. Except that it gets setup only once. A disabled ZA reads as 0s as usual. SVCR and SVG are pseudo registers, generated from the notes. An important detail is that the notes represent what you would have got if you read from ptrace at the time of the crash. This means that for a corefile in non-streaming mode, there is still an NT_ARM_SSVE note and we check the header flags to tell if it is active. We cannot just say if you have the note you're in streaming mode. The kernel does not provide register values for the inactive mode and even if it did, they would be undefined, so if we find streaming state, we ignore the non-streaming state. Same for ZA, a disabled ZA still has the header in the note. The tests do not cover all combinations but enough different vector lengths, modes and ZA states to be confident. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D158500
Old iterator is invalidated upon SmallVector elements additions. Stores index instead of iterator to avoid this. Fixes llvm#66938 PR: llvm#66954
…electionDAG" This reverts commit fb8f591 and b8e9450. Due to test suite failures on AArch64: https://lab.llvm.org/buildbot/#/builders/183/builds/16057
Derived-type-spec (such as `type(t)`) typically cause the instantiation
of a class which is also used to define the offsets of its data
components and the size of the class.
Fortran derived types are always "completely" defined (i.e., no
incomplete / opaque derived types exist on which we can build a pointer
to them like in C/C++) so they can have their offsets always computed.
However, we must be careful not to instantiate a derived type while it
is being defined. This can happen due to cycles introduced by forward
references, such as the one below.
```lang=fortran
type t1
type(t2), pointer :: b ! (A)
end type t1
type :: t2 ! (B)
type(t1), pointer :: a ! (C)
end type t2 ! (D)
```
At `(A)`, flang determines that this is a forward declaration so no
instantiation happens.
At `(B)`, flang determines `t2` is not a forward declaration anymore,
because we are defining it.
At `(C)`, flang chooses to instantiate `t1`. Instantiation of `t1` finds
the field `b` at `(A)`. Now `t2` is not a forward declaration anymore,
so it can be instantiated. But at this point the field `a` has not been
added to `t2`, so we compute the size of an empty class. Because this
computation is done just once, we end emitting a wrong derived type
descriptor with a `sizeinbytes` field set to 0.
Because these kind of cycles can only happen via forward referenced
derived types specifiers, the idea here is to avoid instantiating the
derived type being defined (i.e. `t2`) until `(D)`. Keeping the
attribute "is forward reference" set until `(D)` avoids that.
Fixes llvm#64973
Differential Revision: https://reviews.llvm.org/D159117
This reverts commit 43812c8. Due to failures on x86_64: https://lab.llvm.org/buildbot/#/builders/68/builds/60416
…lvm#65997) Similar to llvm#65598, if we're using a vslideup to insert a fixed length vector into another vector, then we can work out the minimum number of registers it will need to slide up across given the minimum VLEN, and shrink the type operated on to reduce LMUL accordingly. This is somewhat dependent on llvm#66211 , since it introduces a subregister copy that triggers a crash with -early-live-intervals in one of the tests. Stacked upon llvm#66211
expandCodeFor() was directly calling expandCodeForImpl(). Drop the Impl variant.
This option has been superseded by the fixpoint verification functionality.
…ctorize_children_and...}. (llvm#66575) This PR renames the vectorization transform ops as follows: * `structured.masked_vectorize` => `structured.vectorize`. This reflects the fact that since [recently](https://reviews.llvm.org/D157774) the op can also handle the unmasked case. * `structured.vectorize` => `structured.vectorize_children_and_applies_patterns`. This reflects the fact that the op does not just vectorize the given payload op but all vectorizable children contained in it, and applies patterns before and after for preparation and clean-up. This rename was discussed first [here](https://reviews.llvm.org/D157774). The PR also adapts and cleans ups the tablegen description of the `VectorizeChildrenAndApplyPatternsOp` (formerly `VectorizeOp`).
This code is only for riscv, but use the CHECK macro to avoid unused parameters problems if assert is not defined.
The AMDGPU backend now has buffer resource intrinsics that take a ptr addrspase (8) instead of a vector<4xi32>, improving LLVM's ability to reason about their memory behavior. This commit moves MLIR to these new functions. Reviewed By: jsjodin Differential Revision: https://reviews.llvm.org/D157053
In a previous patch, the printf writer was rewritten to use a single writer class with a buffer and a callback hook. This patch refactors scanf's reader to match conceptually.
The formula I added to LoopRotationUtils does not produce reasonable results if some of the branch weights are zero. Add special case handling for this. This fixes llvm#66675
Add the command line option --no-trap-after-noreturn, which exposes the pre-existing TargetOption `NoTrapAfterNoreturn`. This pull request was split off from this one: llvm#65876
Bitwise logical ops can always be done as b32, regardless of availability of other v2i16 ops, that would need a new GPU.
Some tests were passing invalid IR to the VPlan construction logic. Fix the invalid IR and run the verifier on the input to avoid issues in the future.
Originally suggested in https://reviews.llvm.org/D131001 but I accidentally took only have of the suggestion.
This uses a naive lowering for G_BRCOND to a BNE instruction comparing the register to X0.
Header phi recipes have the start value (incoming from outside the loop) as first operand. This wasn't the case for VPWidenPHIRecipes. Instead the start value was picked during execute() by doing extra work. To be in line with other recipes, ensure the operand order is as expected during construction.
This implements the [[msvc::no_unique_address]] attribute. There is not ABI compatibility in this patch because the attribute is relatively new and there's still some uncertainty in the MSVC version. Bug: llvm#49358 Also see https://reviews.llvm.org/D157762.
b1e3cd1 dropped the leading slash here, presumably unintentionally. (I don't understand Driver well enough to know how/where this is supposed to be tested, but it broke clangd on any project that uses the system-installed -stdlib=libc++ on a standard debian install)
This problem was accidentally discovered by the internal symbolizer, but it's relevant for external one as well, see the test. If we just disable tagging, there may still be tagged allocations that have already been freed. After disabling tagging, these tagged allocations can be released to the user as-is, which would later break the "invalid-free" check. We cannot just disable the "invalid-free" check with disabled tagging, because if we re-enable tagging, the issue still applies to allocations created when it was disabled. The fix is to continue tagging with zero even if tagging is disabled. This makes the "disabled" mode less efficient, but this is not the primary use case.
…ions (llvm#67179) These are not supported by the backend. The comment that got deleted was out of place, and it exists in the call sites of this function.
I'd guarded this case in D158874 to avoid regressions, and decided to go investigate what was going on. The solution turns out to be a generic splat matching extension to handle INSERT_SUBVECTOR. In theory, we could see these from other sources as well, but for some reason we only seem to see the i64 extract on rv32 case in practice. Not sure why that is to be honest. Differential Revision: https://reviews.llvm.org/D159230
…lvm#66731) This PR makes `-basic-block-sections` handle functions with custom non-dot-text sections correctly. Cold parts of such functions must be placed in the same section (not in `.text.split`) but with a unique id.
Previous change in llvm#65675 broke the docs generation.
)" This reverts commit 44f2db7. It caused ``` error: Record `NoUniqueAddress', field `Documentation' exists but does not have a list value ```
llvm@057fc8e Introduces a bug in the `TosaInferShapesPass` when an operand type was already inferred. https://github.com/llvm/llvm-project/blob/f7bfa583b7a5ff0e9954d2810006b7a71123be88/mlir/include/mlir/Interfaces/InferTypeOpInterface.td#L248 interprets the `ValueShapeRange` as a normal `ValueRange` and looses the information of the inference. This PR changes the logic of the shape inference a bit. Instead of saving the type information in a `DenseMap` and updating the types after the whole analysis for a region, it now updates the types directly in each iteration. That way the operands always have the inferred type.
``` /build/source/llvm/docs/Coroutines.rst:1781: CRITICAL: Title level inconsistent: '``coro.outside.frame``' Metadata ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ```
While looking into reducing needless interdependencies between upstream MLIR dialects and passes, I discovered that the ROCDL Dialect redundantely uses links in `VectorToLLVM` conversion pass when it actually requires just the LLVM Dialect. Furthermore, after a build failure, I ran `ninja -t missingdeps` which revealed that the NVVM Dialect depends on headers of the GPU dialect (https://github.com/llvm/llvm-project/blob/211c9752c8200fbb3ff7be1f6aa98037901758ce/mlir/include/mlir/Dialect/LLVMIR/NVVMDialect.h#L18) without stating so in CMake. This causes flaky builds as it is not guaranteed that the header exists prior to the dialect being compiled.
This reverts commit 4a55d42. Reverting because this breaks sphinx documentation, and even with it fixed the format of the attribute makes the no_unique_address documentation show up twice.
And merge them with demangle_internal.cpp.
Instead of passing everything off to GCC, add a ToolChain for Haiku to allow Clang to properly link things on its own. Co-authored-by: X512 <danger_mail@list.ru> Co-authored-by: David Karoly <david.karoly@outlook.com>
Note the new surface syntax allows for defining a dimToLvl and lvlToDim map at once (where usually the latter can be inferred from the former, but not always). This revision adds storage for the latter, together with some intial boilerplate. The actual support (inference, validation, printing, etc.) is still TBD of course.
kstoimenov
pushed a commit
that referenced
this pull request
Nov 3, 2023
…tePluginObject After llvm#68052 this function changed from returning a nullptr with `return {};` to returning Expected and hitting `llvm_unreachable` before it could do so. I gather that we're never supposed to call this function, but on Windows we actually do call this function because `interpreter->CreateScriptedProcessInterface()` returns `ScriptedProcessInterface` not `ScriptedProcessPythonInterface`. Likely because `target_sp->GetDebugger().GetScriptInterpreter()` also does not return a Python related class. The previously XFAILed test crashed with: ``` # .---command stderr------------ # | PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. # | Stack dump: # | 0. Program arguments: c:\\users\\tcwg\\david.spickett\\build-llvm\\bin\\lldb-test.exe ir-memory-map C:\\Users\\tcwg\\david.spickett\\build-llvm\\tools\\lldb\\test\\Shell\\Expr\\Output\\TestIRMemoryMapWindows.test.tmp C:\\Users\\tcwg\\david.spickett\\llvm-project\\lldb\\test\\Shell\\Expr/Inputs/ir-memory-map-basic # | 1. HandleCommand(command = "run") # | Exception Code: 0xC000001D # | #0 0x00007ff696b5f588 lldb_private::ScriptedProcessInterface::CreatePluginObject(class llvm::StringRef, class lldb_private::ExecutionContext &, class std::shared_ptr<class lldb_private::StructuredData::Dictionary>, class lldb_private::StructuredData::Generic *) C:\Users\tcwg\david.spickett\llvm-project\lldb\include\lldb\Interpreter\Interfaces\ScriptedProcessInterface.h:28:0 # | #1 0x00007ff696b1d808 llvm::Expected<std::shared_ptr<lldb_private::StructuredData::Generic> >::operator bool C:\Users\tcwg\david.spickett\llvm-project\llvm\include\llvm\Support\Error.h:567:0 # | #2 0x00007ff696b1d808 lldb_private::ScriptedProcess::ScriptedProcess(class std::shared_ptr<class lldb_private::Target>, class std::shared_ptr<class lldb_private::Listener>, class lldb_private::ScriptedMetadata const &, class lldb_private::Status &) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Plugins\Process\scripted\ScriptedProcess.cpp:115:0 # | #3 0x00007ff696b1d124 std::shared_ptr<lldb_private::ScriptedProcess>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1478:0 # | #4 0x00007ff696b1d124 lldb_private::ScriptedProcess::CreateInstance(class std::shared_ptr<class lldb_private::Target>, class std::shared_ptr<class lldb_private::Listener>, class lldb_private::FileSpec const *, bool) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Plugins\Process\scripted\ScriptedProcess.cpp:61:0 # | #5 0x00007ff69699c8f4 std::_Ptr_base<lldb_private::Process>::_Move_construct_from C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1237:0 # | #6 0x00007ff69699c8f4 std::shared_ptr<lldb_private::Process>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1534:0 # | #7 0x00007ff69699c8f4 std::shared_ptr<lldb_private::Process>::operator= C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1594:0 # | #8 0x00007ff69699c8f4 lldb_private::Process::FindPlugin(class std::shared_ptr<class lldb_private::Target>, class llvm::StringRef, class std::shared_ptr<class lldb_private::Listener>, class lldb_private::FileSpec const *, bool) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Target\Process.cpp:396:0 # | #9 0x00007ff6969bd708 std::_Ptr_base<lldb_private::Process>::_Move_construct_from C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1237:0 # | #10 0x00007ff6969bd708 std::shared_ptr<lldb_private::Process>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1534:0 # | #11 0x00007ff6969bd708 std::shared_ptr<lldb_private::Process>::operator= C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1594:0 # | #12 0x00007ff6969bd708 lldb_private::Target::CreateProcess(class std::shared_ptr<class lldb_private::Listener>, class llvm::StringRef, class lldb_private::FileSpec const *, bool) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Target\Target.cpp:215:0 # | #13 0x00007ff696b13af0 std::_Ptr_base<lldb_private::Process>::_Ptr_base C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1230:0 # | llvm#14 0x00007ff696b13af0 std::shared_ptr<lldb_private::Process>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1524:0 # | llvm#15 0x00007ff696b13af0 lldb_private::PlatformWindows::DebugProcess(class lldb_private::ProcessLaunchInfo &, class lldb_private::Debugger &, class lldb_private::Target &, class lldb_private::Status &) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Plugins\Platform\Windows\PlatformWindows.cpp:495:0 # | llvm#16 0x00007ff6969cf590 std::_Ptr_base<lldb_private::Process>::_Move_construct_from C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1237:0 # | llvm#17 0x00007ff6969cf590 std::shared_ptr<lldb_private::Process>::shared_ptr C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1534:0 # | llvm#18 0x00007ff6969cf590 std::shared_ptr<lldb_private::Process>::operator= C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\include\memory:1594:0 # | llvm#19 0x00007ff6969cf590 lldb_private::Target::Launch(class lldb_private::ProcessLaunchInfo &, class lldb_private::Stream *) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Target\Target.cpp:3274:0 # | llvm#20 0x00007ff696fff82c CommandObjectProcessLaunch::DoExecute(class lldb_private::Args &, class lldb_private::CommandReturnObject &) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Commands\CommandObjectProcess.cpp:258:0 # | llvm#21 0x00007ff696fab6c0 lldb_private::CommandObjectParsed::Execute(char const *, class lldb_private::CommandReturnObject &) C:\Users\tcwg\david.spickett\llvm-project\lldb\source\Interpreter\CommandObject.cpp:751:0 # `----------------------------- # error: command failed with exit status: 0xc000001d ``` That might be a bug on the Windows side, or an artifact of how our build is setup, but whatever it is, having `CreatePluginObject` return an error and the caller check it, fixes the failing test. The built lldb can run the script command to use Python, but I'm not sure if that means anything.
kstoimenov
pushed a commit
that referenced
this pull request
Feb 23, 2024
…lvm#80904)" This reverts commit b1ac052. This commit breaks coroutine splitting for non-swift calling convention functions. In this example: ```ll ; ModuleID = 'repro.ll' source_filename = "stdlib/test/runtime/test_llcl.mojo" target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @0 = internal constant { i32, i32 } { i32 trunc (i64 sub (i64 ptrtoint (ptr @craSH to i64), i64 ptrtoint (ptr getelementptr inbounds ({ i32, i32 }, ptr @0, i32 0, i32 1) to i64)) to i32), i32 64 } define dso_local void @af_suspend_fn(ptr %0, i64 %1, ptr %2) #0 { ret void } define dso_local void @craSH(ptr %0) #0 { %2 = call token @llvm.coro.id.async(i32 64, i32 8, i32 0, ptr @0) %3 = call ptr @llvm.coro.begin(token %2, ptr null) %4 = getelementptr inbounds { ptr, { ptr, ptr }, i64, { ptr, i1 }, i64, i64 }, ptr poison, i32 0, i32 0 %5 = call ptr @llvm.coro.async.resume() store ptr %5, ptr %4, align 8 %6 = call { ptr, ptr, ptr } (i32, ptr, ptr, ...) @llvm.coro.suspend.async.sl_p0p0p0s(i32 0, ptr %5, ptr @ctxt_proj_fn, ptr @af_suspend_fn, ptr poison, i64 -1, ptr poison) ret void } define dso_local ptr @ctxt_proj_fn(ptr %0) #0 { ret ptr %0 } ; Function Attrs: nomerge nounwind declare { ptr, ptr, ptr } @llvm.coro.suspend.async.sl_p0p0p0s(i32, ptr, ptr, ...) #1 ; Function Attrs: nounwind declare token @llvm.coro.id.async(i32, i32, i32, ptr) #2 ; Function Attrs: nounwind declare ptr @llvm.coro.begin(token, ptr writeonly) #2 ; Function Attrs: nomerge nounwind declare ptr @llvm.coro.async.resume() #1 attributes #0 = { "target-features"="+adx,+aes,+avx,+avx2,+bmi,+bmi2,+clflushopt,+clwb,+clzero,+crc32,+cx16,+cx8,+f16c,+fma,+fsgsbase,+fxsr,+invpcid,+lzcnt,+mmx,+movbe,+mwaitx,+pclmul,+pku,+popcnt,+prfchw,+rdpid,+rdpru,+rdrnd,+rdseed,+sahf,+sha,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+sse4a,+ssse3,+vaes,+vpclmulqdq,+wbnoinvd,+x87,+xsave,+xsavec,+xsaveopt,+xsaves" } attributes #1 = { nomerge nounwind } attributes #2 = { nounwind } ``` This verifier crashes after the `coro-split` pass with ``` cannot guarantee tail call due to mismatched parameter counts musttail call void @af_suspend_fn(ptr poison, i64 -1, ptr poison) LLVM ERROR: Broken function PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: opt ../../../reduced.ll -O0 #0 0x00007f1d89645c0e __interceptor_backtrace.part.0 /build/gcc-11-XeT9lY/gcc-11-11.4.0/build/x86_64-linux-gnu/libsanitizer/asan/../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4193:28 #1 0x0000556d94d254f7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:22 #2 0x0000556d94d19a2f llvm::sys::RunSignalHandlers() /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/Signals.cpp:105:20 #3 0x0000556d94d1aa42 SignalHandler(int) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/Unix/Signals.inc:371:36 #4 0x00007f1d88e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #5 0x00007f1d88e969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #6 0x00007f1d88e969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10 #7 0x00007f1d88e969fc pthread_kill ./nptl/pthread_kill.c:89:10 #8 0x00007f1d88e42476 gsignal ./signal/../sysdeps/posix/raise.c:27:6 #9 0x00007f1d88e287f3 abort ./stdlib/abort.c:81:7 #10 0x0000556d8944be01 std::vector<llvm::json::Value, std::allocator<llvm::json::Value>>::size() const /usr/include/c++/11/bits/stl_vector.h:919:40 #11 0x0000556d8944be01 bool std::operator==<llvm::json::Value, std::allocator<llvm::json::Value>>(std::vector<llvm::json::Value, std::allocator<llvm::json::Value>> const&, std::vector<llvm::json::Value, std::allocator<llvm::json::Value>> const&) /usr/include/c++/11/bits/stl_vector.h:1893:23 #12 0x0000556d8944be01 llvm::json::operator==(llvm::json::Array const&, llvm::json::Array const&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/Support/JSON.h:572:69 #13 0x0000556d8944be01 llvm::json::operator==(llvm::json::Value const&, llvm::json::Value const&) (.cold) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/JSON.cpp:204:28 llvm#14 0x0000556d949ed2bd llvm::report_fatal_error(char const*, bool) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/ErrorHandling.cpp:82:70 llvm#15 0x0000556d8e37e876 llvm::SmallVectorBase<unsigned int>::size() const /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallVector.h:91:32 llvm#16 0x0000556d8e37e876 llvm::SmallVectorTemplateCommon<llvm::DiagnosticInfoOptimizationBase::Argument, void>::end() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallVector.h:282:41 llvm#17 0x0000556d8e37e876 llvm::SmallVector<llvm::DiagnosticInfoOptimizationBase::Argument, 4u>::~SmallVector() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallVector.h:1215:24 llvm#18 0x0000556d8e37e876 llvm::DiagnosticInfoOptimizationBase::~DiagnosticInfoOptimizationBase() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/DiagnosticInfo.h:413:7 llvm#19 0x0000556d8e37e876 llvm::DiagnosticInfoIROptimization::~DiagnosticInfoIROptimization() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/DiagnosticInfo.h:622:7 llvm#20 0x0000556d8e37e876 llvm::OptimizationRemark::~OptimizationRemark() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/DiagnosticInfo.h:689:7 llvm#21 0x0000556d8e37e876 operator() /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Transforms/Coroutines/CoroSplit.cpp:2213:14 llvm#22 0x0000556d8e37e876 emit<llvm::CoroSplitPass::run(llvm::LazyCallGraph::SCC&, llvm::CGSCCAnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&)::<lambda()> > /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/Analysis/OptimizationRemarkEmitter.h:83:12 llvm#23 0x0000556d8e37e876 llvm::CoroSplitPass::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Transforms/Coroutines/CoroSplit.cpp:2212:13 llvm#24 0x0000556d8c36ecb1 llvm::detail::PassModel<llvm::LazyCallGraph::SCC, llvm::CoroSplitPass, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 llvm#25 0x0000556d91c1a84f llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Analysis/CGSCCPassManager.cpp:90:12 llvm#26 0x0000556d8c3690d1 llvm::detail::PassModel<llvm::LazyCallGraph::SCC, llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 llvm#27 0x0000556d91c2162d llvm::ModuleToPostOrderCGSCCPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Analysis/CGSCCPassManager.cpp:278:18 llvm#28 0x0000556d8c369035 llvm::detail::PassModel<llvm::Module, llvm::ModuleToPostOrderCGSCCPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 llvm#29 0x0000556d9457abc5 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManager.h:247:20 llvm#30 0x0000556d8e30979e llvm::CoroConditionalWrapper::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Transforms/Coroutines/CoroConditionalWrapper.cpp:19:74 llvm#31 0x0000556d8c365755 llvm::detail::PassModel<llvm::Module, llvm::CoroConditionalWrapper, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 llvm#32 0x0000556d9457abc5 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManager.h:247:20 llvm#33 0x0000556d89818556 llvm::SmallPtrSetImplBase::isSmall() const /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:196:33 llvm#34 0x0000556d89818556 llvm::SmallPtrSetImplBase::~SmallPtrSetImplBase() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:84:17 llvm#35 0x0000556d89818556 llvm::SmallPtrSetImpl<llvm::AnalysisKey*>::~SmallPtrSetImpl() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:321:7 llvm#36 0x0000556d89818556 llvm::SmallPtrSet<llvm::AnalysisKey*, 2u>::~SmallPtrSet() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:427:7 llvm#37 0x0000556d89818556 llvm::PreservedAnalyses::~PreservedAnalyses() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/Analysis.h:109:7 llvm#38 0x0000556d89818556 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::ArrayRef<std::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) /home/ubuntu/modular/third-party/llvm-project/llvm/tools/opt/NewPMDriver.cpp:532:10 llvm#39 0x0000556d897e3939 optMain /home/ubuntu/modular/third-party/llvm-project/llvm/tools/opt/optdriver.cpp:737:27 llvm#40 0x0000556d89455461 main /home/ubuntu/modular/third-party/llvm-project/llvm/tools/opt/opt.cpp:25:33 llvm#41 0x00007f1d88e29d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16 llvm#42 0x00007f1d88e29e40 call_init ./csu/../csu/libc-start.c:128:20 llvm#43 0x00007f1d88e29e40 __libc_start_main ./csu/../csu/libc-start.c:379:5 llvm#44 0x0000556d897b6335 _start (/home/ubuntu/modular/.derived/third-party/llvm-project/build-relwithdebinfo-asan/bin/opt+0x150c335) Aborted (core dumped)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
-mbb-profile-dump([AsmPrint] Dump raw frequencies in-mbb-profile-dumpllvm/llvm-project#66818)_nv([mlir][spirv] Suffix NV cooperative matrix props with_nvllvm/llvm-project#66820)notifyOperationRemovedcallback for nested ops ([mlir][IR] TriggernotifyOperationRemovedcallback for nested ops llvm/llvm-project#66771)GIM_SwitchOpcodein Combiners ([TableGen][GlobalISel] UseGIM_SwitchOpcodein Combiners llvm/llvm-project#66864)eh_typeid_forintrinsic needs special care too ([clang][CodeGen] Theeh_typeid_forintrinsic needs special care too llvm/llvm-project#65699)clearerrfmul/fdivby Pow2 toadd/subof exp; NFCfmul/fdivby Pow2 toadd/subof exp; NFCfmul/fdivby Pow2 toadd/subof expcombineFMulOrFDivWithIntPow2to work for non-splat float vecsFileEntryRefinPreamblePatchFileEntryRefinSymbolCollectorFileEntryRefinFileManagerTestLoopLikeOpInterface: Add helpers to get region iter_args and inits ([mlir][Interfaces]LoopLikeOpInterface: Add helpers to get region iter_args and inits llvm/llvm-project#66925)LinalgOpinherit fromDestinationStyleOpInterface([mlir][linalg][NFC] MakeLinalgOpinherit fromDestinationStyleOpInterfacellvm/llvm-project#66995)Block::hasTerminatortomightHaveTerminator([MLIR][IR] RenameBlock::hasTerminatortomightHaveTerminatorllvm/llvm-project#66870)DestinationStyleOpInterface([mlir][Interfaces] Clean upDestinationStyleOpInterfacellvm/llvm-project#67015)RegionBranchOpInterface([mlir][Interfaces][NFC] Better documentation forRegionBranchOpInterfacellvm/llvm-project#66920)Strategyto determine whether to fix a parameternvgpu.warpgroup.mmaOp for Hopper GPUs ([MLIR][NVGPU] Addingnvgpu.warpgroup.mmaOp for Hopper GPUs llvm/llvm-project#65440)enable_arm_streaming_ignoreattribute ([mlir][ArmSME] Addenable_arm_streaming_ignoreattribute llvm/llvm-project#66911)deallocationFnfromBufferizationOptions([mlir][bufferization] RemovedeallocationFnfromBufferizationOptionsllvm/llvm-project#67128)nvgpu.mbarrier.groupfor multiple mbarrier use ([MLIR][NVGPU] Introducenvgpu.mbarrier.groupfor multiple mbarrier use llvm/llvm-project#65951)