[llvm-bugs] [Bug 27685] LLD doesn't like it if LLVM_LINK_LLVM_DYLIB is turned on
https://llvm.org/bugs/show_bug.cgi?id=27685 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED CC||gri...@accesssoftek.com Resolution|--- |FIXED --- Comment #7 from George Rimar --- According to comments above, fixed in r291432 -- 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 31571] lldb 3.8, 3.9 and 4.0 hang on Debian because of the classic "registered more than once" with lldb-server
https://llvm.org/bugs/show_bug.cgi?id=31571 lab...@google.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from lab...@google.com --- r291555 should fix this for the master (4.0) branch. As for the older releases, try the patch from #6. If it does not work, let me know. -- 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 31571] lldb 3.8, 3.9 and 4.0 hang on Debian because of the classic "registered more than once" with lldb-server
https://llvm.org/bugs/show_bug.cgi?id=31571
Sylvestre Ledru changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #8 from Sylvestre Ledru ---
Yeah, for some reason, the following patch doesn't work with 3.9:
diff --git a/lldb/cmake/modules/AddLLDB.cmake b/cmake/modules/AddLLDB.cmake
index 75c522f65..3d868068c 100644
--- a/lldb.orig/cmake/modules/AddLLDB.cmake
+++ b/lldb/cmake/modules/AddLLDB.cmake
@@ -93,7 +93,7 @@ macro(add_lldb_library name)
endmacro(add_lldb_library)
macro(add_lldb_executable name)
- add_llvm_executable(${name} DISABLE_LLVM_LINK_LLVM_DYLIB ${ARGN})
+ add_llvm_executable(${name} ${ARGN})
set_target_properties(${name} PROPERTIES FOLDER "lldb executables")
endmacro(add_lldb_executable)
diff --git a/lldb/tools/lldb-server/CMakeLists.txt
b/tools/lldb-server/CMakeLists.txt
index 28360914a..9d8a09b69 100644
--- a/lldb.orig/tools/lldb-server/CMakeLists.txt
+++ b/lldb/tools/lldb-server/CMakeLists.txt
@@ -43,7 +43,9 @@ else()
target_link_libraries(lldb-server ${LLDB_USED_LIBS})
target_link_libraries(lldb-server ${CLANG_USED_LIBS})
endif()
-llvm_config(lldb-server ${LLVM_LINK_COMPONENTS})
+if (NOT LLVM_LINK_LLVM_DYLIB)
+ llvm_config(lldb-server ${LLVM_LINK_COMPONENTS})
+endif()
target_link_libraries(lldb-server ${LLDB_SYSTEM_LIBS})
--
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 31571] lldb 3.8, 3.9 and 4.0 hang on Debian because of the classic "registered more than once" with lldb-server
https://llvm.org/bugs/show_bug.cgi?id=31571 Sylvestre Ledru changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Sylvestre Ledru --- 3.9 works great with the last patch, merci beaucoup! Hope this is the end of this issue. 3 different patches for the 3 branches won't scale :) Again, many thanks for this amazing help. -- 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 30581] Inconsistent value of ATOMIC_LLONG_LOCK_FREE vs __atomic_always_lock_free(sizeof(long long), 0) on 32-bit x86
https://llvm.org/bugs/show_bug.cgi?id=30581 Michał Górny changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Michał Górny --- commit 266cb72185242313c85a9f33dc33944da8b2b403 Author: Michal Gorny Date: Mon Jan 9 21:54:20 2017 [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin Correct the logic used to set ATOMIC_*_LOCK_FREE preprocessor macros not to rely on the ABI alignment of types. Instead, just assume all those types are aligned correctly by default since clang uses safe alignment for _Atomic types even if the underlying types are aligned to a lower boundary by default. For example, the 'long long' and 'double' types on x86 are aligned to 32-bit boundary by default. However, '_Atomic long long' and '_Atomic double' are aligned to 64-bit boundary, therefore satisfying the requirements of lock-free atomic operations. This fixes PR #19355 by correcting the value of __GCC_ATOMIC_LLONG_LOCK_FREE on x86, and therefore also fixing the assumption made in libc++ tests. This also fixes PR #30581 by applying a consistent logic between the functions used to implement both interfaces. Differential Revision: https://reviews.llvm.org/D28213 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291477 91177308-0d34-0410-b5e6-96231b3b80d8 -- 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 31596] New: deduce icmp result from llvm.assume
https://llvm.org/bugs/show_bug.cgi?id=31596
Bug ID: 31596
Summary: deduce icmp result from llvm.assume
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Filing this based on a question from Daniel Berlin:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170109/418024.html
declare void @llvm.assume(i1)
define i1 @deduce_icmp_from_assume(i8 %a, i8 %b) {
%eqcond = icmp eq i8 %a, %b
call void @llvm.assume(i1 %eqcond)
%ltcond = icmp slt i8 %a, %b
ret i1 %ltcond
}
--
Some pass (don't know which one yet because the line between analysis and the
compile-time cost of that analysis is not clear) should be able to simplify
this to return 'false', but nothing in the -O2 pipeline as of r291443 handles
this.
FWIW, we already call computeKnownBits in InstCombiner::visitReturnInst() for
the stated purpose of checking assumptions:
// There might be assume intrinsics dominating this return that completely
// determine the value. If so, constant fold it.
...so this particular case could be handled by adding to the pattern-matching
logic in computeKnownBitsFromAssume() ( see https://reviews.llvm.org/D28485 ),
but of course that's not the most general solution.
More typically, we'd expect the 2nd icmp result to be used in a branch or
select, so calling value tracking (should computeKnownBitsFromAssume be raised
into the value tracking API?) when visiting those insts in InstCombine might be
a better way. I have a patch proposal for the select variant here:
https://reviews.llvm.org/D28337
There may be no good solution because the design of the llvm.assume intrinsic
itself just isn't ideal ( bug 31518, comment 10 ). Alternative suggestions are
that we should convert it to a form more like llvm.expect:
bug 31512, comment 4
That could lead to a lower-to-metadata pass such as "-lower-expect", so we
wouldn't have the problem of optimization intrinsics interfering with
optimization as noted by Eli here:
https://reviews.llvm.org/D27114
--
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 31597] New: Crash/assert when using regalloc= with -O0
https://llvm.org/bugs/show_bug.cgi?id=31597
Bug ID: 31597
Summary: Crash/assert when using regalloc= with -O0
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: llc
Assignee: unassignedb...@nondot.org
Reporter: jonathanchesterfi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Repro:
echo "define i32 @main() { ret i32 0 }" | llc -O0 --regalloc=basic
echo "define i32 @main() { ret i32 0 }" | llc -O0 --regalloc=greedy
echo "define i32 @main() { ret i32 0 }" | llc -O0 --regalloc=pbqp
Any of these cause a segfault on release builds of 3.9 and trunk. On a debug
build of trunk an assertion fires, stack trace below.
Older versions of llvm (checked 3.5 and 3.8) print "LLVM ERROR: regalloc=...
not currently supported with -O0"
This was discovered while debugging a probably unrelated issue in the fast
allocator when I tried to compare it with the basic allocator. Ideally the
allocators would all work correctly at O0, but failing that perhaps we should
reinstate the error message at O0.
Cheers
.text
.file""
MachineFunctionProperties required by X86 FP Stackifier pass are not met by
function main.
Required properties: NoVRegs
Current properties: NoPHIs, TracksLiveness
MachineFunctionProperties check failed
UNREACHABLE executed at
/home/jon/trunk/llvm/lib/CodeGen/MachineFunctionPass.cpp:58!
#0 0x02b18a53 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/jon/trunk/llvm/lib/Support/Unix/Signals.inc:402:0
#1 0x02b18e15 PrintStackTraceSignalHandler(void*)
/home/jon/trunk/llvm/lib/Support/Unix/Signals.inc:466:0
#2 0x02b17072 llvm::sys::RunSignalHandlers()
/home/jon/trunk/llvm/lib/Support/Signals.cpp:44:0
#3 0x02b183e5 SignalHandler(int)
/home/jon/trunk/llvm/lib/Support/Unix/Signals.inc:256:0
#4 0x7f89c8a9c7e0 __restore_rt (/lib64/libpthread.so.0+0xf7e0)
#5 0x7f89c77485e5 __GI_raise (/lib64/libc.so.6+0x325e5)
#6 0x7f89c7749dc5 __GI_abort (/lib64/libc.so.6+0x33dc5)
#7 0x02aa66b6 bindingsErrorHandler(void*, std::string const&, bool)
/home/jon/trunk/llvm/lib/Support/ErrorHandling.cpp:127:0
#8 0x02277517 llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
/home/jon/trunk/llvm/lib/CodeGen/MachineFunctionPass.cpp:62:0
#9 0x025fa128 llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/jon/trunk/llvm/lib/IR/LegacyPassManager.cpp:1513:0
#10 0x025fa2bb llvm::FPPassManager::runOnModule(llvm::Module&)
/home/jon/trunk/llvm/lib/IR/LegacyPassManager.cpp:1534:0
#11 0x025fa647 (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
/home/jon/trunk/llvm/lib/IR/LegacyPassManager.cpp:1590:0
#12 0x025fad38 llvm::legacy::PassManagerImpl::run(llvm::Module&)
/home/jon/trunk/llvm/lib/IR/LegacyPassManager.cpp:1693:0
#13 0x025faf79 llvm::legacy::PassManager::run(llvm::Module&)
/home/jon/trunk/llvm/lib/IR/LegacyPassManager.cpp:1725:0
#14 0x00fbcbf5 compileModule(char**, llvm::LLVMContext&)
/home/jon/trunk/llvm/tools/llc/llc.cpp:530:0
#15 0x00fbb311 main /home/jon/trunk/llvm/tools/llc/llc.cpp:285:0
#16 0x7f89c7734d1d __libc_start_main (/lib64/libc.so.6+0x1ed1d)
#17 0x00fb9551 _start (./llc+0xfb9551)
Stack dump:
0.Program arguments: ./llc -O0 --regalloc=basic
1.Running pass 'Function Pass Manager' on module ''.
2.Running pass 'X86 FP Stackifier' on function '@main'
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 31369] Register allocator uses reserved register on MIPS
https://llvm.org/bugs/show_bug.cgi?id=31369 Simon Dardis changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Simon Dardis --- Resolved by r291566. -- 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 31598] New: Clang-CL ICE with precompiled headers, export and parameter default initialization
https://llvm.org/bugs/show_bug.cgi?id=31598
Bug ID: 31598
Summary: Clang-CL ICE with precompiled headers, export and
parameter default initialization
Product: clang
Version: 3.9
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: steve...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Using the 3.9.1 binary package for Windows from
http://releases.llvm.org/download.html and the following sources, I get an ICE.
It works with the MSVC CL.exe:
c:\dev\tmp>type source_file.cpp
#include "header_file.h"
BoolValue::BoolValue(bool b)
{
}
c:\dev\tmp>type header_file.h
#pragma once
struct __declspec(dllexport) BoolValue
{
BoolValue(bool b = false);
};
c:\dev\tmp>"C:\Program Files\LLVM\msbuild-bin\CL.exe" /c /Ycheader_file.h /FI
header_file.h source_file.cpp
clang-cl.exe: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.9.1 (branches/release_39)
Target: x86_64-pc-windows-msvc
Thread model: posix
It also works if I remove the __declspec(dllexport) or if I remove the '=
false' from the header.
--
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 31599] New: SLPVectorizer.cpp Assertion `(VL0->getOperand(0) == VL0->getOperand(1)) && "Invalid order"' failed.
https://llvm.org/bugs/show_bug.cgi?id=31599 Bug ID: 31599 Summary: SLPVectorizer.cpp Assertion `(VL0->getOperand(0) == VL0->getOperand(1)) && "Invalid order"' failed. Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: russell_gal...@sn.scee.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17825 --> https://llvm.org/bugs/attachment.cgi?id=17825&action=edit Reduced IR Tested at r291446. $ opt bugpoint-reduced-simplified.ll -slp-vectorizer opt: .../llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:2497: llvm::Value* llvm::slpvectorizer::BoUpSLP::vectorizeTree(llvm::slpvectorizer::BoUpSLP::TreeEntry*): Assertion `(VL0->getOperand(0) == VL0->getOperand(1)) && "Invalid order"' failed. ... Stack dump: 0. Program arguments: opt bugpoint-reduced-simplified.ll -slp-vectorizer 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'. 2. Running pass 'SLP Vectorizer' on function '@_ZN1C5m_fn2Ev' Aborted (core dumped) -- 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 31600] New: Allow vector value types to use signext/zeroext attributes
https://llvm.org/bugs/show_bug.cgi?id=31600
Bug ID: 31600
Summary: Allow vector value types to use signext/zeroext
attributes
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com
Classification: Unclassified
As discussed on [Bug #28486], we don't currently support signext/zeroext
attributes on vector value types:
define <4 x i32> @boolext(<4 x i1> signext %a) {
%ext = sext <4 x i1> %a to <4 x i32>
ret <4 x i32> %ext
}
Doing so could help in a number of cases, for instance when passing around
mask/boolean vector data.
--
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 31519] [AArch64] bitreverse does not generate rbit
https://llvm.org/bugs/show_bug.cgi?id=31519 Chad Rosier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Chad Rosier --- Committed r291574 and r291575. -- 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 31054] Global Variable Optimizer segmentation fault on valid input
https://llvm.org/bugs/show_bug.cgi?id=31054 Matthias Braun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |ma...@braunis.de |org | --- Comment #5 from Matthias Braun --- Fix landed in clang r291576 -- 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 31598] Clang-CL ICE with precompiled headers, export and parameter default initialization
https://llvm.org/bugs/show_bug.cgi?id=31598 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED CC||r...@google.com Resolution|--- |DUPLICATE --- Comment #1 from Reid Kleckner --- I think this was fixed by https://reviews.llvm.org/D27007, which didn't make it to 3.9.1. *** This bug has been marked as a duplicate of bug 31121 *** -- 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 31367] X86: Generate smaller code for atomic refcount decrement
https://llvm.org/bugs/show_bug.cgi?id=31367 Hans Wennborg changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Hans Wennborg --- This was reverted in r290066 as it broke a lot of internal tests. I'm still not sure why this didn't work. GCC also prefers the simpler "lock sub" over "lock xadd", but it doesn't go as far as folding that to "lock dec". One theory is that our folding of "sub -1" to "dec" doesn't take into account that "dec" doesn't set CF, and something in the code that broke was somehow depending on CF. The DAG transform could also be broken in some other way of course. -- 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 26299] [meta][X86] Size optimization opportunities (in particular for 32-bit Chromium on Windows)
https://llvm.org/bugs/show_bug.cgi?id=26299 Bug 26299 depends on bug 31367, which changed state. Bug 31367 Summary: X86: Generate smaller code for atomic refcount decrement https://llvm.org/bugs/show_bug.cgi?id=31367 What|Removed |Added Status|RESOLVED|REOPENED 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 31190] opt crashes with "opt -simplifycfg -instcombine -loop-rotate -licm -loop-vectorize": Assertion `Idx >= 0 && "Invalid basic block argument!"' failed
https://llvm.org/bugs/show_bug.cgi?id=31190 Michael Kuperstein changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Michael Kuperstein --- Fixed in r291589. -- 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 31601] New: Incomplete ARMv7E-M support in ARM Assembler.
https://llvm.org/bugs/show_bug.cgi?id=31601 Bug ID: 31601 Summary: Incomplete ARMv7E-M support in ARM Assembler. Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: joerc...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17827 --> https://llvm.org/bugs/attachment.cgi?id=17827&action=edit Fix for bug report. Assembler is failing on statement: .arch armv7e-m reporting: clang -cc1as: fatal error: error in backend: Unknown Arch: 18 The reason appears to be a missing case label, attaching fix. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 21600] [AArch64] Prefer tbz/tbnz before cmp+br in AND expression
https://llvm.org/bugs/show_bug.cgi?id=21600 Chad Rosier changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Chad Rosier --- I'm not sure this really makes sense. The performance win I was seeing is due to one of the branches being heavily bias and should be guided by profile 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 22738] After r224456, clang++ fails to substitute some non-type template arguments
https://llvm.org/bugs/show_bug.cgi?id=22738 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Smith --- I implemented my idea from comment#1 in r290586; all the testcases on this bug are now accepted by Clang trunk. -- 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 31539] Assertion failed: ParentSEHFn && "No CurSEHParent!" when using pre-compiled headers
https://llvm.org/bugs/show_bug.cgi?id=31539 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Reid Kleckner --- Fixed in r291600 -- 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 26299] [meta][X86] Size optimization opportunities (in particular for 32-bit Chromium on Windows)
https://llvm.org/bugs/show_bug.cgi?id=26299 Bug 26299 depends on bug 31367, which changed state. Bug 31367 Summary: X86: Generate smaller code for atomic refcount decrement https://llvm.org/bugs/show_bug.cgi?id=31367 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31367] X86: Generate smaller code for atomic refcount decrement
https://llvm.org/bugs/show_bug.cgi?id=31367 Hans Wennborg changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Hans Wennborg --- Fixed the old problem in r291630 and re-committed my patch in r291640. -- 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 31602] New: [X86] float/double -> unsigned long conversion slow when inputs are predictable
https://llvm.org/bugs/show_bug.cgi?id=31602
Bug ID: 31602
Summary: [X86] float/double -> unsigned long conversion slow
when inputs are predictable
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: mku...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
SSE and AVX (up until AVX512) don't have convert instructions from FP (both
float or double) and unsigned long. So, these conversion have to be emulated
using FP -> signed long conversions.
GCC lowers this:
unsigned long foo(double x) {
return x;
}
as:
foo(double):
movsd .LC0(%rip), %xmm1
ucomisd %xmm1, %xmm0
jnb .L2
cvttsd2siq %xmm0, %rax
ret
.L2:
subsd %xmm1, %xmm0
movabsq $-9223372036854775808, %rdx
cvttsd2siq %xmm0, %rax
xorq%rdx, %rax
ret
.LC0:
.long 0
.long 1138753536
That is - check whether the value is in range, and if not, force it into range,
convert, and correct the value.
What we do, on the other hand, is:
.LCPI0_0:
.quad 4890909195324358656 # double 9.2233720368547758E+18
foo(double):
movsd .LCPI0_0(%rip), %xmm1
movapd %xmm0, %xmm2
subsd %xmm1, %xmm2
cvttsd2si %xmm2, %rax
movabsq $-9223372036854775808, %rcx # imm = 0x8000
xorq%rax, %rcx
cvttsd2si %xmm0, %rax
ucomisd %xmm1, %xmm0
cmovaeq %rcx, %rax
retq
Which is basically an if-converted version of the GCC code.
Since cvttsd2si has a fairly long latency, the GCC version is much faster when
the branch is well-predicted, and slower when it's not.
But it seems like in most cases this branch should be well-predicted - e.g. if
all inputs are "small", and actually fit into the signed range.
A few additional notes:
1) Our current version is problematic in the presence of FP exceptions, see
PR17686.
2) I tried playing around with selecting on the input instead of the output,
but that doesn't really improve the situation, since we then need to adjust the
sign bit of the output of one of the converts.
There are two options here - (1) adjusting and selecting again between the
original and the adjusted version, or (2) fudging the adjustment so that it's a
nop for the right convert. ICC generates code which is basically (2). This
avoids the problem in PR17686, but both options appear to be even slower than
what we have 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 30885] conversion from double to unsigned raises invalid operation
https://llvm.org/bugs/show_bug.cgi?id=30885 Michael Kuperstein changed: What|Removed |Added Status|NEW |RESOLVED CC||mku...@google.com Resolution|--- |DUPLICATE --- Comment #3 from Michael Kuperstein --- *** This bug has been marked as a duplicate of bug 17686 *** -- 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 31603] New: False positive Null pointer passed as an argument to a 'nonnull' parameter
https://llvm.org/bugs/show_bug.cgi?id=31603 Bug ID: 31603 Summary: False positive Null pointer passed as an argument to a 'nonnull' parameter Product: clang Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Static Analyzer Assignee: kreme...@apple.com Reporter: xiangzha...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Hi Clang developers, https://github.com/isoft-linux/partclone/blob/master/src/partclone.c#L506 assert(optarg != NULL); opt->offset = (off_t)atol(optarg); False positve ---> Null pointer passed as an argument to a 'nonnull' parameter Regards, Leslie Zhai -- 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 31604] New: clang crashes on valid code at -Os and above on x86_64-linux-gnu: Assertion `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong topological sorting"' f
https://llvm.org/bugs/show_bug.cgi?id=31604 Bug ID: 31604 Summary: clang crashes on valid code at -Os and above on x86_64-linux-gnu: Assertion `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong topological sorting"' failed Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Classification: Unclassified $ clang -v clang version 4.0.0 (trunk 291427) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/clang-trunk/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang -O1 -c small.c $ $ clang -Os -c small.c clang-4.0: /tmp/llvm-builder/llvm-source-trunk/lib/CodeGen/ScheduleDAG.cpp:519: void llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong topological sorting"' failed. #0 0x01f9bee5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-4.0+0x1f9bee5) #1 0x01f9a00e llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-4.0+0x1f9a00e) #2 0x01f9a170 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-4.0+0x1f9a170) #3 0x7ff3ac57c330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7ff3ab368c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7ff3ab36c028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7ff3ab361bf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #7 0x7ff3ab361ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x019c4737 llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting() (/usr/local/clang-trunk/bin/clang-4.0+0x19c4737) #9 0x0274d817 (anonymous namespace)::ScheduleDAGRRList::Schedule() (/usr/local/clang-trunk/bin/clang-4.0+0x274d817) #10 0x026d8d0e llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr/local/clang-trunk/bin/clang-4.0+0x26d8d0e) #11 0x026e0df3 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/local/clang-trunk/bin/clang-4.0+0x26e0df3) #12 0x026e3087 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone .part.956] (/usr/local/clang-trunk/bin/clang-4.0+0x26e3087) #13 0x014fc394 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/usr/local/clang-trunk/bin/clang-4.0+0x14fc394) #14 0x018e0bb7 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x18e0bb7) #15 0x01bae1f3 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang-4.0+0x1bae1f3) #16 0x01bae29c llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x1bae29c) #17 0x01baeada llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x1baeada) #18 0x02124504 (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr >) (/usr/local/clang-trunk/bin/clang-4.0+0x2124504) #19 0x02125726 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm:
