[llvm-bugs] [Bug 43413] llvm-objdump should support -M intel
https://bugs.llvm.org/show_bug.cgi?id=43413 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 42250] Improve llvm-objdump help text
https://bugs.llvm.org/show_bug.cgi?id=42250 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED CC||i...@maskray.me Status|NEW |RESOLVED --- Comment #2 from Fangrui Song --- Agree that this is 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 51161] New: `-mattr` should be encoded in the IR for LTO's sake
https://bugs.llvm.org/show_bug.cgi?id=51161
Bug ID: 51161
Summary: `-mattr` should be encoded in the IR for LTO's sake
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: twd2...@gmail.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com
Created attachment 25046
--> https://bugs.llvm.org/attachment.cgi?id=25046&action=edit
The diagnostic information.
When compiling the following code with LTO:
```
$ cat test.c
void _start()
{
asm volatile (
".balign 4\n\t"
"c.nop\n\t"
".balign 4\n\t"
"c.nop"
);
}
$ clang -march=rv64imac -O2 -flto -mno-relax -c test.c
$ ld.lld test.o
```
lld fails with `unable to write nop sequence of 2 bytes`.
The diagnostic information is attached.
It looks like to be due to the `HasStdExtC` check failure in
`RISCVAsmBackend::writeNopData`.
And, if I use `ld.lld -mllvm -mattr=+c test.o`, lld can generate proper machine
code.
According to Nick Desaulniers [1], `-mattr` should be encoded in the IR for
LTO's sake.
My LLVM version: commit 1b61d837b9d0 ("[Inline] Add test for PR50589 (NFC)")
[1]
https://lore.kernel.org/linux-riscv/cakwvodmnji0abyuiosfb5cld+g7ycpxk4odupa8gtfgzymx...@mail.gmail.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 50686] [LV] expandBounds generates wrong runtime checks
https://bugs.llvm.org/show_bug.cgi?id=50686 Mindong Chen changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 51162] New: Crash in IndVarSimplify for Valid IR
https://bugs.llvm.org/show_bug.cgi?id=51162 Bug ID: 51162 Summary: Crash in IndVarSimplify for Valid IR Product: libraries Version: 12.0 Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: ad...@mayuyu.io CC: llvm-bugs@lists.llvm.org Here in our downstream project, we inject custom Transform passes at EP_ModuleOptimizerEarly, perform transforms then continue with the remaining optimizations. However I noticed for CryptoPP, a certain test case crashes LoopAnalysis despite the Transformed IR from our custom passes is valid and passes the LLVM Verifier. IR dumped just before leaving our pass could even be compiled to ObjectFile with llc. The exact crash message is following: ``` Assertion failed: (L->getLoopPreheader() && "Can't expand add recurrences without a loop preheader!"), function getAddRecExprPHILiterally, file LLVM/llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp, line 1275 1. parser at end of file 2.Per-module optimization passes 3.Running pass 'CallGraph Pass Manager' on module 'src.cpp'. 4.Running pass 'Loop Pass Manager' on function '@_ZNK8' 5.Running pass 'Induction Variable Simplification' on basic block '%for.body110' 0 clang++ 0x000103df5535 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 clang++ 0x000103df4765 llvm::sys::RunSignalHandlers() + 85 2 clang++ 0x000103df4cc0 llvm::sys::CleanupOnSignal(unsigned long) + 208 3 clang++ 0x000103d45f2a (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) + 106 4 clang++ 0x000103d460b7 CrashRecoverySignalHandler(int) + 135 5 libsystem_platform.dylib 0x7fff2055ed7d _sigtramp + 29 6 libdyld.dylib0x7fff20534473 dyldGlobalLockRelease() + 0 7 libsystem_c.dylib0x7fff2046d720 abort + 120 8 libsystem_c.dylib0x7fff2046c9d6 err + 0 9 clang++ 0x000106c11a83 llvm::SCEVExpander::getAddRecExprPHILiterally(llvm::SCEVAddRecExpr const*, llvm::Loop const*, llvm::Type*, llvm::Type*, llvm::Type*&, bool&) (.cold.1) + 35 10 clang++ 0x000103eb9643 llvm::SCEVExpander::getAddRecExprPHILiterally(llvm::SCEVAddRecExpr const*, llvm::Loop const*, llvm::Type*, llvm::Type*, llvm::Type*&, bool&) + 4259 11 clang++ 0x000103eb9bda llvm::SCEVExpander::expandAddRecExprLiterally(llvm::SCEVAddRecExpr const*) + 1066 12 clang++ 0x000103eb5f23 llvm::SCEVExpander::expand(llvm::SCEV const*) + 1027 13 clang++ 0x000103eb5aac llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*) + 28 14 clang++ 0x000103ebbc31 llvm::SCEVVisitor::visit(llvm::SCEV const*) + 193 15 clang++ 0x000103eb5f23 llvm::SCEVExpander::expand(llvm::SCEV const*) + 1027 16 clang++ 0x000103eb5aac llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*) + 28 17 clang++ 0x000103eb8c49 llvm::SCEVExpander::getAddRecExprPHILiterally(llvm::SCEVAddRecExpr const*, llvm::Loop const*, llvm::Type*, llvm::Type*, llvm::Type*&, bool&) + 1705 18 clang++ 0x000103eb9bda llvm::SCEVExpander::expandAddRecExprLiterally(llvm::SCEVAddRecExpr const*) + 1066 19 clang++ 0x000103eb5f23 llvm::SCEVExpander::expand(llvm::SCEV const*) + 1027 20 clang++ 0x000103eb5aac llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*) + 28 21 clang++ 0x000103eb9794 llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*, llvm::Instruction*) + 148 22 clang++ 0x000103b3969a (anonymous namespace)::IndVarSimplify::run(llvm::Loop*) + 8522 23 clang++ 0x000103b463c7 (anonymous namespace)::IndVarSimplifyLegacyPass::runOnLoop(llvm::Loop*, llvm::LPPassManager&) + 951 24 clang++ 0x0001030ee209 llvm::LPPassManager::runOnFunction(llvm::Function&) + 1513 25 clang++ 0x0001036afe41 llvm::FPPassManager::runOnFunction(llvm::Function&) + 1073 26 clang++ 0x000102ff4534 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) + 1540 27 clang++ 0x0001036b049f llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1103 28 clang++ 0x00010407b653 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr >) + 15075 29 clang++ 0x0001043456fb clang::BackendConsumer::HandleTranslationUnit(clang::ASTCont
[llvm-bugs] [Bug 51163] New: IR code with bool as return type generates binary may return 255 as true value, which causes UB in C++
https://bugs.llvm.org/show_bug.cgi?id=51163
Bug ID: 51163
Summary: IR code with bool as return type generates binary may
return 255 as true value, which causes UB in C++
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mo_xiao_m...@yahoo.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Hello,
I've been playing with the IR code and JIT recently, and noticed something
weird and can be reproduced by llc as well
For the following IR, which simple compares a array of data to 41 and 42, and
returns the result in boolean(i1)
@0 = internal constant <{ i32, i32 }> <{ i32 41, i32 42 }>, align 1
define i1 @"/.t19709"() {
entry:
%0 = load i32, i32* getelementptr inbounds (<{ i32, i32 }>, <{ i32, i32 }>*
@0, i32 0, i32 0), align 4
%1 = load i32, i32* getelementptr inbounds (<{ i32, i32 }>, <{ i32, i32 }>*
@0, i32 0, i32 1), align 4
%t = icmp eq i32 %0, 41
%t1 = icmp eq i32 %1, 42
%2 = select i1 %t, i1 %t1, i1 false
%. = select i1 %2, i1 true, i1 false
ret i1 %.
}
However, the code generated by > LLVM8 and <=LLVM8 are different,
https://godbolt.org/z/hrze61e8e
>From LLMV9 to trunk, if comparison succeed, the extra `neg` which make %al to
have value 255
0x779b2000: endbr64
0x779b2004: movabs $0x779b3000,%rax
0x779b200e: mov(%rax),%ecx# ecx = 41
0x779b2010: mov0x4(%rax),%eax # eax = 42
0x779b2013: xor$41,%ecx # ecx = 0
0x779b2016: xor$42,%eax # eax = 0
0x779b2019: or %ecx,%eax # eax = 0
0x779b201b: sete %al# al = 1
0x779b201e: neg%al# al = (0-1) = 255
0x779b2020: retq
and 255 is not a valid boolean value for gcc and clang, this kind of return
value causes all sorts of strange behaviors in my C++ code
--
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 51164] New: ICE: clang crash in clang::ASTContext::getFunctionTypeInternal(clang::QualType, llvm::ArrayRef, clang::FunctionProtoType::ExtProtoInfo const&, bool)
https://bugs.llvm.org/show_bug.cgi?id=51164
Bug ID: 51164
Summary: ICE: clang crash in
clang::ASTContext::getFunctionTypeInternal(clang::Qual
Type, llvm::ArrayRef,
clang::FunctionProtoType::ExtProtoInfo const&, bool)
Product: clang
Version: 8.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: czktc2...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Reproducable code:
https://godbolt.org/z/9r3d1jTxq
Fails on 6.x/7.x/8.x, OK on 9.x and newer.
Crash output:
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-8.0.1/bin/clang-8 -cc1
-triple x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name example.cpp -mrelocation-model static
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-dwarf-column-info -debug-info-kind=limited -dwarf-version=4
-debugger-tuning=gdb -coverage-notes-file /app/output.gcno -resource-dir
/opt/compiler-explorer/clang-8.0.1/lib/clang/8.0.1 -isystem
/opt/compiler-explorer/libs/boost_1_76_0 -internal-isystem
/opt/compiler-explorer/gcc-8.3.0/lib/gcc/x86_64-linux-gnu/8.3.0/../../../../include/c++/8.3.0
-internal-isystem
/opt/compiler-explorer/gcc-8.3.0/lib/gcc/x86_64-linux-gnu/8.3.0/../../../../include/c++/8.3.0/x86_64-linux-gnu
-internal-isystem
/opt/compiler-explorer/gcc-8.3.0/lib/gcc/x86_64-linux-gnu/8.3.0/../../../../include/c++/8.3.0/backward
-internal-isystem /usr/local/include -internal-isystem
/opt/compiler-explorer/clang-8.0.1/lib/clang/8.0.1/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-std=c++17 -fdeprecated-macro -fdebug-compilation-dir /app -ferror-limit 19
-fmessage-length 0 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -mllvm --x86-asm-syntax=intel -o
/app/output.s -x c++ -faddrsig
1. :67:1: current parser token '{'
#0 0x562afc9c6d2a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x243fd2a)
#1 0x562afc9c4ce4 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x243dce4)
#2 0x562afc9c4e22 SignalHandler(int)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x243de22)
#3 0x7f33ac3483c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x562afe52754e
clang::ASTContext::getFunctionTypeInternal(clang::QualType,
llvm::ArrayRef, clang::FunctionProtoType::ExtProtoInfo const&,
bool) const (/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3fa054e)
#5 0x562afe52800a
clang::ASTContext::getFunctionTypeWithExceptionSpec(clang::QualType,
clang::FunctionProtoType::ExceptionSpecInfo const&)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3fa100a)
#6 0x562afe52820f
clang::ASTContext::adjustExceptionSpec(clang::FunctionDecl*,
clang::FunctionProtoType::ExceptionSpecInfo const&, bool)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3fa120f)
#7 0x562afe0ae5a1 clang::Sema::UpdateExceptionSpec(clang::FunctionDecl*,
clang::FunctionProtoType::ExceptionSpecInfo const&)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3b275a1)
#8 0x562afe3b558e clang::Sema::SubstExceptionSpec(clang::FunctionDecl*,
clang::FunctionProtoType const*, clang::MultiLevelTemplateArgumentList const&)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3e2e58e)
#9 0x562afe3d5fae
clang::TemplateDeclInstantiator::InitFunctionInstantiation(clang::FunctionDecl*,
clang::FunctionDecl*)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3e4efae)
#10 0x562afe3d62b6
clang::TemplateDeclInstantiator::InitMethodInstantiation(clang::CXXMethodDecl*,
clang::CXXMethodDecl*)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3e4f2b6)
#11 0x562afe3df38d
clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*,
clang::TemplateParameterList*, bool)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3e5838d)
#12 0x562afe3dc44d clang::Sema::SubstDecl(clang::Decl*,
clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3e5544d)
#13 0x562afe396483
clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*,
llvm::SmallVectorImpl&, unsigned int,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&,
llvm::SmallVectorImpl const*, bool,
llvm::function_ref)
(/opt/compiler-explorer/clang-8.0.1/bin/clang-8+0x3e0f483)
#14 0x562afe397666
clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*,
[llvm-bugs] [Bug 51165] New: [AMDGPU][GFX908][GFX90A][DOC] Incorrect description of src2 MFMA
https://bugs.llvm.org/show_bug.cgi?id=51165 Bug ID: 51165 Summary: [AMDGPU][GFX908][GFX90A][DOC] Incorrect description of src2 MFMA Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: d-...@mail.ru CC: llvm-bugs@lists.llvm.org ival operands cannot be used as src2 of mfma instructions. However, the description of src2 refers constant which includes ival. For example, see the description of v_mfma_f32_16x16x16f16 at https://llvm.org/docs/AMDGPU/AMDGPUAsmGFX90a.html#vop3p: Operands: v, a, constant -- 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 49787] Codegen for calling __tgt_target_teams_nowait_mapper has too few arguments
https://bugs.llvm.org/show_bug.cgi?id=49787 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||b455f7f22564a096c043b02fa15 ||9ab16669c121c --- Comment #3 from Alexey Bataev --- Fixed in b455f7f22564a096c043b02fa159ab16669c121c -- 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 36437 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::CreateStoredDeclsMap
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-07-22 Type: Bug New issue 36437 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::CreateStoredDeclsMap https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36437 Detailed Report: https://oss-fuzz.com/testcase?key=5395728074670080 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff2a945db0 Crash State: clang::DeclContext::CreateStoredDeclsMap clang::DeclContext::makeDeclVisibleInContextImpl clang::DeclContext::buildLookupImpl 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=5395728074670080 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 49108] clang-tidy crash on std::chrono::operator<=>
https://bugs.llvm.org/show_bug.cgi?id=49108 Artem Dergachev changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Artem Dergachev --- The original bug is fixed. *** This bug has been marked as a duplicate of bug 47511 *** -- 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 47768] clang-tidy crashes with segmentation fault when using consistent comparison operator for std::chrono::duration
https://bugs.llvm.org/show_bug.cgi?id=47768 Artem Dergachev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Artem Dergachev --- The original bug is fixed. *** This bug has been marked as a duplicate of bug 47511 *** -- 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 26336] Clang allows address of array with 'register' storage-class to be taken
https://bugs.llvm.org/show_bug.cgi?id=26336 Aaron Ballman changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Aaron Ballman --- This is now fixed in 178c2b4c1eb12b2153adb384ac7f22a8791edc86. -- 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 51163] IR function with bool as return type generates binary may return 255 as true value, which causes UB in C++
https://bugs.llvm.org/show_bug.cgi?id=51163 Eli Friedman changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED CC||efrie...@quicinc.com --- Comment #1 from Eli Friedman --- You can write "define zeroext i1 @f()" if you want the return value zero-extended. (This is how clang lowers a function that returns a boolean.) -- 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 51171] New: SIGSEGV at DeduceTemplateArgumentsByTypeMatch
https://bugs.llvm.org/show_bug.cgi?id=51171
Bug ID: 51171
Summary: SIGSEGV at DeduceTemplateArgumentsByTypeMatch
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: ivan.muras...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 25049
--> https://bugs.llvm.org/attachment.cgi?id=25049&action=edit
The crash reproducer
There is a SIGSEGV (NULL dereference) at DeduceTemplateArgumentsByTypeMatch as
soon as FunctionType parameter passed into the function is NULL. See reproducer
at the attachment
The possible fix for the problem is
--- a/clang/lib/Sema/SemaTemplateDeduction.cpp
+++ b/clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -4346,7 +4346,7 @@ Sema::TemplateDeductionResult
Sema::DeduceTemplateArguments(
HasDeducedReturnType = true;
}
- if (!ArgFunctionType.isNull()) {
+ if (!ArgFunctionType.isNull() && !FunctionType.isNull()) {
unsigned TDF =
TDF_TopLevelParameterTypeList | TDF_AllowCompatibleFunctionType;
// Deduce template arguments from the function type.
--
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 34994] sqrt(denormal float) gives -infinity with fast-math
https://bugs.llvm.org/show_bug.cgi?id=34994 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |spatel+l...@rotateright.com CC||i...@maskray.me --- Comment #19 from Fangrui Song --- Mark as fixed. x86-64 and aarch64 % for i in ieee preserve-sign positive-zero; do clang++ a.cc -ffast-math -fdenormal-fp-math=$i && ./a.out; done sqrt(1.0005e-34) = 9.9984e-18 sqrt(1.0004e-36) = 1.0005e-18 sqrt(0) = 0 sqrt(0) = 0 sqrt(0) = 0 sqrt(0) = 0 sqrt(0) = 0 sqrt(1.0005e-34) = 9.9984e-18 sqrt(1.0004e-36) = 1.0005e-18 sqrt(0) = 0 sqrt(0) = 0 sqrt(0) = 0 sqrt(0) = 0 sqrt(0) = 0 sqrt(1.0005e-34) = 9.9984e-18 sqrt(1.0004e-36) = 1.0005e-18 sqrt(0) = 0 sqrt(0) = 0 sqrt(0) = 0 sqrt(0) = 0 sqrt(0) = 0 ppc64le (POWER9) sqrt(1.0005e-34) = 9.9984e-18 sqrt(1.0004e-36) = 1.0005e-18 sqrt(9.9935e-39) = 9.9968e-20 sqrt(9.461e-41) = 9.7303e-21 sqrt(1.0005271e-42) = 1.00026351e-21 sqrt(9.80908925e-45) = 9.90408493e-23 sqrt(0) = 0 sqrt(1.0005e-34) = 9.9984e-18 sqrt(1.0004e-36) = 1.0005e-18 sqrt(9.9935e-39) = 9.9968e-20 sqrt(9.461e-41) = 9.7303e-21 sqrt(1.0005271e-42) = 1.00026351e-21 sqrt(9.80908925e-45) = 9.90408493e-23 sqrt(0) = 0 sqrt(1.0005e-34) = 9.9984e-18 sqrt(1.0004e-36) = 1.0005e-18 sqrt(9.9935e-39) = 9.9968e-20 sqrt(9.461e-41) = 9.7303e-21 sqrt(1.0005271e-42) = 1.00026351e-21 sqrt(9.80908925e-45) = 9.90408493e-23 sqrt(0) = 0 The input constants the 3 arches use are the same. -- 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 51172] New: Multiple calls to llvm.prefetch.p0i8 on aarch64 can cause apparently-unnecessary register spills
https://bugs.llvm.org/show_bug.cgi?id=51172 Bug ID: 51172 Summary: Multiple calls to llvm.prefetch.p0i8 on aarch64 can cause apparently-unnecessary register spills Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: s...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Steps to repeat: (1) See enclosed file prefetch.ll -- notice that there are several calls to `@llvm.prefetch.p0i8`, with all but the first commented out (2) Compile to aarch64 assembly with llc -march=aarch64 ~/prefetch.ll -o - -O3 -mattr=+dotprod > ~/prefetch.s (3) Examine output, search for `prfm`, see block similar to ``` add x27, x26, x16 prfmpldl1strm, [x27] ldr q28, [x27] ldp q8, q29, [x12, #-32] ldr q31, [x28, x16] ldr q10, [x29, x16] ldr q11, [x30, x16] ldr q12, [x8, x16] ldp q9, q30, [x18, #-32] udotv26.4s, v8.16b, v28.4b[0] udotv24.4s, v8.16b, v31.4b[0] udotv22.4s, v8.16b, v10.4b[0] udotv20.4s, v8.16b, v11.4b[0] udotv18.4s, v8.16b, v12.4b[0] ``` (4) Edit prefetch.ll to uncomment the call to `llvm.prefetch.p0i8` on line 459, re-run llc (5) Search for `prfm` again, and note that the start of the block now contains numerous vector-register spills that appear to be completely unnecessary: ``` add x27, x26, x16 prfmpldl1strm, [x27] ldp q31, q30, [x18] ldr q0, [x12] ldr q1, [x27] str q30, [sp, #496] // 16-byte Folded Spill ldr q30, [x21] str q0, [sp, #400] // 16-byte Folded Spill ldr q0, [x12, #16] add x27, x28, x16 stp q31, q30, [sp, #416]// 32-byte Folded Spill ldr q30, [x21, #16] ldp q11, q29, [x12, #-32] str q0, [sp, #512] // 16-byte Folded Spill ldp q10, q0, [x18, #-32] str q30, [sp, #480] // 16-byte Folded Spill ldp q30, q31, [x14, #-32] ldp q8, q15, [x21, #-32] udotv17.4s, v10.16b, v1.4b[0] udotv17.4s, v0.16b, v1.4b[1] str q31, [sp, #384] // 16-byte Folded Spill ldr q31, [x14] udotv16.4s, v30.16b, v1.4b[0] udotv26.4s, v11.16b, v1.4b[0] udotv26.4s, v29.16b, v1.4b[1] str q31, [sp, #448] // 16-byte Folded Spill ldr q31, [x14, #16] udotv27.4s, v8.16b, v1.4b[0] udotv27.4s, v15.16b, v1.4b[1] subsx20, x20, #1// =1 str q31, [sp, #464] // 16-byte Folded Spill prfmpldl1strm, [x27] ldr q9, [x27] ldr q31, [x29, x16] ldr q12, [x30, x16] ldr q13, [x8, x16] udotv2.4s, v10.16b, v9.4b[0] udotv3.4s, v10.16b, v31.4b[0] udotv14.4s, v10.16b, v12.4b[0] udotv4.4s, v10.16b, v13.4b[0] udotv2.4s, v0.16b, v9.4b[1] udotv3.4s, v0.16b, v31.4b[1] udotv14.4s, v0.16b, v12.4b[1] udotv4.4s, v0.16b, v13.4b[1] ``` These spills don't seem to make any sense: the only instruction that should have been added here was the second `prfm` instruction, and it doesn't depend on any of the vector registers being spilled and reloaded. Is something about `prefetch` affecting this (e.g., confusing the lifetime analysis for registers loaded from the prefetch location)? -- 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 51173] New: wasm-ld: stack corruption due to limited unsafe stack size
https://bugs.llvm.org/show_bug.cgi?id=51173 Bug ID: 51173 Summary: wasm-ld: stack corruption due to limited unsafe stack size Product: lld Version: 12.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: wasm Assignee: unassignedb...@nondot.org Reporter: shrava...@gmail.com CC: llvm-bugs@lists.llvm.org, s...@chromium.org Hi, We are using Wasm to sandbox libraries in the Mozilla Firefox browser and ran into an issue when running one of our compiled libraries to Wasm. It looks like wasm-ld allocates a 64K unsafe wasm stack (the portion of the C stack that is moved in to wasm linear memory due to use of pointer arithmetic). While this works well in most of the cases, we recently ran into a library that uses more space than this, when compiled at O0 (it uses less space on the unsafe stack when the C code is optimized) At this time, it looks like there is no way to change the threshold in wasm-ld. it would be nice to add a flag to allow for a larger stack size (I also tried using --stack-first and --global-base together as an indirect way to get the desired behavior) but this doesn't work Beyond the basic stack size issue, I do want to point out there is potentially a more pressing issue here --- compiling code to wasm that needs more unsafe stack space than available does not immediately crash. Instead, it starts silently overwriting other portions of linear memory, and this eventually leads to a crash. This is problematic as this behavior tends to look like a very random crash and is hard to diagnose especially for novel users. I believe beyond the flag to specify the custom size of the stack, one of three things may need to be done 1) Implement the --stack-first behavior by default: Right now C globals are placed in linear memory prior to the unsafe stack which means underflow of the unsafe stack will clobber the C globals silently. --stack-first will mean that an underflow of the stack will wrap around and likely cause bounds check failures (assuming the wasm module isn't using all 4GB of linear memory) 2) Implement bounds checks on unsafe stack expansion: Although this is perhaps something that needs to be done at the codegen level? Additionally, I am not sure what the performance impact of this approach would be. For the moment I am manually expanding the unsafe stack to a larger allocation, but it would be nice to have a better fix. -- 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 51174] New: error __float128 not supported on P9 when building OpenMP
https://bugs.llvm.org/show_bug.cgi?id=51174 Bug ID: 51174 Summary: error __float128 not supported on P9 when building OpenMP Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: xw111lu...@gmail.com CC: llvm-bugs@lists.llvm.org On Summit, RHEL P9 little endian. When build OPENMP as runtime, Clang complains about __float128 whe building archer and libomptarget. In file included from /ccs/home/yeluo/opt/llvm-clang/llvm-project/openmp/tools/archer/ompt-tsan.cpp:17: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/algorithm:60: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/utility:70: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/stl_pair.h:59: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/move.h:55: /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/type_traits:347:39: error: __float128 is not supported on this target struct __is_floating_point_helper<__float128> ^ In file included from /ccs/home/yeluo/opt/llvm-clang/llvm-project/openmp/libomptarget/plugins/common/elf_common/elf_common.cpp:12: In file included from /ccs/home/yeluo/opt/llvm-clang/llvm-project/openmp/libomptarget/plugins/common/elf_common/elf_common.h:16: In file included from /ccs/home/yeluo/opt/llvm-clang/llvm-project/openmp/libomptarget/include/omptargetplugin.h:17: In file included from /ccs/home/yeluo/opt/llvm-clang/llvm-project/openmp/libomptarget/include/omptarget.h:17: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/deque:60: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/stl_algobase.h:64: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/stl_pair.h:59: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/move.h:55: /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/type_traits:347:39: error: __float128 is not supported on this target struct __is_floating_point_helper<__float128> ^ In file included from /ccs/home/yeluo/opt/llvm-clang/llvm-project/openmp/libomptarget/src/api.cpp:13: In file included from /ccs/home/yeluo/opt/llvm-clang/llvm-project/openmp/libomptarget/src/device.h:18: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/list:60: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/stl_algobase.h:64: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/stl_pair.h:59: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/move.h:55: /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/type_traits:347:39: error: __float128 is not supported on this target struct __is_floating_point_helper<__float128> ^ In file included from /ccs/home/yeluo/opt/llvm-clang/llvm-project/openmp/tools/archer/ompt-tsan.cpp:17: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/algorithm:60: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/utility:70: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/stl_pair.h:59: In file included from /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/bits/move.h:55: /sw/summit/gcc/8.1.1/lib/gcc/powerpc64le-unknown-linux-gnu/8.1.1/../../../../include/c++/8.1.1/type_traits:347:39: error: __float128 is not supported on this target struct __is_floating_point_helper<__float128> ^ -- 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 51173] wasm-ld: silent linear memory corruption due to limited unsafe stack size
https://bugs.llvm.org/show_bug.cgi?id=51173 Shravan Narayan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Shravan Narayan --- Thanks for the quick response Sam! ( (In reply to Sam Clegg from comment #1) > Pretty exciting to hear you are wasm inside of FF! > > You can control the size of the stack using `-z stack-size=XXX`. Oh fantastic! Just tried it out and it works great! :) > The main reason for putting global data first is that it can result in > slightly smaller binaries since references to global data in the code we > produce shorter instructions (`i32.const X`) when LEB encoded (Unlike stack > addresses which are not absolute and don't appear in the code like this). Ah I see, that makes sense! Just thinking out loud, I wonder if the right balance would be to use --stack-first by default, but to disable this when compiling this with "-Os". My thinking here is that for AOT compiled use cases (such as ours), Wasm binary size is not a factor, but I definitely recognize that is not the case for many of Wasm's current uses > In terms of adding more checks, in emscripten we have the > STACK_OVERFLOW_CHECK settings: > > https://github.com/emscripten-core/emscripten/blob/ > cef2313504f38d019544b1c24214b9b27b804b5e/src/settings.js#L68-L79 > > This in turn is powered by a binaryen pass which can be run on any wasm > binary to annotate stack accesses: > https://github.com/WebAssembly/binaryen/blob/main/src/passes/StackCheck.cpp Oh cool! I'll have a closer look at binaryen's options as well. May come in handy for other things (Wasn't sure what status to close the bug since the size flag exists and the layout is the way it is for a reason. I have closed the bug with invalid, please feel free to adjust. ) -- 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 51175] New: wrong code at -O3 on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=51175
Bug ID: 51175
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: qrzh...@gatech.edu
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
It appears to be a latent issue. It affects all versions since clang-7.
$ clang-trunk -v
clang version 13.0.0 (https://github.com/llvm/llvm-project.git
599b2f00370ee79e812d2776f2af57fae36d02e9)
$ clang-trunk abc.c ; ./a.out
4
$ clang-trunk -O3 abc.c ; ./a.out
0
$ clang-7 -O3 abc.c ; ./a.out
0
$ cat abc.c
short a = -1;
short c = 4;
int b;
int main() {
char d;
b = 65527 & ++a;
d = 0 == 0 ? b : 0;
if (d)
c = 0;
printf("%d\n", 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
