[llvm-bugs] [Bug 46513] New: [Dead Store Elimination] Assertion "Should not hit the entry block because SI must be dominated by LI" failed.
https://bugs.llvm.org/show_bug.cgi?id=46513 Bug ID: 46513 Summary: [Dead Store Elimination] Assertion "Should not hit the entry block because SI must be dominated by LI" failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 23657 --> https://bugs.llvm.org/attachment.cgi?id=23657&action=edit reduced testcase opt -mtriple=s390x-linux-gnu -mcpu=z13 -O3 tc_dse_entryblock.ll -enable-dse-memoryssa llvm-project/llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp:688: bool memoryIsNotModifiedBetween(llvm::Instruction*, llvm::Instruction*, llvm::AliasAnalysis*, const llvm::DataLayout&, llvm::DominatorTree*): Assertion `B != &FirstBB->getParent()->getEntryBlock() && "Should not hit the entry block because SI must be dominated by LI"' failed. ... #11 0x02aa3936fd28 (anonymous namespace)::DSELegacyPass::runOnFunction -- 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 46514] New: clang does not emit debug info for declaration
https://bugs.llvm.org/show_bug.cgi?id=46514
Bug ID: 46514
Summary: clang does not emit debug info for declaration
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: vr...@gcc.gnu.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Consider the following test-case from the gdb testsuite:
...
$ cat psym-external-decl.c
extern int aaa;
int
main (void)
{
return aaa;
}
$ cat psym-external-decl-2.c
int aaa = 33;
...
Run with script compile.sh:
...
$ cat compile.sh
#!/bin/sh
$cc -c -g psym-external-decl.c
$cc -c psym-external-decl-2.c
$cc -g psym-external-decl.o psym-external-decl-2.o
gdb -batch a.out -ex "ptype aaa" -ex "p aaa"
...
With gcc, we have:
...
$ cc=gcc ./compile.sh
type = int
$1 = 33
...
And with clang-10:
...
$ cc=clang-10 ./compile.sh
type =
'aaa' has unknown type; cast it to its declared type
...
The difference is caused by missing debug info for the declaration of aaa in
psym-external-decl.c.
That is, with gcc, we have:
...
$ readelf -wi psym-external-decl.o | grep aaa
<2e> DW_AT_name: aaa
$
...
and with clang:
...
$ readelf -wi psym-external-decl.o | grep aaa
$
...
Is this a missing feature in clang, or is this explicitly unsupported?
--
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 46515] New: Call abort() instead of exit() on runtime error
https://bugs.llvm.org/show_bug.cgi?id=46515 Bug ID: 46515 Summary: Call abort() instead of exit() on runtime error Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: gcc.j.kell...@hzdr.de CC: llvm-bugs@lists.llvm.org While debugging a openmp target usage inside a complex program, I found, that libomptarget calls exit() when it encounters a runtime error, which in my case causes a deadlock instead of program termination. Specifically, I am seeing the error message: "Libomptarget fatal error 1: failure of target construct while offloading is mandatory" after which the program is hangs in a deadlock instead of terminating. I suggest to change this to call abort() instead of exit(). The rationale is the situation in the program I an working on. # Rationale The program implements a queue to run kernels on backends, one of which is based on OpenMP target offload. In my case I am using a synchronous queue, in which case, a function A() calling a function B() containing an omp target region holds a mutex lock on the queue within its scope (std::lock_guard) (effectively while B() is executing). Another component of the program registers the same queue in a global object. That objects destructor is responsible for clearing destructing the queue before program termination. Part of this is synchronizing the queue, which requires the mutex held by A() to be locked. When exit() is called inside B(), the stack is not unwound, i.e. the lock held by A() is not released, but the destructors of global objects like that queue wrapper are called, which causes a dead lock. This could be avoided by calling abort() on runtime errors instead. -- 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 46516] New: ICE in Sema/SemaDecl.cpp
https://bugs.llvm.org/show_bug.cgi?id=46516
Bug ID: 46516
Summary: ICE in Sema/SemaDecl.cpp
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: tangyix...@mail.dlut.edu.cn
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Hi, clang++ falls on this case, while g++ is ok, please consider:
$: cat s.C
#ifdef __SIZEOF_INT128__
enum A { A1 = (__uint128_t)-1} a;
#endif
$: clang++ -std=c++2a -c s.C
clang-9: /home/oscar/compiler/llvm-project/clang/lib/Sema/SemaDecl.cpp:17512:
void clang::Sema::ActOnEnumBody(clang::SourceLocation, clang::SourceRange,
clang::Decl*, llvm::ArrayRef, clang::Scope*, const
clang::ParsedAttributesView&): Assertion `NumPositiveBits <= BestWidth && "How
could an initializer get larger than ULL?"' failed.
Stack dump:
0. Program arguments: /home/oscar/compiler/llvm-project/build/bin/clang-9
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-main-file-name s.C -mrelocation-model static -mthread-model posix
-mframe-pointer=all -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info
-debugger-tuning=gdb -resource-dir
/home/oscar/compiler/llvm-project/build/lib/clang/10.0.0 -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/backward
-internal-isystem /usr/local/include -internal-isystem
/home/oscar/compiler/llvm-project/build/lib/clang/10.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-std=c++2a -fdeprecated-macro -fdebug-compilation-dir
/media/oscar/xuaner1/autogeneration/testsuitC++/bugreports/clang -ferror-limit
19 -fmessage-length 0 -fgnuc-version=4.2.1 -fno-implicit-modules
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -faddrsig -o s.o -x c++ s.C
1. s.C:2:32: current parser token 'a'
#0 0x5647324b405f llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/oscar/compiler/llvm-project/llvm/lib/Support/Unix/Signals.inc:544:0
#1 0x5647324b40f2 PrintStackTraceSignalHandler(void*)
/home/oscar/compiler/llvm-project/llvm/lib/Support/Unix/Signals.inc:605:0
#2 0x5647324b1f55 llvm::sys::RunSignalHandlers()
/home/oscar/compiler/llvm-project/llvm/lib/Support/Signals.cpp:68:0
#3 0x5647324b39ea SignalHandler(int)
/home/oscar/compiler/llvm-project/llvm/lib/Support/Unix/Signals.inc:391:0
#4 0x7fc8985ea890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#5 0x7fc8976e2e97 raise (/lib/x86_64-linux-gnu/libc.so.6+0x3ee97)
#6 0x7fc8976e4801 abort (/lib/x86_64-linux-gnu/libc.so.6+0x40801)
#7 0x7fc8976d439a (/lib/x86_64-linux-gnu/libc.so.6+0x3039a)
#8 0x7fc8976d4412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412)
#9 0x56473511c5e8 clang::Sema::ActOnEnumBody(clang::SourceLocation,
clang::SourceRange, clang::Decl*, llvm::ArrayRef, clang::Scope*,
clang::ParsedAttributesView const&)
/home/oscar/compiler/llvm-project/clang/lib/Sema/SemaDecl.cpp:17513:0
#10 0x564734e95df7 clang::Parser::ParseEnumBody(clang::SourceLocation,
clang::Decl*)
/home/oscar/compiler/llvm-project/clang/lib/Parse/ParseDecl.cpp:4747:0
#11 0x564734e951a5 clang::Parser::ParseEnumSpecifier(clang::SourceLocation,
clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&,
clang::AccessSpecifier, clang::Parser::DeclSpecContext)
/home/oscar/compiler/llvm-project/clang/lib/Parse/ParseDecl.cpp:4612:0
#12 0x564734e923f4
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
/home/oscar/compiler/llvm-project/clang/lib/Parse/ParseDecl.cpp:3870:0
#13 0x564734e6cf78
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
/home/oscar/compiler/llvm-project/clang/lib/Parse/Parser.cpp:1006:0
#14 0x564734e6d59f
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier)
/home/oscar/compiler/llvm-project/clang/lib/Parse/Parser.cpp::0
#15 0x564734e6caff
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*)
/home/oscar/compiler/llvm-project/clang/lib/
[llvm-bugs] [Bug 45998] volatile lead to inconsistent behaviors between step-by-step and stepi-by-stepi in lldb
https://bugs.llvm.org/show_bug.cgi?id=45998 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |WONTFIX --- Comment #5 from lab...@google.com --- I agree with Jim's analysis. Closing as working-as-intended. If you're using some sort of automated tool to generate these test cases, maybe you could teach it to ignore/coalesce the source-level stops that don't actually end up moving the program counter? -- 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 45988] SBValue.GetNumChildren() returns wrong value for double indirections
https://bugs.llvm.org/show_bug.cgi?id=45988 lab...@google.com changed: What|Removed |Added Fixed By Commit(s)||83bd2c4a0680 Status|NEW |RESOLVED Resolution|--- |FIXED CC||lab...@google.com --- Comment #4 from lab...@google.com --- Fixed by 83bd2c4a0680. -- 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 45853] lldb:buggy expression unit test
https://bugs.llvm.org/show_bug.cgi?id=45853 lab...@google.com changed: What|Removed |Added CC||lab...@google.com Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||d3fa894beaa5 --- Comment #3 from lab...@google.com --- Fixed by d3fa894beaa5. -- 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 44579] Swift Framework returns 'ambiguous use of' method extension in lldb
https://bugs.llvm.org/show_bug.cgi?id=44579 lab...@google.com changed: What|Removed |Added CC||lab...@google.com Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from lab...@google.com --- Closing per #1. -- 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 44078] llvm build fail on mac os 10.11.6
https://bugs.llvm.org/show_bug.cgi?id=44078 lab...@google.com changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||lab...@google.com --- Comment #1 from lab...@google.com --- *** This bug has been marked as a duplicate of bug 44075 *** -- 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 44075] New: llvm build fail on mac os 10.11.6
https://bugs.llvm.org/show_bug.cgi?id=44075 Bug ID: 44075 Summary: llvm build fail on mac os 10.11.6 Product: lldb Version: 9.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: lk...@hdm-stuttgart.de CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org i cannot install llvm 9.0.0 on mac os 10.11.6: /tmp/llvm-20191120-51054-19joaqd/llvm-9.0.0.src/tools/lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp:112:17: error: no matching function for call to 'next' auto parent = std::next(rev_it); ^ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iterator:521:25: note: candidate template ignored: disabled by 'enable_if' [with _ForwardIter = llvm::sys::path::reverse_iterator] typename enable_if<__is_forward_iterator<_ForwardIter>::value>::type* = 0) ^ 1 error generated. --- Comment #1 from lab...@google.com --- *** Bug 44078 has been marked as a duplicate of this bug. *** -- 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 46518] New: Failure to vectorize a std::find across a dereferencable array
https://bugs.llvm.org/show_bug.cgi?id=46518
Bug ID: 46518
Summary: Failure to vectorize a std::find across a
dereferencable array
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: florian_h...@apple.com, lebedev...@gmail.com,
llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com
#include
#include
bool findme(const std::array &db, int key) {
return std::find(db.begin(), db.end(), key) != db.end();
}
https://godbolt.org/z/rdWStD
We end up with a full cmp+branch tree when we could very efficiently use a
vector comparison followed by an anyof reduction.
--
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 22973 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::Lex
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 22973 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::Lex https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22973#c1 ClusterFuzz testcase 5721742692843520 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202006290157:202006300157 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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] Issue 23742 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 23742 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23742#c1 ClusterFuzz testcase 5654726678151168 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202006290157:202006300157 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 46519] New: Copy elision is not performed for objects with non overlapping lifetimes
https://bugs.llvm.org/show_bug.cgi?id=46519
Bug ID: 46519
Summary: Copy elision is not performed for objects with non
overlapping lifetimes
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: antosh...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Consider the example:
struct widget {
widget();
widget(widget&&);
};
// Inspired by https://wg21.link/p2025
widget test(int i) {
{
widget w1;
if (i == 1) return w1;
}
widget w2;
return w2;
}
Lifetimes of w1 and w2 do not overlap and it is possible to elide the move
constructor by constructing w1 and w2 at the same destination address.
Godbolt playground: https://godbolt.org/z/BZPgwi
--
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 46522] New: [DWARF] Template instance name not consistent with CodeView.
https://bugs.llvm.org/show_bug.cgi?id=46522
Bug ID: 46522
Summary: [DWARF] Template instance name not consistent with
CodeView.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: international.phan...@gmail.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
For the given test:
//--
template
struct S {
};
S SS;
//--
The name generated for the template instance, is not consistent between clang
(DWARF) and clang (CodeView), making search or compare difficult.
Clang (DWARF): 'S' <-- Added space
Clang (CodeView): 'S'
GCC (DWARF): 'S'
MSVC (CodeView): 'S'
Clang (DWARF) adds a space between arguments.
Clang (CodeView) does not add any spaces.
--
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 44574] [NewPM] SpeculativeExecutionPass is run on all targets
https://bugs.llvm.org/show_bug.cgi?id=44574 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||1a6cebb4d12c744699e CC||dfuka...@gmail.com, ||matthew.arsena...@amd.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Sanjay Patel --- https://reviews.llvm.org/D82735 https://reviews.llvm.org/rG1a6cebb4d12c744699e23624f8afda5cbe216fe6 I don't have a real test for this, but I updated the test where I first noticed the bug: https://github.com/llvm/llvm-project/commit/09b8dbf70c1 -- 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 23811 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !isAnnotation() && "getIdentifierInfo() on an annotation token!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-06-30 Type: Bug New issue 23811 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: !isAnnotation() && "getIdentifierInfo() on an annotation token!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23811 Detailed Report: https://oss-fuzz.com/testcase?key=6272535493869568 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !isAnnotation() && "getIdentifierInfo() on an annotation token!" clang::Token::getIdentifierInfo clang::Parser::ParseParameterDeclarationClause Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202004080255:202004090022 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6272535493869568 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 46523] New: rG42f488b63a04 breaks arm64 kernel build with ThinLTO
https://bugs.llvm.org/show_bug.cgi?id=46523
Bug ID: 46523
Summary: rG42f488b63a04 breaks arm64 kernel build with ThinLTO
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: spatel+l...@rotateright.com
Reporter: samitolva...@google.com
CC: llvm-bugs@lists.llvm.org, ndesaulni...@google.com
Created attachment 23658
--> https://bugs.llvm.org/attachment.cgi?id=23658&action=edit
kernel configuration
Commit 42f488b63a04fdaa931315bdadecb6d23e20529a ("[InstCombine] improve
matching for sext-lshr-trunc patterns") breaks the arm64 Linux kernel build
with ThinLTO.
Steps to reproduce:
$ git clone https://github.com/samitolvanen/linux.git
$ cd linux
$ git checkout origin/clang-lto
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LLVM=1 defconfig
$ ./scripts/config -e LTO_CLANG -e NFP -e BPF_SYSCALL
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LLVM=1 olddefconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LLVM=1 -j110
...
LD .tmp_vmlinux.kallsyms1
ld.lld: error: undefined symbol: __compiletime_assert_900
>>> referenced by jit.c:653 (drivers/net/ethernet/netronome/nfp/bpf/jit.c:653)
>>> vmlinux.o:(jeq_imm.llvm.9259135780514890817
make: *** [Makefile:1161: vmlinux] Error 1
This is caused by compiletime_assert in the FIELD_FIT / __BF_FIELD_CHECK macro
in the function ur_load_imm_any, which is called in jeq_imm.
The code compiles fine without ThinLTO, or with the previous revision of LLVM
prior to this commit.
I have attached a .config that reproduces the error.
--
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 39254] low-quality code generated for std::find on constant array
https://bugs.llvm.org/show_bug.cgi?id=39254 Eli Friedman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Eli Friedman --- Generated code looks fine on trunk; at least, the problem with the pointers seems to be fixed. (Arguably the switch lowering could still use some work, but it's not ridiculous.) -- 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 46524] New: [Scalarizer] Handling of variable insert/extracts?
https://bugs.llvm.org/show_bug.cgi?id=46524 Bug ID: 46524 Summary: [Scalarizer] Handling of variable insert/extracts? Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: llvm-bugs@lists.llvm.org Currently, Scalarizer does not handle variable insert/extract, and a `@f12` test in basic.ll suggests that is not an omission per-se. Question: is this an intentional design decision, or would it be acceptable to implement it? I maybe might want to explore adding Scalarizer into default pipeline, limited to <=2 elt vectors. -- 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 46525] New: ICE: Assertion `!verifyFunction(*L->getHeader()->getParent())' failed
https://bugs.llvm.org/show_bug.cgi?id=46525 Bug ID: 46525 Summary: ICE: Assertion `!verifyFunction(*L->getHeader()->getParent())' failed Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: vsevolod.livins...@frtk.ru CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Error: >$ clang++ -c -O3 func.cpp clang++: llvm/llvm-trunk/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7993: bool llvm::LoopVectorizePass::processLoop(llvm::Loop*): Assertion `!verifyFunction(*L->getHeader()->getParent())' failed. 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++ -c -O3 func.cpp 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'Function Pass Manager' on module 'func.cpp'. 4. Running pass 'Loop Vectorization' on function '@_Z4testv' #0 0x55f2ca9fce3e llvm::sys::PrintStackTrace(llvm::raw_ostream&) (llvm/bin-trunk/bin/clang-11+0x238ee3e) #1 0x55f2ca9fac14 llvm::sys::RunSignalHandlers() (llvm/bin-trunk/bin/clang-11+0x238cc14) #2 0x55f2ca9fae91 llvm::sys::CleanupOnSignal(unsigned long) (llvm/bin-trunk/bin/clang-11+0x238ce91) #3 0x55f2ca968ee8 CrashRecoverySignalHandler(int) (llvm/bin-trunk/bin/clang-11+0x22faee8) #4 0x7ff9528db540 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x15540) #5 0x7ff9523703eb raise /build/glibc-t7JzpG/glibc-2.30/signal/../sysdeps/unix/sysv/linux/raise.c:51:1 #6 0x7ff95234f899 abort /build/glibc-t7JzpG/glibc-2.30/stdlib/abort.c:81:7 #7 0x7ff95234f769 get_sysdep_segment_value /build/glibc-t7JzpG/glibc-2.30/intl/loadmsgcat.c:509:8 #8 0x7ff95234f769 _nl_load_domain /build/glibc-t7JzpG/glibc-2.30/intl/loadmsgcat.c:970:34 #9 0x7ff952361006 (/lib/x86_64-linux-gnu/libc.so.6+0x37006) #10 0x55f2cabc9a47 llvm::LoopVectorizePass::processLoop(llvm::Loop*) (llvm/bin-trunk/bin/clang-11+0x255ba47) #11 0x55f2cabcb710 llvm::LoopVectorizePass::runImpl(llvm::Function&, llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo&, llvm::TargetLibraryInfo*, llvm::DemandedBits&, llvm::AAResults&, llvm::AssumptionCache&, std::function&, llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*) (llvm/bin-trunk/bin/clang-11+0x255d710) #12 0x55f2cabcbba7 (anonymous namespace)::LoopVectorize::runOnFunction(llvm::Function&) (llvm/bin-trunk/bin/clang-11+0x255dba7) #13 0x55f2ca334f0c llvm::FPPassManager::runOnFunction(llvm::Function&) (llvm/bin-trunk/bin/clang-11+0x1cc6f0c) #14 0x55f2ca3355d9 llvm::FPPassManager::runOnModule(llvm::Module&) (llvm/bin-trunk/bin/clang-11+0x1cc75d9) #15 0x55f2ca335987 llvm::legacy::PassManagerImpl::run(llvm::Module&) (llvm/bin-trunk/bin/clang-11+0x1cc7987) #16 0x55f2cacaac06 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 >) (llvm/bin-trunk/bin/clang-11+0x263cc06) #17 0x55f2cb991591 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (llvm/bin-trunk/bin/clang-11+0x3323591) #18 0x55f2cc70d2e9 clang::ParseAST(clang::Sema&, bool, bool) (llvm/bin-trunk/bin/clang-11+0x409f2e9) #19 0x55f2cb990098 clang::CodeGenAction::ExecuteAction() (llvm/bin-trunk/bin/clang-11+0x3322098) #20 0x55f2cb2d3f69 clang::FrontendAction::Execute() (llvm/bin-trunk/bin/clang-11+0x2c65f69) #21 0x55f2cb28afde clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (llvm/bin-trunk/bin/clang-11+0x2c1cfde) #22 0x55f2cb3a8d80 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (llvm/bin-trunk/bin/clang-11+0x2d3ad80) #23 0x55f2c9299269 cc1_main(llvm::ArrayRef, char const*, void*) (llvm/bin-trunk/bin/clang-11+0xc2b269) #24 0x55f2c9296618 ExecuteCC1Tool(llvm::SmallVectorImpl&) (llvm/bin-trunk/bin/clang-11+0xc28618) #25 0x55f2cb14d699 void llvm::function_ref::callback_fn >, std::__cxx11::basic_string, std::allocator >*, bool*) const::'lambda'()>(long) (llvm/bin-trunk/bin/clang-11+0x2adf699) #26 0x55f2ca96906c llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (llvm/bin-trunk/bin/clang-11+0x22fb06c) #27 0x55f2cb14dfc6 clang::driver::CC1Command::Execute(llvm::ArrayRef >, std::__cxx11::basic_string, std::allocator >*, bool*) const (.part.0) (llvm/bin-trunk/bin/clang-11+0x2adffc6) #28 0x55f2cb1256cc clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (llvm/bin-trunk/bin/clang-11+0x2ab76cc) #29 0x55f2cb1260
[llvm-bugs] [Bug 46526] New: ABI compatibility of CXCursorKind broken
https://bugs.llvm.org/show_bug.cgi?id=46526 Bug ID: 46526 Summary: ABI compatibility of CXCursorKind broken Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: tman...@google.com CC: kli...@google.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk https://reviews.llvm.org/D60193 added CXCursor_CXXAddrspaceCastExpr to CXCursorKind, renumbering a bunch of existing values which came after it and thus breaking ABI compatibility. -- 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 23814 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-07-01 Type: Bug New issue 23814 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23814 Detailed Report: https://oss-fuzz.com/testcase?key=5722002223792128 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe12b18780 Crash State: clang::StmtVisitorBase::Visit IntExprEvaluator::VisitUnaryOperator clang::StmtVisitorBase::Visit Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=202006300157 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5722002223792128 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
