[llvm-bugs] [Bug 49890] New: FAIL: lldb-api :: tools/lldb-vscode/attach/TestVSCode_attach.py
https://bugs.llvm.org/show_bug.cgi?id=49890
Bug ID: 49890
Summary: FAIL: lldb-api ::
tools/lldb-vscode/attach/TestVSCode_attach.py
Product: new-bugs
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: nnel...@infowest.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
This bug may be a repeat of bug 49242.
FAIL: lldb-api :: tools/lldb-vscode/attach/TestVSCode_attach.py (87920 of
87920)
TEST 'lldb-api ::
tools/lldb-vscode/attach/TestVSCode_attach.py' FAILED
Script:
--
/usr/bin/python3.8
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/llvm-project/lldb/test/API/dotest.py
-u CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
--env
LLVM_LIBS_DIR=/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/./lib
--arch x86_64 --build-dir
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/lldb-test-build.noindex
--lldb-module-cache-dir
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/lldb-test-build.noindex/module-cache-lldb/lldb-api
--clang-module-cache-dir
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/lldb-test-build.noindex/module-cache-clang/lldb-api
--executable
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/./bin/lldb
--compiler
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/./bin/clang
--dsymutil
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/./bin/dsymutil
--filecheck
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/./bin/FileCheck
--yaml2obj
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/./bin/yaml2obj
--lldb-libs-dir
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/./lib
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/llvm-project/lldb/test/API/tools/lldb-vscode/attach
-p TestVSCode_attach.py
--
Exit Code: 1
Command Output (stdout):
--
lldb version 12.0.0 (https://github.com/llvm/llvm-project.git revision
7e99bddfeaab2713a8bb6ca538da25b66e6efc59)
clang revision 7e99bddfeaab2713a8bb6ca538da25b66e6efc59
llvm revision 7e99bddfeaab2713a8bb6ca538da25b66e6efc59
Skipping following debug info categories: ['dsym', 'gmodules']
objc tests will be skipped because of unsupported platform
description: breakpoint 1.1
description: breakpoint 1.1
description: breakpoint 1.1
--
Command Output (stderr):
--
PASS: LLDB
(/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/bin/clang-x86_64)
:: test_by_name (TestVSCode_attach.TestVSCode_attach)
UNSUPPORTED: LLDB
(/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/bin/clang-x86_64)
:: test_by_name_waitFor (TestVSCode_attach.TestVSCode_attach) (requires one of
macosx, darwin, ios, tvos, watchos, bridgeos, iphonesimulator, watchsimulator,
appletvsimulator)
PASS: LLDB
(/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/bin/clang-x86_64)
:: test_by_pid (TestVSCode_attach.TestVSCode_attach)
PASS: LLDB
(/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/bin/clang-x86_64)
:: test_commands (TestVSCode_attach.TestVSCode_attach)
FAIL: LLDB
(/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/Phase3/Release+Asserts/llvmCore-12.0.0-rc5.obj/bin/clang-x86_64)
:: test_terminate_commands (TestVSCode_attach.TestVSCode_attach)
==
FAIL: test_terminate_commands (TestVSCode_attach.TestVSCode_attach)
--
Traceback (most recent call last):
File
"/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 135, in wrapper
return func(*args, **kwargs)
File
"/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/llvm-project/lldb/test/API/tools/lldb-vscode/attach/TestVSCode_attach.py",
line 225, in test_terminate_commands
self.verify_commands('terminateCommands', output, terminateCommands)
File
"/home/nnelson/Documents/llvm-project/llvm/utils/release/rc5/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscod
[llvm-bugs] [Bug 49891] New: No hint to use -std=c++20 when using 'concept' or 'requires' with older -std modes
https://bugs.llvm.org/show_bug.cgi?id=49891
Bug ID: 49891
Summary: No hint to use -std=c++20 when using 'concept' or
'requires' with older -std modes
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zi...@kayari.org
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
template
concept snackable = requires (sizeof(T) != 1)
template
struct S { };
template requires snackable
struct S { };
Compiling this C++20 code without -std=c++20 produces a load of parser errors:
c.C:2:3: error: unknown type name 'concept'
concept snackable = requires (sizeof(T) != 1)
^
c.C:2:23: error: use of undeclared identifier 'requires'
concept snackable = requires (sizeof(T) != 1)
^
c.C:7:22: error: unknown type name 'requires'
template requires snackable
^
c.C:7:31: error: variable template partial specialization does not specialize
any template argument; to define the primary template, remove the template
argument list
template requires snackable
^~~~
c.C:7:43: error: expected ';' at end of declaration
template requires snackable
^
;
c.C:8:12: error: use of undeclared identifier 'T'
struct S { };
^
6 errors generated.
There's no hint that you need to enable C++20.
GCC does better:
c.C:2:3: error: 'concept' does not name a type
2 | concept snackable = requires (sizeof(T) != 1)
| ^~~
c.C:2:3: note: 'concept' only available with '-std=c++20' or '-fconcepts'
c.C:7:22: error: 'requires' does not name a type
7 | template requires snackable
| ^~~~
c.C:7:22: note: 'requires' only available with '-std=c++20' or '-fconcepts'
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49892] New: [WebAssembly Target] Import+Export Attribute: C++ Generics
https://bugs.llvm.org/show_bug.cgi?id=49892
Bug ID: 49892
Summary: [WebAssembly Target] Import+Export Attribute: C++
Generics
Product: clang
Version: unspecified
Hardware: PC
OS: other
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: sascha.braun@googlemail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Hi,
this is more a feature proposal than a bug report.
For WASM, we have
__attribute__((import_name(name)))
__attribute__((export_name(name)))
This is static and not yet really suitable for generic types and functions.
Can this be extended, e.g. in the following manner:
__attribute__((import_name("importedfunction1")))
Where T gets replaced by the generic argument type name.
In order to be able to address unmangled or language independent type names,
another addition may be needed:
We would need to be able to decorate types/classes with another attribute, e.g.
__attribute__((wasm_type_name("MyClass1NameAttribute"))) class MyClass1 { ...
};
So we can get finally to resolve
__attribute__((import_name("importedfunction1"))) generic_type_function1()
{}
into a wasm import name importedfunction1.
This can be very useful if the executing VM is aware of the generics the wasm
module is implementing.
Many Thanks,
Sascha
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47728] "Attempt to use a SCEVCouldNotCompute object!" with opt -indvars -verify-indvars
https://bugs.llvm.org/show_bug.cgi?id=47728 Mikael Holmén changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Mikael Holmén --- I'll close this as it doesn't crash anymore. I don't know if the root problem is actually fixed or not so I'll just set WORKSFORME. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49893] New: opt -gvn fails with Assertion `!isa(TI) && "Cannot split critical edge from IndirectBrInst"'
https://bugs.llvm.org/show_bug.cgi?id=49893 Bug ID: 49893 Summary: opt -gvn fails with Assertion `!isa(TI) && "Cannot split critical edge from IndirectBrInst"' Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 24732 --> https://bugs.llvm.org/attachment.cgi?id=24732&action=edit bbi-b4783.ll reproducer Reproduce with: opt -S -gvn -o - bbi-54783.ll Result: opt: ../lib/Transforms/Utils/BreakCriticalEdges.cpp:117: llvm::BasicBlock *llvm::SplitKnownCriticalEdge(llvm::Instruction *, unsigned int, const llvm::CriticalEdgeSplittingOptions &, const llvm::Twine &): Assertion `!isa(TI) && "Cannot split critical edge from IndirectBrInst"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /repo/uabelho/master-github/llvm/build-all/bin/opt -S -gvn -o - bbi-54783.ll #0 0x0294ad33 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x294ad33) #1 0x029489ee llvm::sys::RunSignalHandlers() (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x29489ee) #2 0x0294b1f6 SignalHandler(int) Signals.cpp:0:0 #3 0x7f14f6ed0630 __restore_rt sigaction.c:0:0 #4 0x7f14f4603387 raise (/lib64/libc.so.6+0x36387) #5 0x7f14f4604a78 abort (/lib64/libc.so.6+0x37a78) #6 0x7f14f45fc1a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6) #7 0x7f14f45fc252 (/lib64/libc.so.6+0x2f252) #8 0x02974451 llvm::SplitKnownCriticalEdge(llvm::Instruction*, unsigned int, llvm::CriticalEdgeSplittingOptions const&, llvm::Twine const&) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x2974451) #9 0x02654f87 llvm::GVN::splitCriticalEdges(llvm::BasicBlock*, llvm::BasicBlock*) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x2654f87) #10 0x0265c52f llvm::GVN::addDeadBlock(llvm::BasicBlock*) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x265c52f) #11 0x0265a77f llvm::GVN::processFoldableCondBr(llvm::BranchInst*) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x265a77f) #12 0x02659ddd llvm::GVN::processInstruction(llvm::Instruction*) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x2659ddd) #13 0x0265b305 llvm::GVN::processBlock(llvm::BasicBlock*) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x265b305) #14 0x0265a870 llvm::GVN::iterateOnFunction(llvm::Function&) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x265a870) #15 0x02650a6d llvm::GVN::runImpl(llvm::Function&, llvm::AssumptionCache&, llvm::DominatorTree&, llvm::TargetLibraryInfo const&, llvm::AAResults&, llvm::MemoryDependenceResults*, llvm::LoopInfo*, llvm::OptimizationRemarkEmitter*, llvm::MemorySSA*) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x2650a6d) #16 0x0265022c llvm::GVN::run(llvm::Function&, llvm::AnalysisManager&) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x265022c) #17 0x02bfe79d llvm::detail::PassModel >::run(llvm::Function&, llvm::AnalysisManager&) crtstuff.c:0:0 #18 0x0217c769 llvm::PassManager >::run(llvm::Function&, llvm::AnalysisManager&) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x217c769) #19 0x00a8a3cd llvm::detail::PassModel >, llvm::PreservedAnalyses, llvm::AnalysisManager >::run(llvm::Function&, llvm::AnalysisManager&) crtstuff.c:0:0 #20 0x02180f66 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x2180f66) #21 0x0077563d llvm::detail::PassModel >::run(llvm::Module&, llvm::AnalysisManager&) crtstuff.c:0:0 #22 0x0217b5cb llvm::PassManager >::run(llvm::Module&, llvm::AnalysisManager&) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x217b5cb) #23 0x0076e543 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool) (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x76e543) #24 0x0077f236 main (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x77f236) #25 0x7f14f45ef555 __libc_start_main (/lib64/libc.so.6+0x22555) #26 0x00769705 _start (/repo/uabelho/master-github/llvm/build-all/bin/opt+0x769705) Abort -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org ht
[llvm-bugs] Issue 33029 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: Idx >= 0 && "Invalid basic block argument!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-04-08 Type: Bug New issue 33029 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: Idx >= 0 && "Invalid basic block argument!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33029 Detailed Report: https://oss-fuzz.com/testcase?key=5093295945547776 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: Idx >= 0 && "Invalid basic block argument!" llvm::ScalarEvolution::isImpliedViaMerge llvm::ScalarEvolution::isImpliedViaOperations Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202012280613:202012290618 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5093295945547776 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49678] SymbolFile/DWARF/dwarf5-debug_line-file-index.s crash lldb on arm linux
https://bugs.llvm.org/show_bug.cgi?id=49678 lab...@google.com changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||2ecf928153fc56dcb6bb0bd9105 ||84eac86bc23bd --- Comment #3 from lab...@google.com --- The underlying issue fixed by 2ecf928153fc56dcb6bb0bd910584eac86bc23bd. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49894] New: Clang crash in SubstituteExplicitTemplateArguments
https://bugs.llvm.org/show_bug.cgi?id=49894
Bug ID: 49894
Summary: Clang crash in SubstituteExplicitTemplateArguments
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ebrown...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Clang crashes in SubstituteExplicitTemplateArguments from this code:
https://godbolt.org/z/orbGf1ob7.
Possible duplicate of 48808.
Output:
:19:80: error: expected ')'
void* f(/*typename*/ RefOrValueArg::value>::template type
key) {
^
:19:8: note: to match this '('
void* f(/*typename*/ RefOrValueArg::value>::template type
key) {
^
:19:84: error: expected ';' at end of declaration
void* f(/*typename*/ RefOrValueArg::value>::template type
key) {
^
;
:19:85: error: expected unqualified-id
void* f(/*typename*/ RefOrValueArg::value>::template type
key) {
^
:26:11: error: called object type 'void *' is not a function or
function pointer
g(f(a));
~~^
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang++ -g -o
/app/output.s -mllvm --x86-asm-syntax=intel -S
--gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics
-fno-crash-diagnostics
1. parser at end of file
2. :19:7: instantiating variable definition 'f'
3. :19:7: instantiating variable definition 'f'
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH
or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x2c)[0x5597daa1183c]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN4llvm3sys17RunSignalHandlersEv+0x34)[0x5597daa0f7c4]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN4llvm3sys15CleanupOnSignalEm+0xb5)[0x5597daa0fa45]
/opt/compiler-explorer/clang-trunk/bin/clang++(+0x30bd968)[0x5597da973968]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fe1c7ad73c0]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema35SubstituteExplicitTemplateArgumentsEPNS_20FunctionTemplateDeclERNS_24TemplateArgumentListInfoERN4llvm15SmallVectorImplINS_23DeducedTemplateArgumentEEERNS6_INS_8QualTypeEEEPSA_RNS_4sema21TemplateDeductionInfoE+0x41f)[0x5597dcde3dff]
/opt/compiler-explorer/clang-trunk/bin/clang++(+0x552e7d1)[0x5597dcde47d1]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema27runWithSufficientStackSpaceENS_14SourceLocationEN4llvm12function_refIFvvEEE+0x3f)[0x5597dc7a178f]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema23DeduceTemplateArgumentsEPNS_20FunctionTemplateDeclEPNS_24TemplateArgumentListInfoENS_8QualTypeERPNS_12FunctionDeclERNS_4sema21TemplateDeductionInfoEb+0x206)[0x5597dce16c86]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema23DeduceTemplateArgumentsEPNS_20FunctionTemplateDeclEPNS_24TemplateArgumentListInfoERPNS_12FunctionDeclERNS_4sema21TemplateDeductionInfoEb+0x17)[0x5597dce17267]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema43ResolveSingleFunctionTemplateSpecializationEPNS_12OverloadExprEbPNS_14DeclAccessPairE+0x2d5)[0x5597dccd8b65]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema34ResolveAddressOfOverloadedFunctionEPNS_4ExprENS_8QualTypeEbRNS_14DeclAccessPairEPb+0xcf5)[0x5597dccddfe5]
/opt/compiler-explorer/clang-trunk/bin/clang++(+0x54294ba)[0x5597dccdf4ba]
/opt/compiler-explorer/clang-trunk/bin/clang++(+0x5430227)[0x5597dcce6227]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema21TryImplicitConversionEPNS_4ExprENS_8QualTypeEbNS0_15AllowedExplicitEbbb+0x35)[0x5597dcce6475]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang22InitializationSequence14InitializeFromERNS_4SemaERKNS_17InitializedEntityERKNS_18InitializationKindEN4llvm15MutableArrayRefIPNS_4ExprEEEbb+0xd1f)[0x5597dcba6fcf]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema20AddInitializerToDeclEPNS_4DeclEPNS_4ExprEb+0xab5)[0x5597dc902205]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema30InstantiateVariableInitializerEPNS_7VarDeclES2_RKNS_30MultiLevelTemplateArgumentListE+0x2e0)[0x5597dce78050]
/opt/compiler-explorer/clang-trunk/bin/clang++(_ZN5clang4Sema37CompleteVarTemplateSpecializationDeclEPNS_29VarTemplateSpecializationDeclEPNS_7Va
[llvm-bugs] [Bug 49895] New: optimize smax(x, -1) with bit-hack
https://bugs.llvm.org/show_bug.cgi?id=49895
Bug ID: 49895
Summary: optimize smax(x, -1) with bit-hack
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Noticed while investigating idioms for signum functions...
If we have an smax with -1:
declare i32 @llvm.smax.i32(i32, i32)
define i32 @smax(i32 %x) {
%m = call i32 @llvm.smax.i32(i32 %x, i32 -1)
ret i32 %m
}
or:
define i32 @cmpsel(i32 %x) {
%a = icmp sgt i32 %x, -1
%m = select i1 %a, i32 %x, i32 -1
ret i32 %m
}
It seems most targets would do better to convert to arithmetic shift + logic:
define i32 @tgt(i32 %x) {
%a = ashr i32 %x, 31
%m = or i32 %x, %a
ret i32 %m
}
https://alive2.llvm.org/ce/z/AJYAmp
AArch64:
cmp w0, #0
csinv w0, w0, wzr, ge
vs.
orr w0, w0, w0, asr #31
PowerPC64:
li 4, -1
cmpwi 3, -1
rldic 4, 4, 0, 32
iselgt 3, 3, 4
vs.
srawi 4, 3, 31
or 3, 3, 4
x86:
testl %edi, %edi
movl$-1, %eax
cmovnsl %edi, %eax
vs.
movl%edi, %eax
sarl$31, %eax
orl %edi, %eax
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49896] New: FMF.isFast() returns incorrect result when FMF==0x7f
https://bugs.llvm.org/show_bug.cgi?id=49896 Bug ID: 49896 Summary: FMF.isFast() returns incorrect result when FMF==0x7f Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: melanie.blo...@intel.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org I want to check whether the IR Builder FMF flags are set to isFast() in clang/codegen I have a test case that selects all the FMF flags on the cc1 command line, I tried to write this code: auto FMF = Builder.getFastMathFlags(); if (FMF.isFast()) but that didn't work, I had to write like this: if (FMF.allowReassoc() && FMF.noNaNs() && FMF.noInfs() && FMF.noSignedZeros() && FMF.allowReciprocal() && FMF.allowContract() && FMF.approxFunc()) That's because the implementation of isFast ultimately checks, in llvm Operator.h, if the byte == ~0 OK to rewrite that check as byte == 0x7f? I read a comment that the bits in the struct are all used up, there's no 8th bit available at this time. I don't have an easy reproducer, the patch I'm working on is https://reviews.llvm.org/D100118 ; the line where I had to check each bits is CGBuiltin.cpp:3829 in that patch. If I change it to isFast() then the first run line in the test case fails, clang/test/CodeGen/arithmetic-fence-builtin.c -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49897] New: Missing dyn symbol for a weak wrapped function when using --wrap
https://bugs.llvm.org/show_bug.cgi?id=49897
Bug ID: 49897
Summary: Missing dyn symbol for a weak wrapped function when
using --wrap
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: shural...@snapchat.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com
Being honest I'm not sure if this is a really justified bug but at least
intuitively it really feels wrong. All below said is about current mainstream:
$ bin/clang -fuse-ld=lld -Wl,--version
LLD 13.0.0 (https://github.com/llvm/llvm-project.git
37878de5036718481e13d5067a17d65eb85c3388) (compatible with GNU linkers)
When linking a DSO that refers to a some weak symbol, for which no shared
library with a definition was provided at the link time, I'm anyways getting
NOTYPE WEAK symbol in the final .dynsym:
$ cat test.c
__attribute__((weak))
extern int foo(int i);
int bar(int i) {
return foo(i + 10);
}
$ bin/clang -fuse-ld=lld -shared -fPIC -Wl,--no-undefined test.c && readelf
--dyn-syms a.out | grep foo
5: 0 NOTYPE WEAK DEFAULT UND foo
So that linker tolerates a weak external symbol with a missing definition. And
of course when providing some libfoo.so that has this symbol defined I'm
getting usual FUNC WEAK symbol:
$ bin/clang -fuse-ld=lld -shared -fPIC -Wl,--no-undefined test.c libfoo.so &&
readelf --dyn-syms a.out | grep foo
5: 0 FUNCWEAK DEFAULT UND foo
Then let's presume we need to wrap foo() in our DSO by linking in an additional
object:
$ cat test_wrap.c
__attribute__((weak))
extern int __real_foo(int i);
int __wrap_foo(int i) {
return __real_foo ? __real_foo(i + 100) : -1;
}
When libfoo.so is given to a linker - everything is OK:
$ bin/clang -fuse-ld=lld -shared -fPIC -Wl,--no-undefined test.c -Wl,--wrap=foo
test_wrap.c libfoo.so && readelf --dyn-syms a.out | grep foo
5: 0 FUNCWEAK DEFAULT UND foo
9: 173073 FUNCGLOBAL DEFAULT 10 __wrap_foo
__wrap_foo() refers to external foo() as expected:
$ objdump -d a.out
...
1730 <__wrap_foo>:
1730: 55 push %rbp
1731: 48 89 e5mov%rsp,%rbp
1734: 48 83 ec 10 sub$0x10,%rsp
1738: 89 7d fcmov%edi,-0x4(%rbp)
173b: 48 8b 05 5e 12 00 00mov0x125e(%rip),%rax# 29a0
1742: 48 85 c0test %rax,%rax
1745: 0f 84 18 00 00 00 je 1763 <__wrap_foo+0x33>
174b: e9 00 00 00 00 jmpq 1750 <__wrap_foo+0x20>
1750: 8b 7d fcmov-0x4(%rbp),%edi
1753: 83 c7 64add$0x64,%edi
1756: e8 75 00 00 00 callq 17d0
175b: 89 45 f8mov%eax,-0x8(%rbp)
175e: e9 0d 00 00 00 jmpq 1770 <__wrap_foo+0x40>
1763: b8 ff ff ff ff mov$0x,%eax
1768: 89 45 f8mov%eax,-0x8(%rbp)
176b: e9 00 00 00 00 jmpq 1770 <__wrap_foo+0x40>
1770: 8b 45 f8mov-0x8(%rbp),%eax
1773: 48 83 c4 10 add$0x10,%rsp
1777: 5d pop%rbp
1778: c3 retq
...
17d0 :
17d0: ff 25 02 22 00 00 jmpq *0x2202(%rip)# 39d8
17d6: 68 02 00 00 00 pushq $0x2
17db: e9 c0 ff ff ff jmpq 17a0 <_fini+0xc>
But when libfoo.so is not provided it is quite expected to see a reference to
NOTYPE WEAK foo() from __wrap_foo(), exactly like it was with no --wrap. But
instead foo() is completely missing in .dynsym and __wrap_foo() refers to some
garbage:
$ bin/clang -fuse-ld=lld -shared -fPIC -Wl,--no-undefined test.c -Wl,--wrap=foo
test_wrap.c && readelf --dyn-syms a.out | grep foo
8: 169073 FUNCGLOBAL DEFAULT 10 __wrap_foo
$ objdump -d a.out
...
1690 <__wrap_foo>:
1690: 55 push %rbp
1691: 48 89 e5mov%rsp,%rbp
1694: 48 83 ec 10 sub$0x10,%rsp
1698: 89 7d fcmov%edi,-0x4(%rbp)
169b: 48 8b 05 4e 12 00 00mov0x124e(%rip),%rax# 28f0
<_DYNAMIC+0x1a0>
16a2: 48 85 c0test %rax,%rax
16a5: 0f 84 18 00 00 00 je 16c3 <__wrap_foo+0x33>
16ab: e9 00 00 00 00 jmpq 16b0 <__wrap_foo+0x20>
16b0: 8b 7d fcmov-0x4(%rbp),%edi
16b3: 83 c7 64add$0x64,%edi
16b6: e8 75 00 00 00
[llvm-bugs] [Bug 49898] New: Infinite loop in SLP vectorizer after 99203f2004d031f2ef22f01e3c569d2775de1836
https://bugs.llvm.org/show_bug.cgi?id=49898
Bug ID: 49898
Summary: Infinite loop in SLP vectorizer after
99203f2004d031f2ef22f01e3c569d2775de1836
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: benny@gmail.com
CC: a.bat...@hotmail.com, llvm-bugs@lists.llvm.org
$ cat t.ll
define void @fusion_1506(i8* %temp_buf1) local_unnamed_addr {
entry:
%0 = getelementptr inbounds i8, i8* %temp_buf1, i64 5621415936
%1 = getelementptr inbounds i8, i8* %temp_buf1, i64 7278166016
%2 = getelementptr inbounds i8, i8* %temp_buf1, i64 5097127936
%3 = bitcast i8* %2 to float*
%4 = bitcast i8* %1 to float*
%5 = getelementptr inbounds float, float* %4, i64 undef
store float undef, float* %5, align 16
%6 = bitcast i8* %0 to float*
%7 = getelementptr inbounds float, float* %6, i64 undef
store float undef, float* %7, align 16
%8 = getelementptr inbounds float, float* %6, i64 undef
store float undef, float* %8, align 4
%9 = getelementptr inbounds float, float* %3, i64 undef
store float undef, float* %9, align 4
ret void
}
$ opt t.ll -slp-vectorizer -S
This worked before
https://github.com/llvm/llvm-project/commit/99203f2004d031f2ef22f01e3c569d2775de1836
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42017] Typos fixes and text improvements in lldb tutorial
https://bugs.llvm.org/show_bug.cgi?id=42017 Jonas Devlieghere changed: What|Removed |Added Status|NEW |RESOLVED CC||jdevliegh...@apple.com Resolution|--- |FIXED --- Comment #1 from Jonas Devlieghere --- https://reviews.llvm.org/D100053 Thanks Sushma! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49899] New: lldb-shell :: Subprocess/clone-follow-parent*.test failing on Linux/aarch64
https://bugs.llvm.org/show_bug.cgi?id=49899 Bug ID: 49899 Summary: lldb-shell :: Subprocess/clone-follow-parent*.test failing on Linux/aarch64 Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: mgo...@gentoo.org CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org I don't have ARM64 hardware to debug this. The more important fork() tests seem to pass, so I'm just going to 'unsupport' clone() tests on ARM64 Linux. FAIL: lldb-shell :: Subprocess/clone-follow-parent.test (2291 of 2295) TEST 'lldb-shell :: Subprocess/clone-follow-parent.test' FAILED Script: -- : 'RUN: at line 2'; /home/tcwg-buildslave/worker/lldb-cmake-aarch64/build/bin/clang --driver-mode=g++ --target=specify-a-target-or-use-a-_host-substitution --target=aarch64-unknown-linux-gnu -pthread -fmodules-cache-path=/home/tcwg-buildslave/worker/lldb-cmake-aarch64/build/lldb-test-build.noindex/module-cache-clang/lldb-shell /home/tcwg-buildslave/worker/lldb-cmake-aarch64/llvm-project/lldb/test/Shell/Subprocess/Inputs/fork.cpp -DTEST_CLONE -o /home/tcwg-buildslave/worker/lldb-cmake-aarch64/build/tools/lldb/test/Shell/Subprocess/Output/clone-follow-parent.test.tmp : 'RUN: at line 3'; /home/tcwg-buildslave/worker/lldb-cmake-aarch64/build/bin/lldb --no-lldbinit -S /home/tcwg-buildslave/worker/lldb-cmake-aarch64/build/tools/lldb/test/Shell/lit-lldb-init -b -s /home/tcwg-buildslave/worker/lldb-cmake-aarch64/llvm-project/lldb/test/Shell/Subprocess/clone-follow-parent.test /home/tcwg-buildslave/worker/lldb-cmake-aarch64/build/tools/lldb/test/Shell/Subprocess/Output/clone-follow-parent.test.tmp | /home/tcwg-buildslave/worker/lldb-cmake-aarch64/build/bin/FileCheck /home/tcwg-buildslave/worker/lldb-cmake-aarch64/llvm-project/lldb/test/Shell/Subprocess/clone-follow-parent.test -- Exit Code: 1 Command Output (stderr): -- clang-13: warning: argument unused during compilation: '-fmodules-cache-path=/home/tcwg-buildslave/worker/lldb-cmake-aarch64/build/lldb-test-build.noindex/module-cache-clang/lldb-shell' [-Wunused-command-line-argument] /home/tcwg-buildslave/worker/lldb-cmake-aarch64/llvm-project/lldb/test/Shell/Subprocess/clone-follow-parent.test:10:10: error: CHECK: expected string not found in input # CHECK: child exited: 0 ^ :28:23: note: scanning from here function run in parent ^ :29:137: note: possible intended match here clone-follow-parent.test.tmp: /home/tcwg-buildslave/worker/lldb-cmake-aarch64/llvm-project/lldb/test/Shell/Subprocess/Inputs/fork.cpp:46: int main(): Assertion `WIFEXITED(status)' failed. ^ Input file: Check file: /home/tcwg-buildslave/worker/lldb-cmake-aarch64/llvm-project/lldb/test/Shell/Subprocess/clone-follow-parent.test -dump-input=help explains the following input dump. Input was: << . . . 23: 0x400738 <+4>: mov x29, sp 24: 0x40073c <+8>: adrp x9, 17 25: 0x400740 <+12>: mov w8, #0x1 26: Process 3229 launched: '/home/tcwg-buildslave/worker/lldb-cmake-aarch64/build/tools/lldb/test/Shell/Subprocess/Output/clone-follow-parent.test.tmp' (aarch64) 27: (lldb) continue 28: function run in parent check:10'0 X error: no match found 29: clone-follow-parent.test.tmp: /home/tcwg-buildslave/worker/lldb-cmake-aarch64/llvm-project/lldb/test/Shell/Subprocess/Inputs/fork.cpp:46: int main(): Assertion `WIFEXITED(status)' failed. check:10'0 check:10'1 ? possible intended match 30: Process 3229 resuming check:10'0 ~~ 31: Process 3229 stopped check:10'0 ~ 32: * thread #1, name = 'clone-follow-pa', stop reason = hit program assert check:10'0 33: frame #4: 0x00400870 clone-follow-parent.test.tmp`main + 240 check:10'0 ~~ 34: clone-follow-parent.test.tmp`main: check:10'0 ~~~ . . . >> -- T
[llvm-bugs] Issue 33042 in oss-fuzz: llvm:llvm-microsoft-demangle-fuzzer: Stack-overflow in llvm::ms_demangle::Demangler::parse
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-04-08 Type: Bug New issue 33042 by ClusterFuzz-External: llvm:llvm-microsoft-demangle-fuzzer: Stack-overflow in llvm::ms_demangle::Demangler::parse https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33042 Detailed Report: https://oss-fuzz.com/testcase?key=6527584180502528 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-microsoft-demangle-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc5fdcdfe8 Crash State: llvm::ms_demangle::Demangler::parse llvm::ms_demangle::Demangler::demangleLocallyScopedNamePiece llvm::ms_demangle::Demangler::demangleNameScopePiece Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=202011180625 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6527584180502528 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49900] New: Vectorizer is querying SCEV on partially constructed IR
https://bugs.llvm.org/show_bug.cgi?id=49900
Bug ID: 49900
Summary: Vectorizer is querying SCEV on partially constructed
IR
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org
This bug is a reduced form of
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33029 which was reported
as a regression against 4ffcd4fe9ac2ee948948f732baa16663eb63f1c7. I've further
reduced the test case and confirmed that this is not actually related to
multiple exit vectorization. The test case below involves no multiple or early
exit loops, and disabling the multiple exit support entirely does not change
the outcome.
$ ./opt -S test.ll -loop-vectorize # crashes
$ cat test.ll
; ModuleID =
'/home/preames/Downloads/clusterfuzz-testcase-minimized-llvm-opt-fuzzer--x86_64-loop_vectorize-5093295945547776'
source_filename =
"llvm-project/llvm/test/Transforms/LoopVectorize/X86/pr39160.ll"
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128-ni:1"
target triple = "x86_64-unknown-linux-gnu"
define void @barney() {
bb:
br label %bb2
bb2: ; preds = %bb2, %bb
%tmp4 = icmp slt i32 undef, 0
br i1 %tmp4, label %bb2, label %bb5
bb5: ; preds = %bb2
br label %bb19
bb18: ; preds = %bb33
ret void
bb19: ; preds = %bb36, %bb5
%tmp22 = phi i32 [ %tmp65, %bb36 ], [ undef, %bb5 ]
br label %bb50
bb33: ; preds = %bb62
br i1 undef, label %bb18, label %bb36
bb36: ; preds = %bb33
br label %bb19
bb46: ; preds = %bb50
%C = icmp uge i8 16, 0
%B4 = and i1 %C, true
%B5 = xor i1 %C, undef
br i1 %B5, label %bb48, label %bb59
bb48: ; preds = %bb46
ret void
bb50: ; preds = %bb50, %bb19
%tmp52 = phi i32 [ %tmp55, %bb50 ], [ %tmp22, %bb19 ]
%tmp53 = phi i64 [ %tmp56, %bb50 ], [ 1, %bb19 ]
%tmp54 = add i32 %tmp52, 12
%tmp55 = add i32 %tmp52, 13
%tmp56 = add nuw nsw i64 %tmp53, 1
%C6 = icmp sle i32 %tmp54, 65536
br i1 %C6, label %bb50, label %bb46
bb59: ; preds = %bb46
br label %bb62
bb62: ; preds = %bb68, %bb59
%tmp63 = phi i32 [ %tmp65, %bb62 ], [ %tmp55, %bb59 ]
%tmp64 = phi i64 [ %tmp66, %bb62 ], [ %tmp56, %bb59 ]
%tmp65 = add i32 %tmp63, 13
%tmp66 = add nuw nsw i64 %tmp64, 1
%C1 = icmp ult i32 %tmp65, 65536
br i1 %C1, label %bb62, label %bb33
}
We're crashing way down in SCEV when the predecessor lists of a phi and the
basic block itself don't match. This can be seen in the basic block below:
bb46: ; preds = %middle.block,
%bb50
%tmp55.lcssa = phi i32 [ %tmp55, %bb50 ]
%tmp56.lcssa = phi i64 [ %tmp56, %bb50 ]
%C = icmp uge i8 16, 0
%B4 = and i1 %C, true
%B5 = xor i1 %C, undef
br i1 %B5, label %bb48, label %bb59
This is illegal usage of SCEV by LoopVectorize. It appears to be a long
standing issue related to how we set up the phis for newly added edges.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49901] New: Compiler crash on simple coroutine code
https://bugs.llvm.org/show_bug.cgi?id=49901
Bug ID: 49901
Summary: Compiler crash on simple coroutine code
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: dasca...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Created attachment 24733
--> https://bugs.llvm.org/attachment.cgi?id=24733&action=edit
Preprocessed source code, gzipped for size reasons
While writing a TLS library I was trying to wrap it into a HTTP client type
called SecureClient. Its constructor kept giving compiler crashes so I tried to
move it out to a separate file (hoping to circumvent any inlining errors) but
that had no effect. The code that causes the crash is the following lines:
future SecureClient::create(tcp_socket sock,
Talos::TlsContextHandle& context) {
tls client = co_await tls::createServer(context, std::move(sock), 0);
co_return SecureClient(std::move(client));
}
The future type is a custom implementation but should not be *that* wrong. The
tls::createServer function returns a future so the co_await is there for
that; and then it co_returns a SecureClient move-constructed from that. This
used to be a oneliner but again, trying to circumvent the crash.
The future type and all other coroutine logic has been used in about 10k LoC
with no issues. I have no idea why this one crashes.
It crashes both on clang-10 and clang-11 for the Ubuntu 20.10 build of them.
Compiler output:
fatal error: error in backend: Cannot represent a difference across sections
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: clang++-11 -stdlib=libc++ -pthread -Wall -Wextra
-Wpedantic -Werror -std=c++2a -maes -mpclmul -g2 -fsanitize=address,undefined
-c -o build/clang11/obj/src/secure_connection.cpp.o src/secure_connection.cpp
-I./include -ICaligo/include -Imanto/include -Iserialize/include
-Italos/include
1. parser at end of file
2. Code generation
#0 0x7f7fb065abbf llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa6bbf)
#1 0x7f7fb0658f20 llvm::sys::RunSignalHandlers()
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa4f20)
#2 0x7f7fb065a30d llvm::sys::CleanupOnSignal(unsigned long)
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa630d)
#3 0x7f7fb05a27ca (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9ee7ca)
#4 0x7f7fb05a276b (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9ee76b)
#5 0x7f7fb06559ee (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xaa19ee)
#6 0x00412932 (/usr/lib/llvm-11/bin/clang+0x412932)
#7 0x7f7fb05ae82f llvm::report_fatal_error(llvm::Twine const&, bool)
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x9fa82f)
#8 0x7f7fb170d816 (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x1b59816)
#9 0x7f7fb16f067c (/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x1b3c67c)
#10 0x7f7fb1705122 llvm::MCAssembler::handleFixup(llvm::MCAsmLayout const&,
llvm::MCFragment&, llvm::MCFixup const&)
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x1b51122)
#11 0x7f7fb1705572 llvm::MCAssembler::layout(llvm::MCAsmLayout&)
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x1b51572)
#12 0x7f7fb1705818 llvm::MCAssembler::Finish()
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x1b51818)
#13 0x7f7fb0d18fb7 llvm::AsmPrinter::doFinalization(llvm::Module&)
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0x1164fb7)
#14 0x7f7fb076f2d1 llvm::FPPassManager::doFinalization(llvm::Module&)
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xbbb2d1)
#15 0x7f7fb076a352 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/lib/x86_64-linux-gnu/libLLVM-11.so.1+0xbb6352)
#16 0x7f7fb60d9916 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x1581916)
#17 0x7f7fb6396d06 (/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x183ed06)
#18 0x7f7fb54620e3 clang::ParseAST(clang::Sema&, bool, bool)
(/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x90a0e3)
#19 0x7f7fb6a2c198 clang::FrontendAction::Execute()
(/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x1ed4198)
#20 0x7f7fb69e2711
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x1e8a711)
#21 0x7f7fb6a922d0
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/lib/x86_64-linux-gnu/libclang-cpp.so.11+0x1f3a2d0)
#22 0x004125ff cc1_main(llvm::ArrayRef, char const*,
void*) (/usr/lib/llvm-11/bin/clang+0x4125ff)
#23 0x000
[llvm-bugs] [Bug 49768] opt -slsr crashing with "../lib/Analysis/ScalarEvolution.cpp:5678: llvm::ConstantRange llvm::ScalarEvolution::getRangeForUnknownRecurrence(const llvm::SCEVUnknown *): Assertion
https://bugs.llvm.org/show_bug.cgi?id=49768 listm...@philipreames.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from listm...@philipreames.com --- JFYI, should be fixed (again). commit fee330824a2b3d7e502a27e1464c418a4663d7a3 Author: Max Kazantsev Date: Wed Apr 7 13:14:53 2021 +0700 [SCEV] Fix false-positive recognition of simple recurrences. PR49856 A value from reachable block may come to a Phi node as its input from unreachable block. This may confuse matchSimpleRecurrence which has no access to DomTree and can falsely recognize something as a recurrency because of this effect, as the attached test shows. Patch `ae7b1e` deals with half of this problem, but it only accounts from the case when an unreachable instruction comes to Phi as an input. This patch provides a generalization by checking that no Phi block's predecessor is unreachable (no matter what the input is). Differential Revision: https://reviews.llvm.org/D99929 Reviewed By: reames -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49898] Infinite loop in SLP vectorizer after 99203f2004d031f2ef22f01e3c569d2775de1836
https://bugs.llvm.org/show_bug.cgi?id=49898 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||ab124bbe2a7c59cf23da5728dc2 ||39aba6f1efabe --- Comment #2 from Alexey Bataev --- Fixd in ab124bbe2a7c59cf23da5728dc239aba6f1efabe -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 33050 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::DiagnoseEmptyLookup
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-04-08 Type: Bug New issue 33050 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::DiagnoseEmptyLookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33050 Detailed Report: https://oss-fuzz.com/testcase?key=6686315300126720 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff2d0528c8 Crash State: clang::Sema::DiagnoseEmptyLookup FinishOverloadedCallExpr clang::Sema::BuildOverloadedCallExpr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202101150624:202101160602 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6686315300126720 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49903] New: Stack corruption with -fstack-clash-protection + -O2 on ppc64le with clang 12
https://bugs.llvm.org/show_bug.cgi?id=49903 Bug ID: 49903 Summary: Stack corruption with -fstack-clash-protection + -O2 on ppc64le with clang 12 Product: new-bugs Version: trunk Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: cl...@evan.coeusgroup.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24734 --> https://bugs.llvm.org/attachment.cgi?id=24734&action=edit Test case On clang 12 on ppc64le with -O2, -fstack-stack-protection sometimes causes some of my tests to fail. I don't really speak PPC assembly so I've pretty much hit the end of my ability to debug this further, sorry. I'm attaching two test cases, one is the original (pre-processed), the other has been run through cvise to try to reduce it, though I'm not sure that it shows the same issue as the original (it seems to manifest as an infinite loop instead of a segfault like the original). Compile with something like: clang -O2 -fstack-clash-protection -o test test.c -lm The corruption doesn't always occur, so you may have to run it a few times. For me, the counter in the function which calls the individual tests jumps from 76 to 140736792407376 (between the svml/mm256_cdfnorminv_pd and svml/mm512_cdfnorminv_ps tests), and eventually there is a segfault. I haven't been able to reproduce the problem with earlier versions of clang. The code works on other architectures. If there is anything else I can do to help please let me know. FWIW, I can provide access to the machine I'm encountering this on, though I only have clang-12 in an F32 docker container. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49459] Tracking task for LLD-MachO debug info issues
https://bugs.llvm.org/show_bug.cgi?id=49459 Bug 49459 depends on bug 49385, which changed state. Bug 49385 Summary: Support -add_ast_path https://bugs.llvm.org/show_bug.cgi?id=49385 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49385] Support -add_ast_path
https://bugs.llvm.org/show_bug.cgi?id=49385 Jez Ng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||c23b92acd0654bd63942fd70d39 ||c7955354ba3f6#diff-390e91d3 ||e245dfdf3ba30b2633d6e0cfc2e ||4e5a6e246cdd20f6e27ca69b53c ||40 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49688] WRONG code CFGOpt? InstCombine?
https://bugs.llvm.org/show_bug.cgi?id=49688 Juneyoung Lee changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||5207cde5cb4147155c469e18614 ||27ea9d569bd5a Resolution|--- |FIXED --- Comment #6 from Juneyoung Lee --- Fixed via https://reviews.llvm.org/rG5207cde5cb4147155c469e1861427ea9d569bd5a -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 33056 in oss-fuzz: llvm:clang-fuzzer: Use-of-uninitialized-value in clang::getConstructorInfo
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-Medium Reported-2021-04-09 Type: Bug-Security New issue 33056 by ClusterFuzz-External: llvm:clang-fuzzer: Use-of-uninitialized-value in clang::getConstructorInfo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33056 Detailed Report: https://oss-fuzz.com/testcase?key=6073296685760512 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Use-of-uninitialized-value Crash Address: Crash State: clang::getConstructorInfo ResolveConstructorOverload TryConstructorInitialization Sanitizer: memory (MSAN) Recommended Security Severity: Medium Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=202011180625 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6073296685760512 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41712] PDB GUIDs are printed with incorrect byte order.
https://bugs.llvm.org/show_bug.cgi?id=41712 Alex Orlov changed: What|Removed |Added Fixed By Commit(s)||https://github.com/llvm/llv ||m-project/commit/f47a4c0713 ||76c32d970bb26fbfca5a2fb08c1 ||64e Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassignedb...@nondot.org |aor...@accesssoftek.com CC||aor...@accesssoftek.com -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32147] shared_ptr's converting ctor from unique_ptr is incorrectly constrained.
https://bugs.llvm.org/show_bug.cgi?id=32147 Zoe Carver changed: What|Removed |Added CC||z.zoel...@gmail.com Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Zoe Carver --- Fixed by https://reviews.llvm.org/D80882. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
