Ndebug #6
Closed
Ndebug #6
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts part of D149033 and rG8f966cedea594d9a91e585e88a80a42c04049e6c. The added test case is kept to avoid future regression. Reviewed By: vzakhari, vdonaldson Differential Revision: https://reviews.llvm.org/D149639
We don't have i1 vector shuffle lowering.
Element-wise log(exp) does no operation so that we can fold it into no-op effectively. Reviewed By: eric-k256 Differential Revision: https://reviews.llvm.org/D149632
Some mid-air collision between a change in the generic format and this new python test.
llvm::CodeGen was missing so add them to deps Reviewed By: csigg Differential Revision: https://reviews.llvm.org/D149720
We previously used a more stricter -nostdlib option which was also removing compiler-rt/libgcc. Reviewed By: jhuber6 Differential Revision: https://reviews.llvm.org/D149683
…tests on Windows" This reverts commit 63f0fdc. Since f1431bb, this environment variable is always set up by lit itself, so individual test suites don't need to set it. Differential Revision: https://reviews.llvm.org/D149356
There was a discrepancy where the flag was honored when passed through the command line, but not when passed through the API, which was leading to a python test failing.
This test was added by the change which removed typed pointer support. We saved typed pointer support that's why this test expectedly fails. Using COM: results in test being UNRESOLVED.
Small split change from D146023. Migrate elf-notes to v4 and fix llvm-readobj to work with PAL metadata. Reviewed By: kzhuravl Differential Revision: https://reviews.llvm.org/D146119
Restore code removed incorrectly in merge.
hlfir.region_assign is a Region based version of hlfir.assign: the right-hand side and left-hand-side are evaluated in their own region, and an optional region can be added to implement user defined assignment. This will be used for: - assignments inside where and forall - user defined assignments - assignments to vector subscripted entities. Rational: Forall and Where lowering requires solving an expression/assignment evaluation scheduling problem based on data dependencies between the variables being assigned and the one used in the expressions. Keeping left-hand side and right-hand side in their own region will make it really easy to analyse the dependency and move around the expression evaluation as a whole. Operation DAGs are hard to scissor out when the LHS and RHS evaluation are lowered in the same block. The pass dealing with further forall/where lowering in HLFIR will need to succeed. It is not acceptable for them to fail splitting the RHS/LHS evaluation code. Keeping them in independent block is an approach that cannot fail. For user defined assignments, having a region allows implementing all the call details in lowering, and even to allow inlining of the user assignment, before it is decided if a temporary for the LHS or RHS is required or not. The operation description mention "hlfir.elemental_addr" (operation that will be used for vector subscripted LHS) and "ordered assignment trees" (concept/inetrface that will be used to represent forall/where structure in HLFIR). These will be pushed in follow-up patch, but I do not want t scissor out the descriptions. Differential Revision: https://reviews.llvm.org/D149442
Pass on address space information to SPIR-V Joint Matrix Load/Store intrinsics. --------- Signed-off-by: Sidorov, Dmitry <[email protected]> Co-authored-by: Sidorov, Dmitry <[email protected]>
* According to the [specification](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:accessor.local) a local accessor must not be used in a SYCL kernel function that is invoked via single_task or via the simple form of parallel_for that takes a range parameter. * Modifies existing misuse in tests. * This PR was once reviewed and merged in, but it was reverted as needed AccessTargetMask as an exported symbol on Windows to be added. --------- Co-authored-by: Alexey Bader <[email protected]> Co-authored-by: Mahmoud Moadeli <[email protected]> Co-authored-by: Steffen Larsen <[email protected]>
…ment See the operation description in HLFIROps.td. Depends on D149442 Differential Revision: https://reviews.llvm.org/D149449
Lower vector subscripted designators as values when they appear outside of the assignment left-hand side and input IO contexts. This matches Fortran semantics where vector subscripted designators cannot be written to outside of the two contexts mentioned above: they are passed/taken by value where they appear. This patch uses the added hlfir.element_addr to lower vector designators in lowering. But when reaching the end of the designator lowering, the hlfir.element_addr is turned into an hlfir.elemental when lowering is not asking for the hlfir.elemental_addr. This approach allows lowering vector subscripted in the same way in while visiting the designator, and only adapt to the context at the edge. The part where lowering uses the hlfir.elemental_addr will be done in further patch as it requires lowering assignments in the new hlfir.region_assign op, and there is not codegen yet for these new operations. Differential Revision: https://reviews.llvm.org/D149480
Allow shrink-wrapping past memory accesses that only access globals or function arguments. This patch uses getUnderlyingObject to try to identify the accessed object by a given memory operand. If it is a global or an argument, it does not access the stack of the current function and should not block shrink wrapping. Note that the caller's stack may get accessed when passing an argument via the stack, but not the stack of the current function. This addresses part of the TODO from D63152. Reviewed By: thegameg Differential Revision: https://reviews.llvm.org/D149668
OutputSection::checkDynRelAddends() incorrectly reports an internal linker error for large addends on 32-bit targets. This is caused by the lack of sign extension in DynamicReloc::computeAddend() for 32-bit addends. Differential Revision: https://reviews.llvm.org/D149347
It was rejected in C, and in a strange way accepted in C++. However, the support was never properly tested and fully implemented, so just reject it in C++ mode as well. This change also fixes crash on attempt to initialize union with flexible array member. Due to missing check on union, there was a null expression added to init list that caused crash later. Fixes llvm/llvm-project#61746 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D147626
Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D149152
This reverts commit 22e2db6. Broke buildbots on Windows. It seems standard headers on Windows contain flexible array members in unions
…ntel#9135) Signed-off-by: Tikhomirova, Kseniya <[email protected]>
DG2 doesn't support the sqrtm instruction used in the test. Signed-off-by: Sarnie, Nick <[email protected]>
This tries to push the concat in trunc(concat(rshr, rshr)) into the leaves, so that we can generate rshrn(concat). This helps improve the codegen for small types, using the existing rshrn patterns. Differential Revision: https://reviews.llvm.org/D149636
The previous pattern was matching the RVA `0` to the first character of `0x1010`. Make sure now that the entire export entry is matched.
…exports ordinals are large.
intel#8848 Signed-off-by: Jaime Arteaga <[email protected]>
intel#9052 Signed-off-by: Jaime Arteaga <[email protected]>
intel#8763 Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
https://github.com/intel/llvm/pull/8603/files Signed-off-by: Jaime Arteaga <[email protected]>
intel#9094 Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
intel#9109 Signed-off-by: Jaime Arteaga <[email protected]>
intel#9067 Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
intel#8982 Signed-off-by: Jaime Arteaga <[email protected]>
* Fix failing device CTS Signed-off-by: Brandon Yates <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
intel#9203 Signed-off-by: Jaime Arteaga <[email protected]>
intel#9243 Signed-off-by: Jaime Arteaga <[email protected]>
intel#9275 Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
Signed-off-by: Jaime Arteaga <[email protected]>
intel#9300 Signed-off-by: Jaime Arteaga <[email protected]>
* Fixes for porting to UR repo Signed-off-by: Brandon Yates <[email protected]> --------- Signed-off-by: Brandon Yates <[email protected]>
Signed-off-by: Brandon Yates <[email protected]>
jandres742
pushed a commit
that referenced
this pull request
May 15, 2023
…callback
The `TypeSystemMap::m_mutex` guards against concurrent modifications
of members of `TypeSystemMap`. In particular, `m_map`.
`TypeSystemMap::ForEach` iterates through the entire `m_map` calling
a user-specified callback for each entry. This is all done while
`m_mutex` is locked. However, there's nothing that guarantees that
the callback itself won't call back into `TypeSystemMap` APIs on the
same thread. This lead to double-locking `m_mutex`, which is undefined
behaviour. We've seen this cause a deadlock in the swift plugin with
following backtrace:
```
int main() {
std::unique_ptr<int> up = std::make_unique<int>(5);
volatile int val = *up;
return val;
}
clang++ -std=c++2a -g -O1 main.cpp
./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b
```
```
frame #4: std::lock_guard<std::mutex>::lock_guard
frame #5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock #2
frame #6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage
frame #7: lldb_private::Target::GetScratchTypeSystemForLanguage
...
frame intel#26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths
frame intel#27: lldb_private::SwiftASTContext::LoadModule
frame intel#30: swift::ModuleDecl::collectLinkLibraries
frame intel#31: lldb_private::SwiftASTContext::LoadModule
frame intel#34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl
frame intel#35: lldb_private::SwiftASTContext::PerformCompileUnitImports
frame intel#36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext
frame intel#37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState
frame intel#38: lldb_private::Target::GetPersistentSymbol
frame intel#41: lldb_private::TypeSystemMap::ForEach <<<< Lock #1
frame intel#42: lldb_private::Target::GetPersistentSymbol
frame intel#43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols
frame intel#44: lldb_private::IRExecutionUnit::FindSymbol
frame intel#45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence
frame intel#46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame intel#47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame intel#48: llvm::LinkingSymbolResolver::findSymbol
frame intel#49: llvm::LegacyJITSymbolResolver::lookup
frame intel#50: llvm::RuntimeDyldImpl::resolveExternalSymbols
frame intel#51: llvm::RuntimeDyldImpl::resolveRelocations
frame intel#52: llvm::MCJIT::finalizeLoadedModules
frame intel#53: llvm::MCJIT::finalizeObject
frame intel#54: lldb_private::IRExecutionUnit::ReportAllocations
frame intel#55: lldb_private::IRExecutionUnit::GetRunnableInfo
frame intel#56: lldb_private::ClangExpressionParser::PrepareForExecution
frame intel#57: lldb_private::ClangUserExpression::TryParse
frame intel#58: lldb_private::ClangUserExpression::Parse
```
Our solution is to simply iterate over a local copy of `m_map`.
**Testing**
* Confirmed on manual reproducer (would reproduce 100% of the time
before the patch)
Differential Revision: https://reviews.llvm.org/D149949
jandres742
pushed a commit
that referenced
this pull request
Oct 13, 2023
…fine.parallel verifier
This patch updates AffineParallelOp::verify() to check each result type matches
its corresponding reduction op (i.e, the result type must be a `FloatType` if
the reduction attribute is `addf`)
affine.parallel will crash on --lower-affine if the corresponding result type
cannot match the reduction attribute.
```
%128 = affine.parallel (%arg2, %arg3) = (0, 0) to (8, 7) reduce ("maxf") -> (memref<8x7xf32>) {
%alloc_33 = memref.alloc() : memref<8x7xf32>
affine.yield %alloc_33 : memref<8x7xf32>
}
```
This will crash and report a type conversion issue when we run `mlir-opt --lower-affine`
```
Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file Casting.h, line 572.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: mlir-opt --lower-affine temp.mlir
#0 0x0000000102a18f18 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/workspacebin/mlir-opt+0x1002f8f18)
#1 0x0000000102a171b4 llvm::sys::RunSignalHandlers() (/workspacebin/mlir-opt+0x1002f71b4)
#2 0x0000000102a195c4 SignalHandler(int) (/workspacebin/mlir-opt+0x1002f95c4)
#3 0x00000001be7894c4 (/usr/lib/system/libsystem_platform.dylib+0x1803414c4)
#4 0x00000001be771ee0 (/usr/lib/system/libsystem_pthread.dylib+0x180329ee0)
#5 0x00000001be6ac340 (/usr/lib/system/libsystem_c.dylib+0x180264340)
#6 0x00000001be6ab754 (/usr/lib/system/libsystem_c.dylib+0x180263754)
#7 0x0000000106864790 mlir::arith::getIdentityValueAttr(mlir::arith::AtomicRMWKind, mlir::Type, mlir::OpBuilder&, mlir::Location) (.cold.4) (/workspacebin/mlir-opt+0x104144790)
#8 0x0000000102ba66ac mlir::arith::getIdentityValueAttr(mlir::arith::AtomicRMWKind, mlir::Type, mlir::OpBuilder&, mlir::Location) (/workspacebin/mlir-opt+0x1004866ac)
#9 0x0000000102ba6910 mlir::arith::getIdentityValue(mlir::arith::AtomicRMWKind, mlir::Type, mlir::OpBuilder&, mlir::Location) (/workspacebin/mlir-opt+0x100486910)
...
```
Fixes #64068
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D157985
jandres742
pushed a commit
that referenced
this pull request
Nov 8, 2023
…tePluginObject After llvm/llvm-project#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 # | intel#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 # | intel#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 # | intel#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 # | intel#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 # | intel#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 # | intel#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 # | intel#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 # | intel#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 # | intel#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.
jandres742
pushed a commit
that referenced
this pull request
Nov 22, 2023
…ooking options for a custom subcommand (#71975) …ooking options for a custom subcommand. (#71776)" This reverts commit b88308b. The build-bot is unhappy (https://lab.llvm.org/buildbot/#/builders/186/builds/13096), `GroupingAndPrefix` fails after `TopLevelOptInSubcommand` (the newly added test). Revert while I look into this (might be related with test sharding but not sure) ``` [----------] 3 tests from CommandLineTest [ RUN ] CommandLineTest.TokenizeWindowsCommandLine2 [ OK ] CommandLineTest.TokenizeWindowsCommandLine2 (0 ms) [ RUN ] CommandLineTest.TopLevelOptInSubcommand [ OK ] CommandLineTest.TopLevelOptInSubcommand (0 ms) [ RUN ] CommandLineTest.GroupingAndPrefix #0 0x00ba8118 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x594118) #1 0x00ba5914 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x591914) #2 0x00ba89c4 SignalHandler(int) (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5949c4) #3 0xf7828530 __default_sa_restorer /build/glibc-9MGTF6/glibc-2.31/signal/../sysdeps/unix/sysv/linux/arm/sigrestorer.S:67:0 #4 0x00af91f0 (anonymous namespace)::CommandLineParser::ResetAllOptionOccurrences() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x4e51f0) #5 0x00af8e1c llvm::cl::ResetCommandLineParser() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x4e4e1c) #6 0x0077cda0 (anonymous namespace)::CommandLineTest_GroupingAndPrefix_Test::TestBody() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x168da0) #7 0x00bc5adc testing::Test::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5b1adc) #8 0x00bc6cc0 testing::TestInfo::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5b2cc0) #9 0x00bc7880 testing::TestSuite::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5b3880) #10 0x00bd7974 testing::internal::UnitTestImpl::RunAllTests() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5c3974) #11 0x00bd6ebc testing::UnitTest::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5c2ebc) #12 0x00bb1058 main (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x59d058) intel#13 0xf78185a4 __libc_start_main /build/glibc-9MGTF6/glibc-2.31/csu/libc-start.c:342:3 ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
91 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.