[llvm-bugs] Issue 5647 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (RetVT == MVT::i8 || RetVT == MVT::i16 || RetVT == MVT::i32 || RetVT == MVT::i64
Comment #2 on issue 5647 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (RetVT == MVT::i8 || RetVT == MVT::i16 || RetVT == MVT::i32 || RetVT == MVT::i64 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5647#c2 ClusterFuzz has detected this issue as fixed in range 201801240651:201801250632. Detailed report: https://oss-fuzz.com/testcase?key=4634333408133120 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-gisel Fuzz target binary: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (RetVT == MVT::i8 || RetVT == MVT::i16 || RetVT == MVT::i32 || RetVT == MVT::i64 AArch64FastISel::emitLSL_ri AArch64FastISel::fastSelectInstruction Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801020611:201801030610 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801240651:201801250632 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4634333408133120 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 5265 in oss-fuzz: llvm/clang-proto-fuzzer: Stack-overflow in matchSelectPattern
Comment #3 on issue 5265 by ClusterFuzz-External: llvm/clang-proto-fuzzer: Stack-overflow in matchSelectPattern https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5265#c3 ClusterFuzz has detected this issue as fixed in range 201801240651:201801250632. Detailed report: https://oss-fuzz.com/testcase?key=5259730642534400 Project: llvm Fuzzer: libFuzzer_llvm_clang-proto-fuzzer Fuzz target binary: clang-proto-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc71245de0 Crash State: matchSelectPattern llvm::matchSelectPattern matchMinMaxOfMinMax Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801020611:201801030610 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801240651:201801250632 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5259730642534400 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 5647 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (RetVT == MVT::i8 || RetVT == MVT::i16 || RetVT == MVT::i32 || RetVT == MVT::i64
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 5647 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: (RetVT == MVT::i8 || RetVT == MVT::i16 || RetVT == MVT::i32 || RetVT == MVT::i64 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5647#c3 ClusterFuzz testcase 4634333408133120 is verified as fixed, so closing issue as verified. 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 5265 in oss-fuzz: llvm/clang-proto-fuzzer: Stack-overflow in matchSelectPattern
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #4 on issue 5265 by ClusterFuzz-External: llvm/clang-proto-fuzzer: Stack-overflow in matchSelectPattern https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5265#c4 ClusterFuzz testcase 5259730642534400 is verified as fixed, so closing issue as verified. 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 5683 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-earlycse: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-earlycse
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-25 Type: Bug New issue 5683 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-earlycse: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-earlycse https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5683 Detailed report: https://oss-fuzz.com/testcase?key=5089029801377792 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-earlycse Fuzz target binary: llvm-opt-fuzzer--x86_64-earlycse Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-earlycse Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801240651:201801250632 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5089029801377792 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36085] New: Debug fragment offsets are emitted in the wrong order for symbol locations
https://bugs.llvm.org/show_bug.cgi?id=36085
Bug ID: 36085
Summary: Debug fragment offsets are emitted in the wrong order
for symbol locations
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: david.stenb...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19747
--> https://bugs.llvm.org/attachment.cgi?id=19747&action=edit
llc input
LLVM commit used: r323411.
When compiling foo.c:
struct {
long foo;
void *bar;
long baz;
void *qux;
} static var = { .bar = (void *)0x1234, .qux = (void *)0x5678 };
void *ptr;
int main() {
if (var.foo == 0)
var.bar = var.qux = ptr;
return 0;
}
using:
clang -march=x86-64 -O0 -g2 -S -emit-llvm foo.c -o foo.ll
opt -S -globalopt foo.ll -o foo.opt.ll
llc -O0 foo.opt.ll -filetype=obj -o foo.obj
the following debug info is emitted for the SRA'd struct variable, in which
the first and third fields have been optimized out:
<1><40>: Abbrev Number: 4 (DW_TAG_variable)
<41> DW_AT_name: (indirect string, offset: 0x10f): var
<45> DW_AT_type: <0x66>
<49> DW_AT_decl_file : 1
<4a> DW_AT_decl_line : 6
<4b> DW_AT_location: 26 byte block: 3 0 0 0 0 0 0 0 0 93 8 93 8 3 8
0 0 0 0 0 0 0 93 8 93 8 (DW_OP_addr: 0; DW_OP_piece: 8; DW_OP_piece: 8;
DW_OP_addr: 8; DW_OP_piece: 8; DW_OP_piece: 8)
As seen, the DW_OP_addr operations for the second and fourth field are emitted
before the pieces used as offsets for the optimized-out first and third
variable, leading the operations to be associated with wrong parts of the
variable.
This can be further seen by printing the variable in gdb:
echo "print /x var" | gdb a.out | grep '\$1'
(gdb) $1 = {foo = 0x1234, bar = , baz = 0x5678, qux = }
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36086] New: llvm-cov: Uncovered region when evaluated at compile-time
https://bugs.llvm.org/show_bug.cgi?id=36086
Bug ID: 36086
Summary: llvm-cov: Uncovered region when evaluated at
compile-time
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dennis.fels...@sap.com
CC: llvm-bugs@lists.llvm.org
Code regions that can be evaluated at compile-time are shown as uncovered by
llvm-cov, for example:
if (true && true) { // second true is uncovered
return 0;
}
if (argc > 1 && strcmp("&&", "&&) == 0) { // strcmp is uncovered
return 0;
}
if (argc > 1 && (strcmp)("&&", "&&) == 0) { // strcmp is covered here because
it is done at runtime
return 0;
}
if (argc > 1 && strcmp(argv[1], "&&) == 0) { // strcmp is covered here because
it is done at runtime
return 0;
}
Instead I would expect all of the if line to be covered.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36087] New: Unable to execute command: Segmentation fault
https://bugs.llvm.org/show_bug.cgi?id=36087 Bug ID: 36087 Summary: Unable to execute command: Segmentation fault Product: clang Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: wellingtonuem...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 19748 --> https://bugs.llvm.org/attachment.cgi?id=19748&action=edit Clang diagnostic msg clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 5.0.0-3 (tags/RELEASE_500/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/wico-7049ee.cpp clang: note: diagnostic msg: /tmp/wico-7049ee.sh clang: note: diagnostic msg: Compiling src/mame/drivers/next.cpp... #0 0x7fac0a52adfa llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/llvm-5.0/bin/../lib/libLLVM-5.0.so.1+0x7aadfa) #1 0x7fac0a529016 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-5.0/bin/../lib/libLLVM-5.0.so.1+0x7a9016) #2 0x7fac0a52914b (/usr/lib/llvm-5.0/bin/../lib/libLLVM-5.0.so.1+0x7a914b) #3 0x7fac0d39b150 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13150) #4 0x557f13af96de clang::ParmVarDecl::getDefaultArg() (/usr/lib/llvm-5.0/bin/clang+0x17a16de) #5 0x557f135a774b clang::Sema::SubstParmVarDecl(clang::ParmVarDecl*, clang::MultiLevelTemplateArgumentList const&, int, llvm::Optional, bool) (/usr/lib/llvm-5.0/bin/clang+0x124f74b) #6 0x557f135a8863 (/usr/lib/llvm-5.0/bin/clang+0x1250863) #7 0x557f135a9e3a (/usr/lib/llvm-5.0/bin/clang+0x1251e3a) #8 0x557f135aaeba (/usr/lib/llvm-5.0/bin/clang+0x1252eba) #9 0x557f135ad85b (/usr/lib/llvm-5.0/bin/clang+0x125585b) #10 0x557f135b1b1b (/usr/lib/llvm-5.0/bin/clang+0x1259b1b) #11 0x557f135b5280 (/usr/lib/llvm-5.0/bin/clang+0x125d280) #12 0x557f135b1004 (/usr/lib/llvm-5.0/bin/clang+0x1259004) #13 0x557f135b176e (/usr/lib/llvm-5.0/bin/clang+0x125976e) #14 0x557f135b5e4f (/usr/lib/llvm-5.0/bin/clang+0x125de4f) #15 0x557f135aaa78 (/usr/lib/llvm-5.0/bin/clang+0x1252a78) #16 0x557f135ad85b (/usr/lib/llvm-5.0/bin/clang+0x125585b) #17 0x557f135b624f clang::Sema::SubstType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName, bool) (/usr/lib/llvm-5.0/bin/clang+0x125e24f) #18 0x557f1350b07f (/usr/lib/llvm-5.0/bin/clang+0x11b307f) #19 0x557f1351f6d6 clang::Sema::CheckTemplateArgumentList(clang::TemplateDecl*, clang::SourceLocation, clang::TemplateArgumentListInfo&, bool, llvm::SmallVectorImpl&, bool) (/usr/lib/llvm-5.0/bin/clang+0x11c76d6) #20 0x557f1351fe8a clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation, clang::TemplateArgumentListInfo&) (/usr/lib/llvm-5.0/bin/clang+0x11c7e8a) #21 0x557f135b5776 (/usr/lib/llvm-5.0/bin/clang+0x125d776) #22 0x557f135abbd4 (/usr/lib/llvm-5.0/bin/clang+0x1253bd4) #23 0x557f135ad85b (/usr/lib/llvm-5.0/bin/clang+0x125585b) #24 0x557f135b1b1b (/usr/lib/llvm-5.0/bin/clang+0x1259b1b) #25 0x557f135b5280 (/usr/lib/llvm-5.0/bin/clang+0x125d280) #26 0x557f135abbd4 (/usr/lib/llvm-5.0/bin/clang+0x1253bd4) #27 0x557f135c1cf1 clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*, clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation, clang::DeclarationName, clang::CXXRecordDecl*, unsigned int) (/usr/lib/llvm-5.0/bin/clang+0x1269cf1) #28 0x557f135c4d22 clang::TemplateDeclInstantiator::VisitDecl(clang::Decl*) (/usr/lib/llvm-5.0/bin/clang+0x126cd22) #29 0x557f135d66d0 clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*, clang::TemplateParameterList*, bool) (/usr/lib/llvm-5.0/bin/clang+0x127e6d0) #30 0x557f135d3d2e clang::Sema::SubstDecl(clang::Decl*, clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) (/usr/lib/llvm-5.0/bin/clang+0x127bd2e) #31 0x557f1358da3f clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*, bool, llvm::function_ref) (/usr/lib/llvm-5.0/bin/clang+0x1235a3f) #32 0x557f135926be clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool, l
[llvm-bugs] [Bug 36018] [GlobalISel][AArch64] Two load instructions generated for single volatile load
https://bugs.llvm.org/show_bug.cgi?id=36018 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #9 from Hans Wennborg --- (In reply to Eli Friedman from comment #8) > Needs to be cherry-picked to 6.0. Merged in r323434 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 36018, which changed state. Bug 36018 Summary: [GlobalISel][AArch64] Two load instructions generated for single volatile load https://bugs.llvm.org/show_bug.cgi?id=36018 What|Removed |Added Status|REOPENED|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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36088] New: ExprWithCleanups not handled in emitOpenCLEnqueuedBlock
https://bugs.llvm.org/show_bug.cgi?id=36088
Bug ID: 36088
Summary: ExprWithCleanups not handled in
emitOpenCLEnqueuedBlock
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: l...@zaghen.it
CC: llvm-bugs@lists.llvm.org
Created attachment 19749
--> https://bugs.llvm.org/attachment.cgi?id=19749&action=edit
The CL kernel
The attached source makes clang (6.0-rc1 and trunk) assert on
cast().
I tried ignoring the ExprWithCleanups:
if (auto DR = dyn_cast(E)) {
E = cast(DR->getDecl())->getInit();
}
+ if (auto Cast = dyn_cast(E)) {
+E = Cast->getSubExpr();
+ }
if (auto Cast = dyn_cast(E)) {
E = Cast->getSubExpr();
}
auto *Block = cast(E);
but it seems like clang also tries to emit the same block expression twice (the
second time through the OCL enqueue specific codepath.)
Options I used for clang: "-x cl -cl-std=CL2.0 enqueue_block_kernel.cl"
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36089] New: [ThinLTO] asserts `!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"` failed
https://bugs.llvm.org/show_bug.cgi?id=36089
Bug ID: 36089
Summary: [ThinLTO] asserts `!(Pair.first != Ty && Pair.second
== Ty) && "mapping to a source type"` failed
Product: libraries
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Linker
Assignee: unassignedb...@nondot.org
Reporter: russell_gal...@sn.scee.net
CC: llvm-bugs@lists.llvm.org
This seems related to PR37522 but wasn't fixed by r322103.
At r323433:
$ clang --version
clang version 7.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
$ cat a.cpp
void foo() {}
$ cat b.cpp
struct B;
struct C {
C(B &);
};
struct A &fn1() {}
C::C(B &) {}
$ cat c.cpp
struct A &foo();
template struct D {};
struct B {
B(A &);
D<> m_list;
};
struct C {
C(B &);
};
void bar() {
B b(foo());
C c(b);
}
$ clang -c -O1 -g -flto=thin a.cpp
$ clang -c -O1 -g -flto=thin b.cpp
b.cpp:5:18: warning: control reaches end of non-void function [-Wreturn-type]
struct A &fn1() {}
^
1 warning generated.
$ clang -c -O1 -g -flto=thin c.cpp
$ llvm-lto -thinlto-action=run a.o b.o c.o
llvm-lto: /home/user/git/llvm/lib/Linker/IRMover.cpp:248: llvm::Type*
{anonymous}::TypeMapTy::get(llvm::Type*, llvm::SmallPtrSet&): Assertion
`!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"'
failed.
...
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36090] New: [X86
https://bugs.llvm.org/show_bug.cgi?id=36090 Bug ID: 36090 Summary: [X86 Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: llvm-bugs@lists.llvm.org -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36090] [X86][SSE]
https://bugs.llvm.org/show_bug.cgi?id=36090 Simon Pilgrim changed: What|Removed |Added Summary|[X86|[X86][SSE] Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Simon Pilgrim --- Stupid fat fingers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36091] New: [X86][SSE] Failure to vectorize load+extend v8i8 to v8i16
https://bugs.llvm.org/show_bug.cgi?id=36091
Bug ID: 36091
Summary: [X86][SSE] Failure to vectorize load+extend v8i8 to
v8i16
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
nir...@google.com, spatel+l...@rotateright.com
#include
#include
__m128i loadext_i8(int8_t *data) {
return _mm_set_epi16(data[7], data[6], data[5], data[4], data[3], data[2],
data[1], data[0]);
}
__m128i loadext_u8(uint8_t *data) {
return _mm_set_epi16(data[7], data[6], data[5], data[4], data[3], data[2],
data[1], data[0]);
}
clang -O3 -march=btver2
define <2 x i64> @loadext_i8(i8* nocapture readonly) {
%2 = getelementptr inbounds i8, i8* %0, i64 7
%3 = load i8, i8* %2, align 1, !tbaa !2
%4 = sext i8 %3 to i16
%5 = getelementptr inbounds i8, i8* %0, i64 6
%6 = load i8, i8* %5, align 1, !tbaa !2
%7 = sext i8 %6 to i16
%8 = getelementptr inbounds i8, i8* %0, i64 5
%9 = load i8, i8* %8, align 1, !tbaa !2
%10 = sext i8 %9 to i16
%11 = getelementptr inbounds i8, i8* %0, i64 4
%12 = load i8, i8* %11, align 1, !tbaa !2
%13 = sext i8 %12 to i16
%14 = getelementptr inbounds i8, i8* %0, i64 3
%15 = load i8, i8* %14, align 1, !tbaa !2
%16 = sext i8 %15 to i16
%17 = getelementptr inbounds i8, i8* %0, i64 2
%18 = load i8, i8* %17, align 1, !tbaa !2
%19 = sext i8 %18 to i16
%20 = getelementptr inbounds i8, i8* %0, i64 1
%21 = load i8, i8* %20, align 1, !tbaa !2
%22 = sext i8 %21 to i16
%23 = load i8, i8* %0, align 1, !tbaa !2
%24 = sext i8 %23 to i16
%25 = insertelement <8 x i16> undef, i16 %24, i32 0
%26 = insertelement <8 x i16> %25, i16 %22, i32 1
%27 = insertelement <8 x i16> %26, i16 %19, i32 2
%28 = insertelement <8 x i16> %27, i16 %16, i32 3
%29 = insertelement <8 x i16> %28, i16 %13, i32 4
%30 = insertelement <8 x i16> %29, i16 %10, i32 5
%31 = insertelement <8 x i16> %30, i16 %7, i32 6
%32 = insertelement <8 x i16> %31, i16 %4, i32 7
%33 = bitcast <8 x i16> %32 to <2 x i64>
ret <2 x i64> %33
}
define <2 x i64> @loadext_u8(i8* nocapture readonly) {
%2 = getelementptr inbounds i8, i8* %0, i64 7
%3 = load i8, i8* %2, align 1, !tbaa !2
%4 = zext i8 %3 to i16
%5 = getelementptr inbounds i8, i8* %0, i64 6
%6 = load i8, i8* %5, align 1, !tbaa !2
%7 = zext i8 %6 to i16
%8 = getelementptr inbounds i8, i8* %0, i64 5
%9 = load i8, i8* %8, align 1, !tbaa !2
%10 = zext i8 %9 to i16
%11 = getelementptr inbounds i8, i8* %0, i64 4
%12 = load i8, i8* %11, align 1, !tbaa !2
%13 = zext i8 %12 to i16
%14 = getelementptr inbounds i8, i8* %0, i64 3
%15 = load i8, i8* %14, align 1, !tbaa !2
%16 = zext i8 %15 to i16
%17 = getelementptr inbounds i8, i8* %0, i64 2
%18 = load i8, i8* %17, align 1, !tbaa !2
%19 = zext i8 %18 to i16
%20 = getelementptr inbounds i8, i8* %0, i64 1
%21 = load i8, i8* %20, align 1, !tbaa !2
%22 = zext i8 %21 to i16
%23 = load i8, i8* %0, align 1, !tbaa !2
%24 = zext i8 %23 to i16
%25 = insertelement <8 x i16> undef, i16 %24, i32 0
%26 = insertelement <8 x i16> %25, i16 %22, i32 1
%27 = insertelement <8 x i16> %26, i16 %19, i32 2
%28 = insertelement <8 x i16> %27, i16 %16, i32 3
%29 = insertelement <8 x i16> %28, i16 %13, i32 4
%30 = insertelement <8 x i16> %29, i16 %10, i32 5
%31 = insertelement <8 x i16> %30, i16 %7, i32 6
%32 = insertelement <8 x i16> %31, i16 %4, i32 7
%33 = bitcast <8 x i16> %32 to <2 x i64>
ret <2 x i64> %33
}
loadext_i8:
movsbl (%rdi), %ecx
movsbl 1(%rdi), %eax
movsbl 2(%rdi), %edx
vmovd %ecx, %xmm0
movsbl 3(%rdi), %ecx
vpinsrw $1, %eax, %xmm0, %xmm0
vpinsrw $2, %edx, %xmm0, %xmm0
movsbl 4(%rdi), %edx
vpinsrw $3, %ecx, %xmm0, %xmm0
movsbl 5(%rdi), %ecx
vpinsrw $4, %edx, %xmm0, %xmm0
movsbl 6(%rdi), %edx
vpinsrw $5, %ecx, %xmm0, %xmm0
movsbl 7(%rdi), %ecx
vpinsrw $6, %edx, %xmm0, %xmm0
vpinsrw $7, %ecx, %xmm0, %xmm0
retq
loadext_u8:
movzbl (%rdi), %ecx
movzbl 1(%rdi), %eax
movzbl 2(%rdi), %edx
vmovd %ecx, %xmm0
movzbl 3(%rdi), %ecx
vpinsrw $1, %eax, %xmm0, %xmm0
vpinsrw $2, %edx, %xmm0, %xmm0
movzbl 4(%rdi), %edx
vpinsrw $3, %ecx, %xmm0, %xmm0
movzbl 5(%rdi), %ecx
vpinsrw $4, %edx, %xmm0, %xmm0
movzbl 6(%rdi), %edx
vpinsrw $5, %ecx, %xmm0, %xmm0
movzbl 7(%rdi), %ecx
vpinsrw $6, %edx, %xmm0, %xmm0
vpinsrw $7, %ecx, %xmm0, %xmm0
retq
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36083] Crash when multiple ATs map to the same AT>
https://bugs.llvm.org/show_bug.cgi?id=36083 Rafael Ávila de Espíndola changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Rafael Ávila de Espíndola --- r323449. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36092] New: [AMDGPU][MC][GFX8][GFX9] Image instructions failed to assemble with d16 modifier
https://bugs.llvm.org/show_bug.cgi?id=36092 Bug ID: 36092 Summary: [AMDGPU][MC][GFX8][GFX9] Image instructions failed to assemble with d16 modifier Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org An example of a failed test: image_load v5, v[1:4], s[8:15] d16 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36093] New: [AMDGPU][MC][GFX7][GFX8] Image instructions failed to assemble with r128 modifier
https://bugs.llvm.org/show_bug.cgi?id=36093 Bug ID: 36093 Summary: [AMDGPU][MC][GFX7][GFX8] Image instructions failed to assemble with r128 modifier Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Examples of failed tests: image_load v5, v[1:4], s[8:15] r128 The test fails because r128 modifier is not recognized. Also note that this modifier should affect SRSRC size, but assembler currently does not support 128-bit SRSRC. When it will, the correct test would be: image_load v5, v[1:4], s[8:11] r128 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 14493] [Hexagon] Factor out common functionality from the predicate definitions in HexagonOperands.td
https://bugs.llvm.org/show_bug.cgi?id=14493 Krzysztof Parzyszek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Krzysztof Parzyszek --- A lot of the .td definitions are now auto-generated. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36094] New: [AMDGPU][MC][GFX9] r128 modifier of image instructions should be disabled for GFX9
https://bugs.llvm.org/show_bug.cgi?id=36094 Bug ID: 36094 Summary: [AMDGPU][MC][GFX9] r128 modifier of image instructions should be disabled for GFX9 Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36095] New: [AMDGPU][MC][GFX8][GFX9] d16 modifier of image instructions should be enabled for GFX8/9 only
https://bugs.llvm.org/show_bug.cgi?id=36095 Bug ID: 36095 Summary: [AMDGPU][MC][GFX8][GFX9] d16 modifier of image instructions should be enabled for GFX8/9 only Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33629] [mc][gfx9] Missing support for 16-bit renamed/legacy VALU opcodes
https://bugs.llvm.org/show_bug.cgi?id=33629 Dmitry changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dmitry --- Resolved by commits 318955, 310497 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35962] [AMDGPU][MC] Incorrect encoding of VDATA for image atomics
https://bugs.llvm.org/show_bug.cgi?id=35962 Dmitry changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #1 from Dmitry --- closed by commit 322942: http://llvm.org/viewvc/llvm-project?rev=322942&view=rev -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35963] [AMDGPU][MC] Incorrect parsing of image modifiers
https://bugs.llvm.org/show_bug.cgi?id=35963 Dmitry changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #1 from Dmitry --- closed by commit 322942: http://llvm.org/viewvc/llvm-project?rev=322942&view=rev -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36096] New: Regression: Invalid *.lib produced on MSVC upgrading from 4.0.1
https://bugs.llvm.org/show_bug.cgi?id=36096 Bug ID: 36096 Summary: Regression: Invalid *.lib produced on MSVC upgrading from 4.0.1 Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Object Assignee: unassignedb...@nondot.org Reporter: a...@crichton.co CC: llvm-bugs@lists.llvm.org, martellmal...@gmail.com, r...@google.com Created attachment 19750 --> https://bugs.llvm.org/attachment.cgi?id=19750&action=edit Object to insert in archive Over at rust-lang/rust we've been a little slow to the uptick of landing LLVM changes, but we're getting around now to upgrading from LLVM 4.0.1 to 6.0.0. Unfortunately though we're seeing what I think is a regression in behavior of the `llvm-ar.exe` tool on Windows MSVC. I've run a bisection and it pointed at https://reviews.llvm.org/D29892 so I'm cc'ing those there to hope that y'all can help out with this issue! Unfortunately I don't have a small reproduction to gist here but I can certainly work to make it smaller if need be! The rust compiler isn't necessarily standard about how it uses LLVM, for example we don't literally use `llvm-ar.exe` but rather call `writeArchive` directly. I believe that the various invocations are the same, however, in terms of reproduction at the command line. In any case, the bug that I'm seeing happens when we do something like: * First we compile a C++ library to an archive using its own build system (CMake). That project is https://github.com/WebAssembly/binaryen. * Next, the Rust compiler opens up this archive using the `Archive` class in LLVM and iterates over it with `Archive::child_iterator`. * We then create a new archive with `writeArchive` where some members are freshly generated object files (aka the Rust code) and the remaining members are those from the previous `Archive` opened earlier. We're using `NewArchiveMember::getOldMember` to insert these preexisting members into the new archive. * Later this archive that was generated is then passed to `link.exe`, MSVC's linker * The bug happens here where MSVC's linker spits out a message "library is corrupt" (with no other information). Using LLVM 4.0.1 `link.exe` doesn't spit out this error message, but using LLVM 6.0.0 `link.exe` spits out the error message. While I haven't managed to create a tiny test case I have managed to reduce this somewhat. Specifically I've been taking the object file attached to this bug and executing: llvm-ar.exe crus libfoo.a archive.obj When the resulting archive is fed to `link.exe` on LLVM 4.0.1 then `link.exe` spits out a ton of undefined symbol errors (as the archive is missing all the other objects). On LLVM 6.0.0, however, `link.exe` simply spits out "library is corrupt". Unfortunately a direct invocation of `link.exe` isn't working, I've been using it with all the other libraries and files on the originally failing `link.exe` command. I'm not too familiar with `link.exe`, though, so y'all may know how to create a more directly failing test case! Upon running a bisection it ended up pointing at https://github.com/llvm-mirror/llvm/commit/5d7d0e869f7abea7d1022e4b65a75a97dc2e54a6. This commit was reverted a few hours later but a slight tweak was relanded and I believe it's stayed since. The "suspicious" line for archive writing was the change to `ArchiveWriter.cpp` where `SF_Indirect` symbols were changed to be included in the archive. I've tested out LLVM 6.0.0 with just the change to `ArchiveWriter.cpp` reverted from that patch (aka remove the branch that checks `SF_Indirect`). That seems to at least restore the old behavior and produces a working archive which isn't considered corrupt by `link.exe`. Ok so that's all the information that I currently have at this time, but I realize it's not a great amount of information as it can't be trivially reproduced yet! I'm hoping though that y'all cc'd here can help me out and either recognize what's going on here or suggest a way to help minimize. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36097] New: Merge r323469 into 6.0: Teach Intel syntax InstPrinter to print lock prefixes that have been parsed from the asm parser.
https://bugs.llvm.org/show_bug.cgi?id=36097 Bug ID: 36097 Summary: Merge r323469 into 6.0: Teach Intel syntax InstPrinter to print lock prefixes that have been parsed from the asm parser. Product: libraries Version: 6.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: llvm-bugs@lists.llvm.org This is another issue introduced by https://reviews.llvm.org/rL315899 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27784] llc emits AT&T-mnemonic when using -O0 --x86-asm-syntax=intel
https://bugs.llvm.org/show_bug.cgi?id=27784 Craig Topper changed: What|Removed |Added CC||craig.top...@gmail.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Craig Topper --- I believe this was fixed in r314140. We now print "movabs»·rdi, offset .LLt_0004" The 'offset' makes the GNU assembler happy. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36098] New: llvm-ar/lib checks incorrectly "lib" stem
https://bugs.llvm.org/show_bug.cgi?id=36098 Bug ID: 36098 Summary: llvm-ar/lib checks incorrectly "lib" stem Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-ar Assignee: unassignedb...@nondot.org Reporter: ignacio.slipk...@gmail.com CC: llvm-bugs@lists.llvm.org Visual Studio 2015 runs lib as "Lib" so the case-sensitive comparison fails. Not sure if it affects everyone. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36099] New: Input stream formatted input for `float` produces incorrect result for non-hexadecimal-prefixed input containing hexadecimal characters without an exponent
https://bugs.llvm.org/show_bug.cgi?id=36099
Bug ID: 36099
Summary: Input stream formatted input for `float` produces
incorrect result for non-hexadecimal-prefixed input
containing hexadecimal characters without an exponent
Product: libc++
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: brycelelb...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
=
Test Case
=
#include
#include
int main() {
std::istringstream s("1.000f32");
float f;
s >> f;
std::cout << f << std::endl;
}
==
Steps to Reproduce
==
https://wandbox.org/permlink/3d9Z9Fr6vqzcx29w
===
Observed Output
===
0
===
Expected Output
===
1
This appears to be a bug in libc++'s hexadecimal `float` formatted input.
libc++'s formatted stream input implementation for `float` calls `num_get`
(ISO/IEC 14882 [istream.formatted.arithmetic]).
In the case of `float`, `num_get` accumulates valid characters until it
encounters an invalid character (stage 1), and then does the equivalent of
calling the C library function `strtof` on the accumulated string (ISO/IEC
14882 [facet.num.get.virtuals] (3.3.3) "Stage 2"). My guess is that in this
case,
libc++ considers the characters `[a-z]` (hexadecimal digits) to be valid in
addition to `[0-9+-eE]` in stage 1, but in stage 2 (the equivalent-to-`strtof`
stage), the string "1.000f32" is rejected because it doesn't have the
hexadecimal prefix (e.g. it's not "0x1.000f32").
Feeding the entire string directly into `strtof` consumes "1.000" and returns
1:
https://wandbox.org/permlink/BRWaxfmoTNewQMTo
If you change the input string to contain a character that is not a hexadecimal
digit (e.g. "1.000g32"), libc++ returns 1:
https://wandbox.org/permlink/BRWaxfmoTNewQMTo
libc++ should only accept hexadecimal digits in floats when the hexadecimal
prefix is present. Otherwise, there are ambiguities. Consider "1.000e32" - is
it a hexadecimal `float`, or a `float` with an exponent.
libstdc++ and MSVC print 1 for the test case:
libstdc++: https://wandbox.org/permlink/4EF17CZxau2CrYTA
MSVC: http://rextester.com/STNGQX93481
===
Environment
===
Platform: Godbolt (Linux Docker)
Clang/LLVM Version: Top of trunk as of 01/25/2018
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 5688 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: llvm::all_of(Mask, [&](int M) { return M < (NElts * 2) && M >= -1; }) && "Index
Status: New
Owner:
CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com,
igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com,
mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com
Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible
Engine-libfuzzer Proj-llvm Reported-2018-01-25
Type: Bug
New issue 5688 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2:
ASSERT: llvm::all_of(Mask, [&](int M) { return M < (NElts * 2) && M >= -1;
}) && "Index
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5688
Detailed report: https://oss-fuzz.com/testcase?key=5066873944145920
Project: llvm
Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2
Fuzz target binary: llvm-isel-fuzzer--x86_64-O2
Job Type: libfuzzer_asan_llvm
Platform Id: linux
Crash Type: ASSERT
Crash Address:
Crash State:
llvm::all_of(Mask, [&](int M) { return M < (NElts * 2) && M >= -1; })
&& "Index
llvm::SelectionDAG::getVectorShuffle
DAGCombiner::visitBUILD_VECTOR
Sanitizer: address (ASAN)
Regressed:
https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710190451:201710200650
Reproducer Testcase:
https://oss-fuzz.com/download?testcase_id=5066873944145920
Issue filed automatically.
See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for
more information.
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 have questions for the OSS-Fuzz team, please file an issue at
https://github.com/google/oss-fuzz/issues.
--
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36100] New: Abort trap in 'PowerPC DAG->DAG Pattern Instruction Selection'
https://bugs.llvm.org/show_bug.cgi?id=36100 Bug ID: 36100 Summary: Abort trap in 'PowerPC DAG->DAG Pattern Instruction Selection' Product: clang Version: 5.0 Hardware: Other OS: FreeBSD Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: s...@sven-siemsen.de CC: llvm-bugs@lists.llvm.org Created attachment 19752 --> https://bugs.llvm.org/attachment.cgi?id=19752&action=edit Preprocessed source and associated run script I am trying to build FreeBSD-11.1 on powerpc64 with clang-5.0.1 from ports. When building openssh, clang crashes --- progressmeter.o --- clang-5.0: error: unable to execute command: Abort trap (core dumped) clang-5.0: error: clang frontend command failed due to signal (use -v to see invocation) clang version 5.0.1 (tags/RELEASE_501/final) Target: powerpc-portbld-freebsd11.1 Thread model: posix InstalledDir: /usr/local/llvm50/bin clang-5.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-5.0: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-5.0: note: diagnostic msg: /tmp/progressmeter-2c5082.c clang-5.0: note: diagnostic msg: /tmp/progressmeter-2c5082.sh Output of progressmeter-2c5082.sh: Assertion failed: (NewLHS.getValueType() == N->getValueType(0) && "Unexpected setcc expansion!"), function ExpandIntOp_SETCC, file /usr/ports/devel/llvm50/work/llvm-5.0.1.src/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp, line 3117. Stack dump: 0. Program arguments: /usr/local/llvm50/bin/clang-5.0 -cc1 -triple powerpc-portbld-freebsd11.1 -emit-obj -disable-free -main-file-name progressmeter.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu 970 -mfloat-abi hard -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /usr/obj/usr/src/world32/usr/src/secure/lib/libssh/progressmeter.gcno -sys-header-deps -D COMPAT_32BIT -D HAVE_LDNS=1 -O2 -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -std=gnu99 -ferror-limit 19 -fmessage-length 0 -stack-protector 2 -fno-signed-char -fobjc-runtime=gnustep -fdiagnostics-show-option -vectorize-loops -vectorize-slp -x c progressmeter-2c5082.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'progressmeter-2c5082.c'. 4. Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on function '@Fssh_refresh_progress_meter' Abort trap (core dumped) I tried with clang 7.0.0 from devel/clang-devel, same result. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36101] New: LLD COFF produces bad diagnostics for undefined /include symbol
https://bugs.llvm.org/show_bug.cgi?id=36101
Bug ID: 36101
Summary: LLD COFF produces bad diagnostics for undefined
/include symbol
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: smee...@fb.com
CC: compn...@compnerd.org, llvm-bugs@lists.llvm.org,
pe...@pcc.me.uk, r...@google.com, r...@google.com,
ztur...@google.com
% cat using.c
int main() { return 0; }
#pragma comment(linker, "/include:undefined")
% clang -target x86_64-windows-msvc -c using.c
$ lld-link -entry:main using.o
lld-link: error: : undefined symbol: undefined
Undefined symbols from /include directives in object files are reported as
originating from the GC root, which is confusing and makes the user have to
manually hunt for the errant object file.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36102] New: RewriteStatepointsForGC probably shouldn't turn musttail calls into statepoints
https://bugs.llvm.org/show_bug.cgi?id=36102 Bug ID: 36102 Summary: RewriteStatepointsForGC probably shouldn't turn musttail calls into statepoints Product: libraries Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: ben...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 19753 --> https://bugs.llvm.org/attachment.cgi?id=19753&action=edit A minimal example of input that the pass mangles Applying the RewriteStatepointsForGC pass to a function definition that contains a `musttail` call turns that call into a statepoint, which produces a malformed module (since the parameter counts mismatch). The attached file is a valid module, but running `opt -rewrite-statepoints-for-gc -S tail_statepoint.ll` produces the following error message: cannot guarantee tail call due to mismatched parameter counts %statepoint_token = musttail call token (i64, i32, i32 (i32 addrspace(1)*)*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i32p1i32f(i64 288240, i32 0, i32 (i32 addrspace(1)*)* @foo, i32 1, i32 0, i32 addrspace(1)* %x, i32 0, i32 0, i32 addrspace(1)* %x) LLVM ERROR: Broken function found, compilation aborted! As far as I can tell, the decision on whether to rewrite a given callsite is made here: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp#L2522 It seems to me that just adding a clause to verify that the call is not `musttail` would be an improvement, but I'm not at all familiar with what other repercussions it could possibly have. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36099] Input stream formatted input for `float` produces incorrect result for non-hexadecimal-prefixed input containing hexadecimal characters without an exponent
https://bugs.llvm.org/show_bug.cgi?id=36099 Marshall Clow (home) changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Marshall Clow (home) --- *** This bug has been marked as a duplicate of bug 17782 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 5704 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary ope
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-01-26 Type: Bug New issue 5704 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-gisel: ASSERT: N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary ope https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5704 Detailed report: https://oss-fuzz.com/testcase?key=6013747266060288 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-gisel Fuzz target binary: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: N1.getValueType() == N2.getValueType() && N1.getValueType() == VT && "Binary ope llvm::SelectionDAG::getNode llvm::SelectionDAGBuilder::visitBinary Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801240651:201801250632 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6013747266060288 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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 have questions for the OSS-Fuzz team, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36103] New: LLVM overwrites spilled xmm registers in crash handler
https://bugs.llvm.org/show_bug.cgi?id=36103 Bug ID: 36103 Summary: LLVM overwrites spilled xmm registers in crash handler Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: smee...@fb.com CC: compn...@compnerd.org, david.majne...@gmail.com, llvm-bugs@lists.llvm.org, r...@google.com Created attachment 19754 --> https://bugs.llvm.org/attachment.cgi?id=19754&action=edit Reduced test case See dbl3.ll (in the attached zip). If I assemble this with % opt -mem2reg -mtriple x86_64-windows-msvc -S -o - dbl3.ll | \ llc -filetype=asm -o - - the function prologue has "?z@@YANXZ":# @"\01?z@@YANXZ" .Lfunc_begin0: .seh_proc "?z@@YANXZ" .seh_handler __CxxFrameHandler3, @unwind, @except # %bb.0:# %entry pushq %rbp .seh_pushreg 5 subq$64, %rsp .seh_stackalloc 64 leaq64(%rsp), %rbp .seh_setframe 5, 64 movaps %xmm6, -16(%rbp)# 16-byte Spill .seh_savexmm 6, 48 .seh_endprologue and the catch handler prologue has "?catch$4@?0??z@@YANXZ@4HA": .seh_proc "?catch$4@?0??z@@YANXZ@4HA" .seh_handler __CxxFrameHandler3, @unwind, @except .LBB0_4:# %catch movq%rdx, 16(%rsp) pushq %rbp .seh_pushreg 5 subq$32, %rsp .seh_stackalloc 32 leaq64(%rdx), %rbp movapd %xmm6, -16(%rbp)# 16-byte Spill .seh_savexmm 6, 48 .seh_endprologue Note that the catch handler saves xmm6 to the stack to the exact same slot the function prologue saved it to. In other words, when the catch handler is entered, the *current* value of xmm6, which has already been overwritten inside the function, is saved to the stack, overwriting the original value that was saved in the function prologue. The function epilogue will therefore restore an incorrect value to xmm6. dbl.cpp, dbl2.cpp, and dbl3.cpp in the attached zip represent a complete example demonstrating the problem. If you run % clang-cl /O1 /EHsc dbl.cpp dbl2.cpp dbl3.cpp and then execute dbl.exe, the exit code should be 1 rather than 0, because of xmm6 getting trashed. Compiling with cl and running the compiled program yields an exit code of 0, as expected. I've reproduced this with clang 5, clang 6, and trunk, so it seems like it goes a long way back. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36104] New: LoopUnrollPass is not updating parameters of DbgValueInst correctly
https://bugs.llvm.org/show_bug.cgi?id=36104
Bug ID: 36104
Summary: LoopUnrollPass is not updating parameters of
DbgValueInst correctly
Product: libraries
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: agu...@tifr.res.in
CC: llvm-bugs@lists.llvm.org
Consider following input to LoopUnroll pass to be unrolled two times.
define i32 @main() #0 !dbg !7 {
call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !11, metadata !12),
!dbg !13
br label %1, !dbg !14
; :1: ; preds = %1, %0
%.0 = phi i32 [ 0, %0 ], [ %3, %1 ]
call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
%2 = icmp slt i32 %.0, 5, !dbg !15
%3 = add nsw i32 %.0, 1, !dbg !18
call void @llvm.dbg.value(metadata i32 %3, i64 0, metadata !11, metadata
!12), !dbg !13
br i1 %2, label %1, label %4, !dbg !20, !llvm.loop !21
; :4: ; preds = %1
ret i32 0, !dbg !23
}
After rotating and unrolling (unrolling requires rotating), we obtain:
define i32 @main() #0 !dbg !7 {
call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !11, metadata !12),
!dbg !13
br label %1, !dbg !14
; :1: ; preds = %6, %0
%.0 = phi i32 [ 0, %0 ], [ %8, %6 ]
call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
%2 = add nuw nsw i32 %.0, 1, !dbg !15
call void @llvm.dbg.value(metadata i32 %2, i64 0, metadata !11, metadata
!12), !dbg !13
call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
%3 = icmp ult i32 %2, 5, !dbg !19
%4 = add nuw nsw i32 %2, 1, !dbg !15
call void @llvm.dbg.value(metadata i32 %2, i64 0, metadata !11, metadata
!12), !dbg !13
br i1 %3, label %6, label %5, !dbg !20, !llvm.loop !21
; :5: ; preds = %1
ret i32 0, !dbg !23
; :6: ; preds = %1
call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
%7 = add nuw nsw i32 %4, 1, !dbg !15
call void @llvm.dbg.value(metadata i32 %2, i64 0, metadata !11, metadata
!12), !dbg !13
call void @llvm.dbg.value(metadata i32 %.0, i64 0, metadata !11, metadata
!12), !dbg !13
%8 = add nuw nsw i32 %7, 1, !dbg !15
call void @llvm.dbg.value(metadata i32 %2, i64 0, metadata !11, metadata
!12), !dbg !13
br label %1
}
Look at the the copied body in block 6. Note that the dbg.value after %7 is not
updated and still reflects %2. IMHO, it is wrong cloning of the block.
I think the problem lies in the following function of LoopUnroll.cpp:67
static inline void remapInstruction(Instruction *I,
ValueToValueMapTy &VMap) {
for (unsigned op = 0, E = I->getNumOperands(); op != E; ++op) {
Value *Op = I->getOperand(op); <<<
ValueToValueMapTy::iterator It = VMap.find(Op);
if (It != VMap.end())
I->setOperand(op, It->second); <<<
}
if (PHINode *PN = dyn_cast(I)) {
for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) {
ValueToValueMapTy::iterator It = VMap.find(PN->getIncomingBlock(i));
if (It != VMap.end())
PN->setIncomingBlock(i, cast(It->second));
}
}
}
This function fails to pick the the right argument of a DbgValueInst. 0th Op is
not a Value but a metadata that contains the value %2 and needs one more
redirection to update the reference to %2.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
