[llvm-bugs] Issue 4588 in oss-fuzz: llvm/clang-fuzzer: Stack-buffer-overflow in clang::expandUCNs
Comment #6 on issue 4588 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-buffer-overflow in clang::expandUCNs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4588#c6 ClusterFuzz has detected this issue as fixed in range 201802060728:201802070205. Detailed report: https://oss-fuzz.com/testcase?key=5041559499177984 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-buffer-overflow READ 1 Crash Address: 0x7fcbded34038 Crash State: clang::expandUCNs clang::NumericLiteralParser::NumericLiteralParser clang::Sema::ActOnNumericConstant Sanitizer: address (ASAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712090607:201712100011 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802060728:201802070205 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5041559499177984 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 4588 in oss-fuzz: llvm/clang-fuzzer: Stack-buffer-overflow in clang::expandUCNs
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #7 on issue 4588 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-buffer-overflow in clang::expandUCNs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4588#c7 ClusterFuzz testcase 5041559499177984 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 4664 in oss-fuzz: llvm/clang-fuzzer: ASSERT: *I == 'u' || *I == 'U'
Comment #5 on issue 4664 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: *I == 'u' || *I == 'U' https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4664#c5 ClusterFuzz has detected this issue as fixed in range 201802060728:201802070205. Detailed report: https://oss-fuzz.com/testcase?key=460742694912 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: *I == 'u' || *I == 'U' clang::expandUCNs clang::NumericLiteralParser::NumericLiteralParser Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712090607:201712100011 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802060728:201802070205 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=460742694912 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 5999 in oss-fuzz: llvm: Stack-overflow in clang::Lexer::LexTokenInternal
Comment #1 on issue 5999 by ClusterFuzz-External: llvm: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5999#c1 ClusterFuzz has detected this issue as fixed in range 201802070205:201802070726. Detailed report: https://oss-fuzz.com/testcase?key=6031891724500992 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd43d2aee0 Crash State: clang::Lexer::LexTokenInternal clang::Lexer::Lex clang::Preprocessor::Lex Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802030906:201802040725 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802070205:201802070726 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6031891724500992 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 5999 in oss-fuzz: llvm: Stack-overflow in clang::Lexer::LexTokenInternal
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 5999 by ClusterFuzz-External: llvm: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5999#c2 ClusterFuzz testcase 6031891724500992 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 4664 in oss-fuzz: llvm/clang-fuzzer: ASSERT: *I == 'u' || *I == 'U'
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #6 on issue 4664 by ClusterFuzz-External: llvm/clang-fuzzer: ASSERT: *I == 'u' || *I == 'U' https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4664#c6 ClusterFuzz testcase 460742694912 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] [Bug 35744] [ELF] - -defsym incorrectly works with reserved symbols.
https://bugs.llvm.org/show_bug.cgi?id=35744 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from George Rimar --- r324461 -- 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 6076 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-gvn
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-02-07 Type: Bug New issue 6076 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-gvn https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6076 Detailed report: https://oss-fuzz.com/testcase?key=5610533957926912 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-gvn Fuzz target binary: llvm-opt-fuzzer--x86_64-gvn 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-gvn Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802050757:201802060728 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5610533957926912 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 36114] Merge r324422 to 6.0 branch ([LivePhysRegs] Fix handling of return instructions.)
https://bugs.llvm.org/show_bug.cgi?id=36114 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Hans Wennborg --- Merged in r324466. -- 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 36114, which changed state. Bug 36114 Summary: Merge r324422 to 6.0 branch ([LivePhysRegs] Fix handling of return instructions.) https://bugs.llvm.org/show_bug.cgi?id=36114 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6085 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: VI != valueNumbering.end() && "Value not numbered?"
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-02-07 Type: Bug New issue 6085 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: VI != valueNumbering.end() && "Value not numbered?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6085 Detailed report: https://oss-fuzz.com/testcase?key=6579784730542080 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-gvn Fuzz target binary: llvm-opt-fuzzer--x86_64-gvn Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: VI != valueNumbering.end() && "Value not numbered?" llvm::GVN::ValueTable::lookup llvm::GVN::performScalarPRE Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802050757:201802060728 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6579784730542080 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 36262] New: wrong code with opt -loop-rotate -licm
https://bugs.llvm.org/show_bug.cgi?id=36262
Bug ID: 36262
Summary: wrong code with opt -loop-rotate -licm
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: pauls...@linux.vnet.ibm.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19822
--> https://bugs.llvm.org/attachment.cgi?id=19822&action=edit
opt input for test case as seen in the description
Csmith generated a program, which was later reduced by creduce into:
int a = 0, b = 0, c = 0, e = 11, f = 0, h = 0;
long d = 0;
short *g = &f;
int *i = 0;
main() {
int *j = &b;
for (; e; e--) {
d = 9;
for (; d; d--)
*j = 8;
*g = h;
for (; a <= 9; a++)
i = &h;
j = i;
}
c = j;
printf("checksum = %X\n", f);
}
The correct output is "checksum = 8", per gcc -O0/-O1 etc.
It seems that licm / loop-rotate is doing something wrong:
bin/opt -mtriple=s390x-linux-gnu -mcpu=z13 -S -o out.opt.ll tc_licm_rotate.ll
-tbaa -sroa
bin/llc -mtriple=s390x-linux-gnu -mcpu=z13 -O0 out.opt.ll -o out.s
rm ./a.out; bin/clang -O0 -march=z13 out.s -o a.out; ./a.out
checksum = 8
bin/opt -mtriple=s390x-linux-gnu -mcpu=z13 -S -o out.opt.ll tc_licm_rotate.ll
-tbaa -sroa -loop-rotate -licm
bin/llc -mtriple=s390x-linux-gnu -mcpu=z13 -O0 out.opt.ll -o out.s
rm ./a.out; bin/clang -O0 -march=z13 out.s -o a.out; ./a.out
checksum = 0
In particular, the store of immediate 8 to f via *g never happens.
- *g points to f throughout function
- first iteration: *g is assigned value of h, which is 0. *i is set to point to
h, as is *j, via *i.
- second iteration: *j now points to h, so h gets value 8. f, via *g, should
then also get the same value.
With loop rotation and invariant code motion, the load of @h has been hoisted
to outside the outer loop, which is then stored just to @g just once after the
loop. This must be wrong.
--
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 36263] New: Assertion `CountVarDIE && "DIE for count is not yet instantiated"' failed.
https://bugs.llvm.org/show_bug.cgi?id=36263
Bug ID: 36263
Summary: Assertion `CountVarDIE && "DIE for count is not yet
instantiated"' failed.
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: david.stenb...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19823
--> https://bugs.llvm.org/attachment.cgi?id=19823&action=edit
IR reproducer.
Seen on trunk (rL324422).
When compiling the attached IR file using:
llc -O0 -filetype=asm -mtriple x86_64-unknown-linux-gnu -mcpu=x86-64 -o
./foo.s ./foo.opt.ll
the following crash is seen:
llc: ../lib/CodeGen/AsmPrinter/DwarfUnit.cpp:1355: void
llvm::DwarfUnit::constructSubrangeDIE(llvm::DIE &, const llvm::DISubrange *,
llvm::DIE *): Assertion `CountVarDIE && "DIE for count is not yet
instantiated"' failed.
#0 0x01d744f4 PrintStackTraceSignalHandler(void*)
(/repo/llvm/build-all-clang40/bin/llc+0x1d744f4)
#1 0x01d74836 SignalHandler(int)
(/repo/llvm/build-all-clang40/bin/llc+0x1d74836)
#2 0x7fdfdb120850 __restore_rt (/lib64/libpthread.so.0+0xf850)
#3 0x7fdfda2cb875 __GI_raise (/lib64/libc.so.6+0x32875)
#4 0x7fdfda2cce51 __GI_abort (/lib64/libc.so.6+0x33e51)
#5 0x7fdfda2c4740 __GI___assert_fail (/lib64/libc.so.6+0x2b740)
#6 0x013e7249 (/repo/llvm/build-all-clang40/bin/llc+0x13e7249)
#7 0x013e53d1 llvm::DwarfUnit::constructArrayTypeDIE(llvm::DIE&,
llvm::DICompositeType const*) (/repo/llvm/build-all-clang40/bin/llc+0x13e53d1)
#8 0x013e4400 llvm::DwarfUnit::constructTypeDIE(llvm::DIE&,
llvm::DICompositeType const*) (/repo/llvm/build-all-clang40/bin/llc+0x13e4400)
#9 0x013e345d llvm::DwarfUnit::getOrCreateTypeDIE(llvm::MDNode
const*) (/repo/llvm/build-all-clang40/bin/llc+0x13e345d)
#10 0x013e312c llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType
const*, llvm::dwarf::Attribute)
(/repo/llvm/build-all-clang40/bin/llc+0x13e312c)
#11 0x01414d71
llvm::DwarfCompileUnit::applyVariableAttributes(llvm::DbgVariable const&,
llvm::DIE&) (/repo/llvm/build-all-clang40/bin/llc+0x1414d71)
#12 0x01414758
llvm::DwarfCompileUnit::constructVariableDIEImpl(llvm::DbgVariable const&,
bool) (/repo/llvm/build-all-clang40/bin/llc+0x1414758)
#13 0x01413a97
llvm::DwarfCompileUnit::createScopeChildrenDIE(llvm::LexicalScope*,
llvm::SmallVectorImpl&, bool*)
(/repo/llvm/build-all-clang40/bin/llc+0x1413a97)
#14 0x0141337a
llvm::DwarfCompileUnit::constructScopeDIE(llvm::LexicalScope*,
llvm::SmallVectorImpl&)
(/repo/llvm/build-all-clang40/bin/llc+0x141337a)
#15 0x01413c9e
llvm::DwarfCompileUnit::createScopeChildrenDIE(llvm::LexicalScope*,
llvm::SmallVectorImpl&, bool*)
(/repo/llvm/build-all-clang40/bin/llc+0x1413c9e)
#16 0x0141337a
llvm::DwarfCompileUnit::constructScopeDIE(llvm::LexicalScope*,
llvm::SmallVectorImpl&)
(/repo/llvm/build-all-clang40/bin/llc+0x141337a)
#17 0x01413c9e
llvm::DwarfCompileUnit::createScopeChildrenDIE(llvm::LexicalScope*,
llvm::SmallVectorImpl&, bool*)
(/repo/llvm/build-all-clang40/bin/llc+0x1413c9e)
#18 0x0141337a
llvm::DwarfCompileUnit::constructScopeDIE(llvm::LexicalScope*,
llvm::SmallVectorImpl&)
(/repo/llvm/build-all-clang40/bin/llc+0x141337a)
#19 0x01413c9e
llvm::DwarfCompileUnit::createScopeChildrenDIE(llvm::LexicalScope*,
llvm::SmallVectorImpl&, bool*)
(/repo/llvm/build-all-clang40/bin/llc+0x1413c9e)
#20 0x01415ce7
llvm::DwarfCompileUnit::constructAbstractSubprogramScopeDIE(llvm::LexicalScope*)
(/repo/llvm/build-all-clang40/bin/llc+0x1415ce7)
The IR file was generated by running the following commands on the attached C
file:
clang -mllvm -disable-llvm-optzns -S -emit-llvm
--target=x86_64-unknown-linux-gnu -g foo.c -o ./foo.ll
opt -mcpu=x86-64 -always-inline -O1 -S -o ./foo.opt.ll ./foo.ll
I'm not very knowledgeable about LLVM's inner working for this, but I noted
that the vla_expr variable is not included in the list of local variables for
the scope when running createScopeChildrenDIE(), whereas it is that in the
input IR file:
!21 = distinct !DILexicalBlock(scope: !18, file: !1, line: 5, column: 31)
!22 = !DILocalVariable(name: "vla_expr", scope: !21, file: !1, line: 6, type:
!23)
!25 = !DILocalVariable(name: "vn", scope: !21, file: !1, line: 6, type: !26)
!26 = !DICompositeType(tag: DW_TAG_array_type, baseType: !10, elements: !27)
!27 = !{!28}
!28 = !DISubrange(count: !22)
--
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 36264] New: [SelectionDAG] HandleMergeInputChains gets stuck in infinite loop in calls to AddChains()
https://bugs.llvm.org/show_bug.cgi?id=36264 Bug ID: 36264 Summary: [SelectionDAG] HandleMergeInputChains gets stuck in infinite loop in calls to AddChains() Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 19825 --> https://bugs.llvm.org/attachment.cgi?id=19825&action=edit reduced testcase bin/clang -cc1 -triple s390x-ibm-linux -S -target-cpu z13 -w -o out.s -x ir tc_clang_hang.ll -O3 -- 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 36265] New: -fconstexpr-steps switch doesn't work as expected on Windows
https://bugs.llvm.org/show_bug.cgi?id=36265 Bug ID: 36265 Summary: -fconstexpr-steps switch doesn't work as expected on Windows Product: clang Version: trunk Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: lminkov...@outlook.com CC: llvm-bugs@lists.llvm.org Per Richard Smith: -Xclang passes arguments directly to clang's internal -cc1 frontend, which has a slightly different command line argument format for some flags. In this case, it needs the flag and its argument to be presented separately: -Xclang -fconstexpr-steps -Xclang 10 That said, we really should expose the -fconstexpr-steps= flag within the clang-cl driver (the GCC-compatible clang driver exposes it). -- 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 36266] New: llvm-objcopy doesn't support --only-keep-debug flag
https://bugs.llvm.org/show_bug.cgi?id=36266 Bug ID: 36266 Summary: llvm-objcopy doesn't support --only-keep-debug flag Product: tools Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: llvm-ar Assignee: unassignedb...@nondot.org Reporter: arichardson@gmail.com CC: llvm-bugs@lists.llvm.org I tried to build FreeBSD using llvm-objcopy instead of elftoolchain objcopy and it failed when running the following command: objcopy --only-keep-debug kernel.full kernel.debug Would be great if this could be implemented. There isn't a llvm-objcopy target so I'm not sure which product to assign this to. -- 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 36267] New: Less than ideal handling of variable names in Cyrillic alphabet
https://bugs.llvm.org/show_bug.cgi?id=36267
Bug ID: 36267
Summary: Less than ideal handling of variable names in Cyrillic
alphabet
Product: clang
Version: trunk
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: lminkov...@outlook.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The following example has a variable name in Russian:
int main() {
int переменная=1;
static_assert(переменная,"");
}
Wandbox.org compiles it with a correct error message:
prog.cc:3:16: error: static_assert expression is not an integral constant
expression
static_assert(переменная,"");
^~
prog.cc:3:16: note: read of non-const variable 'переменная' is not allowed in a
constant expression
prog.cc:2:6: note: declared here
int переменная=1;
^
On Windows however, that message looks as follows:
test.cpp(3,16): error: static_assert expression is not an integral constant
expression
static_assert(,"");
^~~~
test.cpp(3,16): note: read of non-const variable 'переменная' is not
allowed in a constant expression
test.cpp(2,6): note: declared here
int
=1;
^
This happens because the Windows console needs to be set to the UTF-8 code page
to properly show Cyrillic characters.
--
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 36268] New: "GlobalValue with non default visibility must be dso_local!"
https://bugs.llvm.org/show_bug.cgi?id=36268 Bug ID: 36268 Summary: "GlobalValue with non default visibility must be dso_local!" Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org, rafael.espind...@gmail.com After r322806, Clang fails to build Chromium for iOS. creduced test case: __attribute__((availability(ios, introduced = 11.0))) @interface a @end @implementation a @end $ clang -cc1 -triple thumbv7-apple-ios10.0.0 -emit-obj -fvisibility hidden -fvisibility-inlines-hidden -x objective-c++ a.ii GlobalValue with non default visibility must be dso_local! %struct._class_t* @"OBJC_CLASS_$_a" GlobalValue with non default visibility must be dso_local! %struct._class_t* @"OBJC_METACLASS_$_a" fatal error: error in backend: Broken module found, compilation aborted! -- 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 36270] New: [ValueTracking] Crash in computeKnownBitsFromAssume
https://bugs.llvm.org/show_bug.cgi?id=36270
Bug ID: 36270
Summary: [ValueTracking] Crash in computeKnownBitsFromAssume
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: llvm-bugs@lists.llvm.org
Reduced from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6033
define void @bar4(i32 %b) {
entry:
%B7 = xor i32 -1, 2147483647
%and1 = and i32 %b, 3
%B12 = lshr i32 %B7, %and1
%C1 = icmp ult i32 %and1, %B12
tail call void @llvm.assume(i1 %C1)
%cmp2 = icmp eq i32 0, %B12
tail call void @llvm.assume(i1 %cmp2)
unreachable
}
declare void @llvm.assume(i1)
--
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 36271] New: Assert due to overflow in IEEEFloat::convertPPCDoubleDoubleAPFloatToAPInt bitcast
https://bugs.llvm.org/show_bug.cgi?id=36271
Bug ID: 36271
Summary: Assert due to overflow in
IEEEFloat::convertPPCDoubleDoubleAPFloatToAPInt
bitcast
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Support Libraries
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org
Reduced from https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5779
opt -instcombine
Assertion failed: fs == opOK || fs == opInexact, file
F:\llvm\llvm\lib\Support\APFloat.cpp, line 2849
define void @i32_cast_cmp_oeq_int_0_uitofp_ppcf128() {
%f = uitofp i32 65536 to ppc_fp128
%B1 = fdiv ppc_fp128 %f, 0xM7FEF7C8E
%B6 = fdiv ppc_fp128 %f, %B1
store ppc_fp128 %B6, ppc_fp128* undef
ret void
}
--
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 36272] New: [LLD/ELF] - ICF folds functions with different LSDA.
https://bugs.llvm.org/show_bug.cgi?id=36272 Bug ID: 36272 Summary: [LLD/ELF] - ICF folds functions with different LSDA. Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: gri...@accesssoftek.com CC: llvm-bugs@lists.llvm.org Created attachment 19828 --> https://bugs.llvm.org/attachment.cgi?id=19828&action=edit test.c We knew about that (and had some patches in this direction, for example D38319 and others), but I do not think we had a realistic use case before. And it was probably not documented in bugtracker. I found this issue in binutils bugtracker today and verified it is reproduced with use of LLD head. (for reference: https://sourceware.org/bugzilla/show_bug.cgi?id=21066) test.c is attached. When compiled and linked with LLD and --icf=all it crashes: ./test caught expected exception ERROR: caught unexpected exception terminate called after throwing an instance of 'second_exception' Aborted (core dumped) without ICF output is: ./test caught expected exception caught expected exception -- 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 36273] New: Warnings on deprecated enumerators in switch statements are not useful
https://bugs.llvm.org/show_bug.cgi?id=36273
Bug ID: 36273
Summary: Warnings on deprecated enumerators in switch
statements are not useful
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: ibiryu...@google.com
CC: llvm-bugs@lists.llvm.org
In the following code clang will complain about deprecated enumerator:
// clang++ -std=c++11 input.cpp
enum X {
a = 1,
b [[deprecated]] = 2,
};
int foo(X x) {
switch(x) {
case a:
return 10;
case b: // complains that 'b' is deprecated
return 15;
}
return 20;
}
However, removing 'case b' will cause clang to complain about enumeration value
unhandled in the switch.
Maybe we should consider silencing the deprecation warnings in that case?
--
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 36274] New: [m32][debug] "Wrong topological sorting" in ScheduleDAG.cpp after r324359
https://bugs.llvm.org/show_bug.cgi?id=36274
Bug ID: 36274
Summary: [m32][debug] "Wrong topological sorting" in
ScheduleDAG.cpp after r324359
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org
This test fails at ScheduleDAG.cpp with "Wrong topological sorting" after
r324359 using debug build:
= nice.c ==
void foo (unsigned long);
unsigned int g = 0;
unsigned long long a [13] [2];
int main ()
{
unsigned long m = g;
unsigned long i = 0;
for (i = 0; i <= 12; i++)
a[i][0]++;
foo(m);
return 0;
}
===
>>> clang -v
clang version 7.0.0 (trunk 324464)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
>>> clang -c -m32 -O3 nice.c
clang-7.0: .../llvm/lib/CodeGen/ScheduleDAG.cpp:518: void
llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion
`Node2Index[SU.NodeNum] > Node2Index[PD.getSUnit()->NodeNum] && "Wrong
topological sorting"' failed.
This is small ll reproducer for llc:
= fine.ll =
target triple = "i386-unknown-linux-gnu"
@g = external local_unnamed_addr global i32, align 4
@a = external local_unnamed_addr global [13 x [2 x i64]], align 8
; Function Attrs: nounwind
define void @main() local_unnamed_addr #0 {
entry:
%0 = load i32, i32* @g, align 4
%1 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 0, i32 0), align 8
%inc = add i64 %1, 1
store i64 %inc, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 0, i32 0), align 8
%2 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 1, i32 0), align 8
%inc.1 = add i64 %2, 1
store i64 %inc.1, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 1, i32 0), align 8
%3 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 2, i32 0), align 8
%inc.2 = add i64 %3, 1
store i64 %inc.2, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 2, i32 0), align 8
%4 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 3, i32 0), align 8
%inc.3 = add i64 %4, 1
store i64 %inc.3, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 3, i32 0), align 8
%5 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 4, i32 0), align 8
%inc.4 = add i64 %5, 1
store i64 %inc.4, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 4, i32 0), align 8
%6 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 5, i32 0), align 8
%inc.5 = add i64 %6, 1
store i64 %inc.5, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 5, i32 0), align 8
%7 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 6, i32 0), align 8
%inc.6 = add i64 %7, 1
store i64 %inc.6, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 6, i32 0), align 8
%8 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 7, i32 0), align 8
%inc.7 = add i64 %8, 1
store i64 %inc.7, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 7, i32 0), align 8
%9 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 8, i32 0), align 8
%inc.8 = add i64 %9, 1
store i64 %inc.8, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 8, i32 0), align 8
%10 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 9, i32 0), align 8
%inc.9 = add i64 %10, 1
store i64 %inc.9, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 9, i32 0), align 8
%11 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 10, i32 0), align 8
%inc.10 = add i64 %11, 1
store i64 %inc.10, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 10, i32 0), align 8
%12 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 11, i32 0), align 8
%inc.11 = add i64 %12, 1
store i64 %inc.11, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 11, i32 0), align 8
%13 = load i64, i64* getelementptr inbounds ([13 x [2 x i64]], [13 x [2 x
i64]]* @a, i32 0, i32 12, i32 0), align 8
%inc.12 = add i64 %13, 1
store i64 %inc.12, i64* getelementptr inbounds ([13 x [2 x i64]],
[llvm-bugs] [Bug 36275] New: PDB "modules" section does not contain import libraries/DLLs
https://bugs.llvm.org/show_bug.cgi?id=36275 Bug ID: 36275 Summary: PDB "modules" section does not contain import libraries/DLLs Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: stefan.reinal...@molecular-matters.com CC: llvm-bugs@lists.llvm.org When producing a PDB using lld, the module list does not contain import DLLs such as kernel32.dll. PDBs produced by MSVC's linker will add entries such as "Import:KERNEL32.dll" for all import libraries that contributed to the final image. Furthermore, for symbols pulled in from import libraries (again e.g. kernel32.lib) the section contributions in the PDB will list the "* Linker *" compiland instead of the original import library. Is this something that could be changed in lld? It may seem unimportant, but it allows one to reconstruct the full paths of all libraries that were used to build the image, e.g. C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x86\kernel32.lib -- 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 36276] New: PDB * Linker * module does not contain incremental linking thunks
https://bugs.llvm.org/show_bug.cgi?id=36276 Bug ID: 36276 Summary: PDB * Linker * module does not contain incremental linking thunks Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: stefan.reinal...@molecular-matters.com CC: llvm-bugs@lists.llvm.org PDBs produced by MSVC's linker contain a * Linker * compiland that stores incremental linking thunks as SymTagThunk children of this linker compiland, such as the following (output produced using DIA2Dump): Thunk : [1005][0001:0005], target [A1B0][0001:91B0] Thunk : [100A][0001:000A], target [4720][0001:3720] Thunk : [100F][0001:000F], target [D800][0001:C800] PDBs produced by lld contain the * Linker * compiland (with environment and details), but don't store any thunks. Is this something that could be added to lld? -- 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 36277] New: PDB * Linker * module does not contain COFF groups
https://bugs.llvm.org/show_bug.cgi?id=36277 Bug ID: 36277 Summary: PDB * Linker * module does not contain COFF groups Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: stefan.reinal...@molecular-matters.com CC: llvm-bugs@lists.llvm.org PDBs produced by MSVC's linker contain a * Linker * compiland that stores COFF groups as SymTagCoffGroup children of this linker compiland, such as the following (output produced using DIA2Dump): CoffGroup : [0x0001:0x] 0x1000, len = 3310, characteristics = 6020, .text$di CoffGroup : [0x0002:0x030c] 0x0001630C, len = 0164, characteristics = 4040, .CRT$XCU CoffGroup : [0x000a:0x] 0x00023000, len = 0104, characteristics = 4040, .some_custom_read_only_section CoffGroup : [0x000c:0x] 0x00025000, len = 0104, characteristics = C040, .tls PDBs produced by lld contain the * Linker * compiland but don't store any COFF groups. Is this something that could be added to lld? This is *very* useful information for finding e.g. dynamic initializers, symbols in thread-local storage, as well as symbols in certain user-defined sections where you don't know the symbols' names beforehand, but need to be able to enumerate them. -- 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 36264] [SelectionDAG] HandleMergeInputChains gets stuck in infinite loop in calls to AddChains()
https://bugs.llvm.org/show_bug.cgi?id=36264 Nirav Dave changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Nirav Dave --- Ah. This isn't actually infinite, just ridiculously slow because we check through all chain paths to the first non TokenFactor. rL324491 fixes this by adding a quick redundancy check. -- 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 36253] llvm.bitreverse.i64 returns wrong value
https://bugs.llvm.org/show_bug.cgi?id=36253 Kai Nacke changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36278] New: Merge r324486 into the 6.0 branch : AMDGPU: Remove the s_buffer workaround for GFX9 chips
https://bugs.llvm.org/show_bug.cgi?id=36278 Bug ID: 36278 Summary: Merge r324486 into the 6.0 branch : AMDGPU: Remove the s_buffer workaround for GFX9 chips Product: new-bugs Version: 6.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mar...@gmail.com CC: llvm-bugs@lists.llvm.org Blocks: 35804 Is it OK to merge the following revision(s) to the 6.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.0.0 Release Blockers -- 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 36279] New: Merge r324487 into the 6.0 branch : AMDGPU: Add 32-bit constant address space
https://bugs.llvm.org/show_bug.cgi?id=36279 Bug ID: 36279 Summary: Merge r324487 into the 6.0 branch : AMDGPU: Add 32-bit constant address space Product: new-bugs Version: 6.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mar...@gmail.com CC: llvm-bugs@lists.llvm.org Blocks: 35804 Is it OK to merge the following revision(s) to the 6.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.0.0 Release Blockers -- 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 36280] New: [SLPVectorizer] 2-way parallel vectorization hurts perf on x86
https://bugs.llvm.org/show_bug.cgi?id=36280
Bug ID: 36280
Summary: [SLPVectorizer] 2-way parallel vectorization hurts
perf on x86
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19830
--> https://bugs.llvm.org/attachment.cgi?id=19830&action=edit
himeno.c source file
This is a reduction from the Himeno benchmark (attached). In the actual
benchmark, we lose 6% performance on AMD Jaguar when using SLP vectorization
because the extra insert/extract ops cost more than the savings from combining
2 scalar loads and 2 scalar fmul.
(p[1] * x) + z + (p[2] * y)
---
target triple = "x86_64-unknown-unknown"
define float @jacobi(float* %p, float %x, float %y, float %z) {
%gep1 = getelementptr float, float* %p, i64 1
%gep2 = getelementptr float, float* %p, i64 2
%p1 = load float, float* %gep1
%p2 = load float, float* %gep2
%mul1 = fmul float %p1, %x
%mul2 = fmul float %p2, %y
%add1 = fadd float %mul1, %z
%add2 = fadd float %mul2, %add1
ret float %add2
}
$ ./opt -slp-vectorizer minnn.ll -S
define float @jacobi(float* %p, float %x, float %y, float %z) {
%gep1 = getelementptr float, float* %p, i64 1
%gep2 = getelementptr float, float* %p, i64 2
%1 = bitcast float* %gep1 to <2 x float>*
%2 = load <2 x float>, <2 x float>* %1, align 4
%3 = insertelement <2 x float> undef, float %x, i32 0
%4 = insertelement <2 x float> %3, float %y, i32 1
%5 = fmul <2 x float> %4, %2
%6 = extractelement <2 x float> %5, i32 0
%add1 = fadd float %6, %z
%7 = extractelement <2 x float> %5, i32 1
%add2 = fadd float %7, %add1
ret float %add2
}
---
The x86 AVX code looks like this without SLP:
vmulss 4(%rdi), %xmm0, %xmm0
vmulss 8(%rdi), %xmm1, %xmm1
vaddss %xmm2, %xmm0, %xmm0
vaddss %xmm0, %xmm1, %xmm0
And this with SLP:
vmovsd 4(%rdi), %xmm3 # xmm3 = mem[0],zero
vinsertps $16, %xmm1, %xmm0, %xmm0 # xmm0 =
xmm0[0],xmm1[0],xmm0[2,3]
vmulps %xmm3, %xmm0, %xmm0
vaddss %xmm2, %xmm0, %xmm1
vmovshdup %xmm0, %xmm0# xmm0 = xmm0[1,1,3,3]
vaddss %xmm1, %xmm0, %xmm0
--
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 36282] New: Merge r324353 into the 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=36282 Bug ID: 36282 Summary: Merge r324353 into the 6.0 branch Product: libraries Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: b...@basnieuwenhuizen.nl CC: llvm-bugs@lists.llvm.org Blocks: 35804 r324353 fixes a GPU hang due to to a pseudo instruction generated with a new pattern not having SGPR->VGPR promotion support. "AMDGPU: Fix S_BUFFER_LOAD_DWORD_SGPR moveToVALU. It moves the offset to vgpr, but did not handle being called for any of the other arguments, while LLVM 5 would select BUFFER_LOAD_DWORD_OFFEN immediately, which does the right thing. This calls legalizeOperands to fix up the operands after we converted to a BUFFER_LOAD_DWORD_OFFEN." Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.0.0 Release Blockers -- 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 36008] Regression (r316268): erroneous -Wsign-compare for typeof(enum T) and typeof(enumValue)
https://bugs.llvm.org/show_bug.cgi?id=36008 Alex Lorenz changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Alex Lorenz --- r324514. -- 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 36008, which changed state. Bug 36008 Summary: Regression (r316268): erroneous -Wsign-compare for typeof(enum T) and typeof(enumValue) https://bugs.llvm.org/show_bug.cgi?id=36008 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31454] basic_string::push_back() crashes if sizeof(T)>sizeof(long long)
https://bugs.llvm.org/show_bug.cgi?id=31454 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marshall Clow (home) --- revision 324531 fixes this. -- 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 36256] [X86] Couple lit tests generate KMOVQ instructions on KNL which doesn't support KMOVQ
https://bugs.llvm.org/show_bug.cgi?id=36256 Craig Topper changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Craig Topper --- Fixed in r324533 -- 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 35629] i/o fragmentation inside fstream.
https://bugs.llvm.org/show_bug.cgi?id=35629 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #7 from Marshall Clow (home) --- I don't believe that this is a libc++ bug. If you feel this is in error, please reopen the bug and provide more information. -- 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 36286] New: Implement constant string merging
https://bugs.llvm.org/show_bug.cgi?id=36286 Bug ID: 36286 Summary: Implement constant string merging Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org We should implement the constant string merging for the COFF version of lld, just like we did for ELF, to reduce output size. Unlike ELF, COFF sections that contain constant strings don't have any special section type, but we can identify them by looking at their symbol name. So it's doable. -- 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 36287] New: String merging for symbol names
https://bugs.llvm.org/show_bug.cgi?id=36287 Bug ID: 36287 Summary: String merging for symbol names Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org We merge strings for mergeable string sections, but we don't for regular string tables which contains symbol names. We should merge strings in the string table at least when -O2 is specified to produce smaller binaries. -- 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 36055, which changed state. Bug 36055 Summary: Reproducible Clang crash + strongly suspected invalid code generation https://bugs.llvm.org/show_bug.cgi?id=36055 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36055] Reproducible Clang crash + strongly suspected invalid code generation
https://bugs.llvm.org/show_bug.cgi?id=36055 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Smith --- Fixed in r324537. -- 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 36288] New: Merge clang r324419 into 6.0 branch: [Lex] Fix handling numerical literals ending with ' and signed exponent.
https://bugs.llvm.org/show_bug.cgi?id=36288 Bug ID: 36288 Summary: Merge clang r324419 into 6.0 branch: [Lex] Fix handling numerical literals ending with ' and signed exponent. Product: clang Version: 6.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: vsap...@apple.com CC: h...@chromium.org, llvm-bugs@lists.llvm.org Blocks: 35804 This commit https://reviews.llvm.org/rC324419 fixes crash for invalid usage of digit separator introduced in C++14. The main reason to merge the fix is that it fixes OSS-Fuzz bug https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4588 which is classified as security issue. Regardless of their own security evaluations, I think clang vendors and users will benefit from this fix. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.0.0 Release Blockers -- 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 4664 in oss-fuzz: llvm/clang-fuzzer: ASSERT: *I == 'u' || *I == 'U'
Comment #7 on issue 4664 by vsap...@gmail.com: llvm/clang-fuzzer: ASSERT: *I == 'u' || *I == 'U' https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4664#c7 This is a duplicate of https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4588 For more details check that bug. -- 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 4588 in oss-fuzz: llvm/clang-fuzzer: Stack-buffer-overflow in clang::expandUCNs
Comment #8 on issue 4588 by vsap...@gmail.com: llvm/clang-fuzzer: Stack-buffer-overflow in clang::expandUCNs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4588#c8 Bug was fixed in revision 324419. It is an old bug that was exposed by switching to gnu++14 as the default dialect. -- 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 36165] [x86] LLVM folds R_X86_64_GOTTPOFF relocation loads into arbitrary instruction memory operands and assembles them
https://bugs.llvm.org/show_bug.cgi?id=36165 Chandler Carruth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Chandler Carruth --- Fixed in r324546. -- 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 36289] New: lld should produce better .hash section
https://bugs.llvm.org/show_bug.cgi?id=36289 Bug ID: 36289 Summary: lld should produce better .hash section Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org We support both .gnu.hash and .hash sections, but the support for the latter type is just for backward compatibility and produces an inefficient hash section. It seems like old Android loader doesn't support .gnu.hash, and we are using .hash for Android now, so we probably need to improve lld to produce better .hash section. -- 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 36268] "GlobalValue with non default visibility must be dso_local!"
https://bugs.llvm.org/show_bug.cgi?id=36268 Rafael Ávila de Espíndola changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Rafael Ávila de Espíndola --- 324551 and 324552. -- 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 36289] lld should produce better .hash section
https://bugs.llvm.org/show_bug.cgi?id=36289 Rui Ueyama changed: What|Removed |Added Resolution|--- |INVALID Status|ASSIGNED|RESOLVED --- Comment #1 from Rui Ueyama --- I investigated this a little and my conclusion is that the current .hash section isn't bad. The only parameter we can tweak in .hash section is the number of on-disk hash table entries, and currently we set it to the number of symbols. That's an arbitrary choice, but I don't think that's particularly bad. Thus I'm closing the 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6101 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal
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-02-08 Type: Bug New issue 6101 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6101 Detailed report: https://oss-fuzz.com/testcase?key=6574423067852800 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::SelectionDAGBuilder::getValueImpl llvm::SelectionDAGBuilder::getValue Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712190608:201712210617 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6574423067852800 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 36290] New: False memory leak report involving self-deleting object
https://bugs.llvm.org/show_bug.cgi?id=36290 Bug ID: 36290 Summary: False memory leak report involving self-deleting object Product: clang Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: dcough...@apple.com Reporter: jakob.le...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 19836 --> https://bugs.llvm.org/attachment.cgi?id=19836&action=edit Example code that generates false memory leak report The attached example reports a potential memory leak: $ scan-build-6.0 clang++-6.0 -std=c++14 example.cpp example.cpp:19:1: warning: Potential leak of memory pointed to by 'p' } ^ I believe there is no memory leak in this example though. The example exhibits a pattern sometimes used in smart pointer implementations, such as Poco::AutoPtr: https://pocoproject.org/docs/Poco.AutoPtr.html I believe the same issue in the static analyzer causes memory leak and null-pointer dereference warnings when using Poco::AutoPtr. -- 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 36291] New: Contents of .ARM.attributes should be based on target-cpu and target-features function attributes
https://bugs.llvm.org/show_bug.cgi?id=36291 Bug ID: 36291 Summary: Contents of .ARM.attributes should be based on target-cpu and target-features function attributes Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: pe...@pcc.me.uk CC: llvm-bugs@lists.llvm.org I think the way that this should work is that we should emit a separate .ARM.attributes section for each unique cpu/features pair. Any linker that wants to accept LTO object files should be prepared to understand multiple .ARM.attributes sections. -- 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 36292] New: Invalid PPC CTR loop with llc on powerpc64le-unknown-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=36292 Bug ID: 36292 Summary: Invalid PPC CTR loop with llc on powerpc64le-unknown-linux-gnu Product: libraries Version: 6.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: k...@redstar.de CC: llvm-bugs@lists.llvm.org Created attachment 19837 --> https://bugs.llvm.org/attachment.cgi?id=19837&action=edit LLVM IR demonstring the problem. The attached file was bugpoint reduced from a unittest of the D library. Running llc -O2 bugpoint-reduced-simplified.ll results in Invalid PPC CTR loop! UNREACHABLE executed at /home/ubuntu/llvm/lib/Target/PowerPC/PPCCTRLoops.cpp:751! ... Stack dump: 0. Program arguments: llc -O2 bugpoint-reduced-simplified.ll 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'. 2. Running pass 'PowerPC CTR Loops Verify' on function '@_D4core8internal7arrayop__T7arrayOpHTAfTfTQfVAyaa1_25VQja1_3dZQBjFNaNbNiNeQBlfQBpZQBt' Aborted (core dumped) Happens without -O2, too. -- 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 36035] lld error @ thin-lto: --plugin-opt: unknown option: -debugger-tune=gdb
https://bugs.llvm.org/show_bug.cgi?id=36035 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from George Rimar --- (In reply to Rafael Ávila de Espíndola from comment #6) > Can we close this? It does not seem that -Og is an issue of LLD. We have PR35895 which is about -Os. Since it has the same nature, I think we can close this PR in favor of it. Probably we could also close PR35895. Or at least we could discuss what behavior we may want from -Os, -Og options and handle them somehow. -- 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
