[llvm-bugs] [Bug 27505] New: clang frontend command failed due to signal
https://llvm.org/bugs/show_bug.cgi?id=27505 Bug ID: 27505 Summary: clang frontend command failed due to signal Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: s.singap...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I am building Android content-shell-apk on my Ubuntu (64-bit) 16.04 LTS laptop. (https://www.chromium.org/developers/how-tos/android-build-instructions) clang version 3.9.0 (trunk 266460) Target: arm--linux-android Build failed with crash. ../../content/browser/service_worker/service_worker_storage.cc 1.../../mojo/public/cpp/bindings/lib/interface_endpoint_client.h:127:53: current parser token ';' 2.../../mojo/public/cpp/bindings/lib/interface_endpoint_client.h:22:1: parsing namespace 'mojo' 3.../../mojo/public/cpp/bindings/lib/interface_endpoint_client.h:26:1: parsing namespace 'internal' 4.../../mojo/public/cpp/bindings/lib/interface_endpoint_client.h:34:1: parsing struct/union/class body 'InterfaceEndpointClient' 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 3.9.0 (trunk 266460) Target: arm--linux-android Thread model: posix InstalledDir: /home/sarath/WORK/CHROMIUM/chromium_android/src/out/Default/../../third_party/llvm-build/Release+Asserts/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/service_worker_storage-fdc0b3.cpp clang: note: diagnostic msg: /tmp/service_worker_storage-fdc0b3.sh clang: note: diagnostic msg: [11030/15230] CXX obj/content/browser/browser/service_worker_version.o ninja: build stopped: subcommand failed. ++ Please see the attachments. -- 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 27506] New: GVN's propagateEquality propagates wrong equality
https://llvm.org/bugs/show_bug.cgi?id=27506 Bug ID: 27506 Summary: GVN's propagateEquality propagates wrong equality Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: kyoo...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16264 --> https://llvm.org/bugs/attachment.cgi?id=16264&action=edit llvm code that exposes error GVN's `propagateEquality` propagates wrong equality related to icmp instructions. When it propagates such as "(icmp eq A B) == true", it also propagates "A == B". However, this may cause an incorrect behavior if either A or B is an undefined value. When the source code like below is given, GVN transforms the "b1" block as shown. Suppose %x has a normal value and %u has the undef value. In the source, "%aa" is always defined. However, in the target, "%aa" is replaced with "%u", which is undef. We attach an input llvm file of "opt -gvn" and a C example code that exposes the same problem when compiled using "clang -O2". We tested this in both clang 3.7.1 and the trunk. b0: %a = add i32 %x, 1 %c = icmp eq i32 %a, %u br i1 %c, label %b1, label %b2 b1: %aa = add i32 %x, 1 %d = call i32 @bar(i32 %aa) -> b1: %d = call i32 @bar(i32 %u) -- 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 27387] ADD8TLS accepts r0 as source
https://llvm.org/bugs/show_bug.cgi?id=27387 Marcin Kościelnicki changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marcin Kościelnicki --- Fixed by r267388. -- 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 26206] TestExitDuringStep sometimes hangs on android
https://llvm.org/bugs/show_bug.cgi?id=26206 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from lab...@google.com --- Does not seem to be reproducible anymore... -- 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 27508] New: [MC] X86 intel syntax: push immediate misassembled to a 16 bit push
https://llvm.org/bugs/show_bug.cgi?id=27508 Bug ID: 27508 Summary: [MC] X86 intel syntax: push immediate misassembled to a 16 bit push Product: libraries Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: teeem...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When assembling with intel syntax for i386, pushing an immediate which has a value between -128 and 127 causes a pushw instruction to be emitted (decrements esp by 2 bytes) instead of the correct pushl (decrements by 4 bytes). pushw is selected by the 0x66 prefix. > echo 'push 0' | llvm-mc -triple i386-unknown-unknown --x86-asm-syntax=intel -filetype obj | llvm-objdump -d - ... 0:66 6a 00 pushw$0 (Outputting -filetype asm directly shows the same result) Each of pushw and pushl has two different opcodes, 0x6a for 8 bit immediate, and 0x68 for a 16 or 32bit immediate. If the value doesn't fit in 8 bits, the correct opcode is emitted: > echo 'push 128' | llvm-mc -triple i386-unknown-unknown --x86-asm-syntax=intel -filetype obj | llvm-objdump -d - ... 0:68 80 00 00 00 pushl$128 There's no problem when using at&t syntax: > echo 'push $0' | llvm-mc -triple i386-unknown-unknown --x86-asm-syntax=att -filetype obj | llvm-objdump -d - ... 0:6a 00 pushl$0 Nor when targetting x86_64: > echo 'push 0' | llvm-mc -triple x86_64-unknown-unknown --x86-asm-syntax=intel -filetype obj | llvm-objdump -d - ... 0:6a 00 pushq$0 llvm-mc is latest stable: LLVM (http://llvm.org/): LLVM version 3.8.0 Optimized build. Built Mar 8 2016 (17:36:36). Default target: x86_64-unknown-linux-gnu Host CPU: amdfam10 I actually couldn't figure out what the intel syntax equivalent for pushw is, if any exists. Anyone know? It doesn't appear to be very popular on i386/x86_64. -- 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 27509] New: Function Passes inadvertently skipped
https://llvm.org/bugs/show_bug.cgi?id=27509
Bug ID: 27509
Summary: Function Passes inadvertently skipped
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: jesper.antons...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
In opt.cpp, if there are any passes specified in the argument list after an
optimizaton level is specified, the OptLevelO is set to false by code like
this:
if (OptLevelO3 && OptLevelO3.getPosition() < PassList.getPosition(i)) {
AddOptimizationPasses(Passes, *FPasses, 3, 0);
OptLevelO3 = false;
}
This seems to be done to avoid rerunning AddOptimizationPasses(). But later,
FPasses is run only if any of these OptLevels are true:
if (OptLevelO1 || OptLevelO2 || OptLevelOs || OptLevelOz || OptLevelO3) {
FPasses->doInitialization();
for (Function &F : *M)
FPasses->run(F);
FPasses->doFinalization();
}
Thus FPasses is not run and I consider that a bug. My suggestion for a bugfix
is simple:
--- a/tools/opt/opt.cpp
+++ b/tools/opt/opt.cpp
@@ -598,7 +598,7 @@ int main(int argc, char **argv) {
if (OptLevelO3)
AddOptimizationPasses(Passes, *FPasses, 3, 0);
- if (OptLevelO1 || OptLevelO2 || OptLevelOs || OptLevelOz || OptLevelO3) {
+ if (FPasses) {
FPasses->doInitialization();
for (Function &F : *M)
FPasses->run(F);
BR,
Jesper Antonsson, Ericsson AB
--
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 27463] Privatizing struct fields with array type causes code generation failure.
https://llvm.org/bugs/show_bug.cgi?id=27463 Alexey Bataev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Alexey Bataev --- Fixed in rL267125. -- 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 27510] New: TestBitfields fails on linux with clang>=3.9
https://llvm.org/bugs/show_bug.cgi?id=27510 Bug ID: 27510 Summary: TestBitfields fails on linux with clang>=3.9 Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified -- 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 27501] [WinEH] bad instruction ordering with function calls that might throw
https://llvm.org/bugs/show_bug.cgi?id=27501 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from David Majnemer --- Fixed in r267412. -- 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 27511] New: LLVMConstantAggregateZero is missing from C API and Go Bindings
https://llvm.org/bugs/show_bug.cgi?id=27511 Bug ID: 27511 Summary: LLVMConstantAggregateZero is missing from C API and Go Bindings Product: new-bugs Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: alain.kuchta+l...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16266 --> https://llvm.org/bugs/attachment.cgi?id=16266&action=edit Patch file to add ConstantAggregateZero to the C-API and Go Bindings LLVMConstantAggregateZero is missing from `include/llvm-c/Core.h` LLVMConstantAggregateZero is missing from `bindings/go/ir.org` This prevents C and Go API users from correctly initializing global array variables. Attached is a patch to fix this issue. Summary of Changes -- - Add declaration of LLVMConstantAggregateZero in `include/llvm-c/Core.h` - Add definition of LLVMConstantAggregateZero in `lib/IR/Core.cpp` - Add definition of ConstantAggregateZero in `bindings/go/llvm/ir.go' -- 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 27511] LLVMConstantAggregateZero is missing from C API and Go Bindings
https://llvm.org/bugs/show_bug.cgi?id=27511 Alain Kuchta changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Alain Kuchta --- Ah, I see now! Thank you @Benjamin Kramer I didn't realize that functionality was provided by ConstNull() Marking Resolved -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27512] New: scan-build installation on windows missing pieces
https://llvm.org/bugs/show_bug.cgi?id=27512 Bug ID: 27512 Summary: scan-build installation on windows missing pieces Product: clang Version: trunk Hardware: PC OS: other Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: r...@newrelic.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I follow the latest set of instructions to download, configure and build llvm/clang 3.9.0 (trunk 267376) on an up-to-date windows10 system with Visual Studio 2013. I find that the perl scripts for scan-build and ccc-analyzer are not installed. The .bat files, which act as a trampoline through perl into the actual perl code is installed. I have been able to manually install a plausible scan-build perl script in place, compensate for installation path names, but then find I have to do the same thing for ccc-analyzer, at which point it starts getting tedious. -- 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 26255] Checks for UserLabelPrefix in freestanding mode are incorrect (?)
https://llvm.org/bugs/show_bug.cgi?id=26255 James Y Knight changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from James Y Knight --- Yes, this should be accurate for all targets now, by that change. -- 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 27513] New: error: 'std::basic_string, std::allocator >::_Alloc_hider' from module ...
https://llvm.org/bugs/show_bug.cgi?id=27513 Bug ID: 27513 Summary: error: 'std::basic_string, std::allocator >::_Alloc_hider' from module ... Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: biancacristinacriste...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified -- 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 27514] New: lldb assertion failure: (Offset >= Size), function insertPadding
https://llvm.org/bugs/show_bug.cgi?id=27514 Bug ID: 27514 Summary: lldb assertion failure: (Offset >= Size), function insertPadding Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: v...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Bot: lldb stage 1 RA (master) URL: http://lab.llvm.org:8080/green/job/lldb_build_test/17944/ Assertion failed: (Offset >= Size), function insertPadding, file /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp, line 610. [TestBitfields.py FAILED] Command invoked: /usr/bin/python /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/test/dotest.py --apple-sdk macosx --executable=/Users/buildslave/jenkins/sharedspace/lldb@2/lldb-build/Build/Products/Debug/lldb -C /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm-build/Release+Asserts/x86_64/bin/clang --rerun-all-issues --env TERM=vt100 -s 2016-04-25-07_48_36 --results-port 49957 --inferior -p TestBitfields.py /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test --event-add-entries worker_index=3:int -- 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 27515] New: TestBitfields hits assert on OS X: Assertion failed: (Offset >= Size), function insertPadding, CGRecordLayoutBuilder.cpp
https://llvm.org/bugs/show_bug.cgi?id=27515 Bug ID: 27515 Summary: TestBitfields hits assert on OS X: Assertion failed: (Offset >= Size), function insertPadding, CGRecordLayoutBuilder.cpp Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Possibly a dupe of 27510 but is happening on Xcode 7.3.0, which is not the same named version of clang in 27510. -- 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 27514] lldb assertion failure: (Offset >= Size), function insertPadding
https://llvm.org/bugs/show_bug.cgi?id=27514 Vedant Kumar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Vedant Kumar --- *** This bug has been marked as a duplicate of bug 27515 *** -- 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 27508] [MC] X86 intel syntax: push immediate misassembled to a 16 bit push
https://llvm.org/bugs/show_bug.cgi?id=27508 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |DUPLICATE --- Comment #1 from Reid Kleckner --- *** This bug has been marked as a duplicate of bug 22028 *** -- 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 27513] error: 'std::basic_string, std::allocator >::_Alloc_hider' from module ...
https://llvm.org/bugs/show_bug.cgi?id=27513 David Blaikie changed: What|Removed |Added Status|NEW |RESOLVED CC||dblai...@gmail.com Resolution|--- |INVALID --- Comment #1 from David Blaikie --- PResumably this needs a lot more info to be able to reproduce/know what you're referring 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 27516] New: test suite: add a skipUnless-style decorator for skipping unless libc++ is available
https://llvm.org/bugs/show_bug.cgi?id=27516 Bug ID: 27516 Summary: test suite: add a skipUnless-style decorator for skipping unless libc++ is available Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is meant to implement: https://bugs.swift.org/browse/SR-800 >From there: Upstream llvm.org Linux folks currently assume using gcc as a compiler is a sufficient guard against building on a Linux without libc++. However, on Swift Ubuntu, we build on Linux with clang (rather than gcc) but don't have libc++. So the "compiling with clang" skipUnless variant isn't sufficient. Also, it's not really checking the key piece: whether libc++ is available. -- 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 27517] New: TestStepOverWatchpoint.py fails in VMWare Ubuntu guest on VMWare Fusion
https://llvm.org/bugs/show_bug.cgi?id=27517 Bug ID: 27517 Summary: TestStepOverWatchpoint.py fails in VMWare Ubuntu guest on VMWare Fusion Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified From: https://bugs.swift.org/browse/SR-796 FAIL: test_dwarf (functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py) FAIL: test_dwo (functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py) A while back I researched this. It is possible to find out that a Linux client is running in a VMWare host. Add a decorator that allows skipping a test if we're (1) Linux, and (2) running under a VMWare Host. -- 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 27466] test/DebugInfo/PDB/Inputs/empty.pdb broken on some bots
https://llvm.org/bugs/show_bug.cgi?id=27466 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |FIXED --- Comment #1 from Reid Kleckner --- Patch got reverted, fixed, relanded, everything looks green now. -- 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 27518] New: Fuzz failures on wasm backend
https://llvm.org/bugs/show_bug.cgi?id=27518 Bug ID: 27518 Summary: Fuzz failures on wasm backend Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: alonza...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The emscripten test suite has a bunch of fuzz tests, and the wasm backend fails on several. The smallest is 3.c. STR: in emscripten (with .emscripten set up to use latest vanilla llvm) ./emcc tests/fuzz/3.c -I tests/fuzz/include/ -w clang tests/fuzz/3.c -I tests/fuzz/include/ -w nodejs a.out.js ./a.out The outputs should be identical, but are checksum = EE4B2FFC checksum = EE4B2FFC This is csmith output, so running with argument '1' will print out the intermediate hash results, which is helpful sometimes. -- 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 27519] New: Missed induction variable optimizations (-m64 -O2 -march=slm)
https://llvm.org/bugs/show_bug.cgi?id=27519 Bug ID: 27519 Summary: Missed induction variable optimizations (-m64 -O2 -march=slm) Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: andrew.senkev...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16267 --> https://llvm.org/bugs/attachment.cgi?id=16267&action=edit Small reproducer Hi, for attached test Clang generates 5% slower code than GCC due to missed optimizations of induction variable. Clang assembly for hottest loop: 4005c0:8b 1fmov(%rdi),%ebx 4005c2:0f af 1e imul (%rsi),%ebx 4005c5:83 c2 01 add$0x1,%edx 4005c8:48 81 c7 24 03 00 00 add$0x324,%rdi 4005cf:48 83 c6 04 add$0x4,%rsi 4005d3:01 d9add%ebx,%ecx 4005d5:39 d0cmp%edx,%eax 4005d7:75 e7jne4005c0 GCC assembly: 400410:8b 94 87 60 10 60 00 mov0x601060(%rdi,%rax,4),%edx 400417:48 83 c0 01 add$0x1,%rax 40041b:48 81 c1 24 03 00 00 add$0x324,%rcx 400422:0f af 91 dc fc ff ff imul -0x324(%rcx),%edx 400429:01 d6add%edx,%esi 40042b:41 39 c0 cmp%eax,%r8d 40042e:7f e0jg 400410 And the same for outer loop. -- 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 27520] New: on handling Instruction::AddrSpaceCast in stripPointerCastsAndOffsets() at Value.cpp
https://llvm.org/bugs/show_bug.cgi?id=27520
Bug ID: 27520
Summary: on handling Instruction::AddrSpaceCast in
stripPointerCastsAndOffsets() at Value.cpp
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: jack@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Function stripPointerCastsAndOffsets() at Value.cpp will handle the
AddrSpaceCast case as follows:
static Value *stripPointerCastsAndOffsets(Value *V) {
...
} else if (Operator::getOpcode(V) == Instruction::BitCast ||
Operator::getOpcode(V) == Instruction::AddrSpaceCast) {
V = cast(V)->getOperand(0);
} else if (GlobalAlias *GA = dyn_cast(V)) {
...
This does not look correct, since according to LLVM langref, "The
‘addrspacecast‘ instruction converts the pointer value ptrval to type pty2. It
can be a no-op cast or a complex value modification, depending on the target
and the address space pair."
Should we remove the check of Instruction::AddrSpaceCast here?
--
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 27521] New: Assert in "Simple Register Coalescing" after load-store-opt in AMDGPU backend
https://llvm.org/bugs/show_bug.cgi?id=27521 Bug ID: 27521 Summary: Assert in "Simple Register Coalescing" after load-store-opt in AMDGPU backend Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: changpeng.f...@amd.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16268 --> https://llvm.org/bugs/attachment.cgi?id=16268&action=edit reduced.ll For the reduced case bug.ll attached, I see an assert in "Simple Register Coalescing" pass. This pass was added after load-store-opt in AMDGPU backend. chfang@fijilc:~/amd/llvm/build/bin$ ./llc -mtriple=amdgcn--amdhsa -mcpu=fiji -mattr=+load-store-opt reduced.ll -o isa.txt llc: /home/chfang/amd/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:414: void extendSegmentsToUses(llvm::LiveRange&, const llvm::SlotIndexes&, ShrinkToUsesWorkList&, const llvm::LiveRange&): Assertion `OldRange.getVNInfoBefore(Stop) == VNI && "Wrong value out of predecessor"' failed. #0 0x025c728f llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/chfang/amd/llvm/lib/Support/Unix/Signals.inc:322:0 #1 0x025c75a4 PrintStackTraceSignalHandler(void*) /home/chfang/amd/llvm/lib/Support/Unix/Signals.inc:380:0 #2 0x025c5cbc llvm::sys::RunSignalHandlers() /home/chfang/amd/llvm/lib/Support/Signals.cpp:44:0 #3 0x025c6db6 SignalHandler(int) /home/chfang/amd/llvm/lib/Support/Unix/Signals.inc:210:0 #4 0x7faffe71f340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #5 0x7faffd93ecc9 gsignal /build/eglibc-3GlaMS/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #6 0x7faffd9420d8 abort /build/eglibc-3GlaMS/eglibc-2.19/stdlib/abort.c:91:0 #7 0x7faffd937b86 __assert_fail_base /build/eglibc-3GlaMS/eglibc-2.19/assert/assert.c:92:0 #8 0x7faffd937c32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #9 0x01d8db43 extendSegmentsToUses(llvm::LiveRange&, llvm::SlotIndexes const&, llvm::SmallVector, 16u>&, llvm::LiveRange const&) /home/chfang/amd/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:415:0 #10 0x01d8e0ae llvm::LiveIntervals::shrinkToUses(llvm::LiveInterval*, llvm::SmallVectorImpl*) /home/chfang/amd/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:472:0 #11 0x01fceb4f llvm::LiveRangeEdit::eliminateDeadDefs(llvm::SmallVectorImpl&, llvm::ArrayRef) /home/chfang/amd/llvm/lib/CodeGen/LiveRangeEdit.cpp:355:0 #12 0x01eddde7 (anonymous namespace)::RegisterCoalescer::eliminateDeadDefs() /home/chfang/amd/llvm/lib/CodeGen/RegisterCoalescer.cpp:463:0 #13 0x01ee2a53 (anonymous namespace)::RegisterCoalescer::joinCopy(llvm::MachineInstr*, bool&) /home/chfang/amd/llvm/lib/CodeGen/RegisterCoalescer.cpp:1375:0 #14 0x01ee9fb8 (anonymous namespace)::RegisterCoalescer::copyCoalesceWorkList(llvm::MutableArrayRef) /home/chfang/amd/llvm/lib/CodeGen/RegisterCoalescer.cpp:2812:0 #15 0x01eeaad1 (anonymous namespace)::RegisterCoalescer::coalesceLocals() /home/chfang/amd/llvm/lib/CodeGen/RegisterCoalescer.cpp:2938:0 #16 0x01eeaf30 (anonymous namespace)::RegisterCoalescer::joinAllIntervals() /home/chfang/amd/llvm/lib/CodeGen/RegisterCoalescer.cpp:2972:0 #17 0x01eeb28a (anonymous namespace)::RegisterCoalescer::runOnMachineFunction(llvm::MachineFunction&) /home/chfang/amd/llvm/lib/CodeGen/RegisterCoalescer.cpp:3018:0 #18 0x01e0a8f3 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /home/chfang/amd/llvm/lib/CodeGen/MachineFunctionPass.cpp:60:0 #19 0x020fedf8 llvm::FPPassManager::runOnFunction(llvm::Function&) /home/chfang/amd/llvm/lib/IR/LegacyPassManager.cpp:1550:0 #20 0x020fef8b llvm::FPPassManager::runOnModule(llvm::Module&) /home/chfang/amd/llvm/lib/IR/LegacyPassManager.cpp:1571:0 #21 0x020ff326 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /home/chfang/amd/llvm/lib/IR/LegacyPassManager.cpp:1627:0 #22 0x020ffa76 llvm::legacy::PassManagerImpl::run(llvm::Module&) /home/chfang/amd/llvm/lib/IR/LegacyPassManager.cpp:1730:0 #23 0x020ffcb7 llvm::legacy::PassManager::run(llvm::Module&) /home/chfang/amd/llvm/lib/IR/LegacyPassManager.cpp:1762:0 #24 0x00dbf7a0 compileModule(char**, llvm::LLVMContext&) /home/chfang/amd/llvm/tools/llc/llc.cpp:415:0 #25 0x00dbe575 main /home/chfang/amd/llvm/tools/llc/llc.cpp:218:0 #26 0x7faffd929ec5 __libc_start_main /build/eglibc-3GlaMS/eglibc-2.19/csu/libc-start.c:321:0 #27 0x00dbcdf9 _start (/home/chfang/amd/llvm/build/bin/llc+0xdbcdf9) Stack dump: 0.Program arguments: ./llc -mtriple=amdgcn--amdhsa -mcpu=fiji -mattr=+load-store-opt reduced.ll -o isa.txt 1.Running pass 'Function Pass Manager' on module 'reduced.ll'. 2.Running pass 'Si mple Register Coalescing'
[llvm-bugs] [Bug 27522] New: Inefficient passing of byval parameters
https://llvm.org/bugs/show_bug.cgi?id=27522
Bug ID: 27522
Summary: Inefficient passing of byval parameters
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider:
target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
target triple = "i686-pc-windows-msvc18.0.0"
%struct.S = type { i32 }
define void @f() {
entry:
%agg.tmp = alloca %struct.S
%x = getelementptr inbounds %struct.S, %struct.S* %agg.tmp, i32 0, i32 0
store i32 42, i32* %x
call void @g(%struct.S* byval nonnull align 4 %agg.tmp)
ret void
}
declare void @g(%struct.S* byval align 4)
$ bin/llc /tmp/a.ll -o -
[..]
_f: # @f
# BB#0: # %entry
subl$8, %esp
movl$42, 4(%esp)
movl4(%esp), %eax
movl%eax, (%esp)
calll _g
addl$8, %esp
retl
That's quite a round-about way to put 42 on the stack.
Another example:
struct S {
int x;
};
void g(S);
void f(int x) {
g({x});
}
$ bin/clang++ -target i686-pc-win32 -O3 -S -o - /tmp/a.cc
[..]
# BB#0: # %entry
subl$8, %esp
movl12(%esp), %eax
movl%eax, 4(%esp)
movl4(%esp), %eax
movl%eax, (%esp)
calll "?g@@YAXUS@@@Z"
addl$8, %esp
retl
We could just jump to g() directly instead :-)
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27523] New: loop-unroll and simplifycfg cause oscillation with phi node arguments
https://llvm.org/bugs/show_bug.cgi?id=27523 Bug ID: 27523 Summary: loop-unroll and simplifycfg cause oscillation with phi node arguments Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: nwilso...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16269 --> https://llvm.org/bugs/attachment.cgi?id=16269&action=edit scfg_loop_unroll.ll When using the flags -simplifycfg and -loop-unroll on the attached IR (scfg_loop_unroll.ll) the phi nodes will keep flipping. This was produced by using the attached IR and using the output as input back to opt. For example: $./opt -simplifycfg -loop-unroll -S scfg_loop_unroll.ll > out1.ll $ ./opt -simplifycfg -loop-unroll -S out1.ll > out2.ll $./opt -simplifycfg -loop-unroll -S out2.ll > out3.ll $diff out2.ll out1.ll 1c1 < ; ModuleID = 'out1.ll' --- > ; ModuleID = 'simplifycfg_loop-unroll_osc.ll' 130c130 < %.ph = phi i32 [ %3, %if.then20 ], [ undef, %if.end27 ] --- > %.ph = phi i32 [ undef, %if.end27 ], [ %3, %if.then20 ] $diff out3.ll out2.ll 1c1 < ; ModuleID = 'out2.ll' --- > ; ModuleID = 'out1.ll' 130c130 < %.ph = phi i32 [ undef, %if.end27 ], [ %3, %if.then20 ] --- > %.ph = phi i32 [ %3, %if.then20 ], [ undef, %if.end27 ] -- 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 27524] New: return optimization opportunities
https://llvm.org/bugs/show_bug.cgi?id=27524 Bug ID: 27524 Summary: return optimization opportunities Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: alonza...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The wasm backend currently emits unnecessary returns, which are unnecessary since control flow goes out of the function anyhow, like a return at the very end of a function (which can be replaced with nothing, or with the value if there is one). On BananaBread, removing such returns eliminates 2906 out of 4142 (70%, 0.3% of total nodes). -- 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 27316] SROA always returning true (even though nothing has changed)
https://llvm.org/bugs/show_bug.cgi?id=27316 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |david.majne...@gmail.com --- Comment #1 from David Majnemer --- Fixed in r267507. -- 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
