[llvm-bugs] [Bug 38906] New: 'Assertion `AnalysisPass && "Expected analysis pass to exist."' failed.' with -gvn-hoist -early-cse-memssa even on empty file
https://bugs.llvm.org/show_bug.cgi?id=38906 Bug ID: 38906 Summary: 'Assertion `AnalysisPass && "Expected analysis pass to exist."' failed.' with -gvn-hoist -early-cse-memssa even on empty file Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org opt -S -o - /dev/null -gvn-hoist -early-cse-memssa crashes with opt: ../lib/IR/LegacyPassManager.cpp:617: void llvm::PMTopLevelManager::setLastUser(ArrayRef, llvm::Pass *): Assertion `AnalysisPass && "Expected analysis pass to exist."' failed. Stack dump: 0. Program arguments: build-all/bin/opt -S -o - /dev/null -gvn-hoist -early-cse-memssa #0 0x020ec834 PrintStackTraceSignalHandler(void*) (build-all/bin/opt+0x20ec834) #1 0x020ea990 llvm::sys::RunSignalHandlers() (build-all/bin/opt+0x20ea990) #2 0x020ecb98 SignalHandler(int) (build-all/bin/opt+0x20ecb98) #3 0x7f7c26a2b330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7f7c2561ac37 gsignal /build/eglibc-ripdx6/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f7c2561e028 abort /build/eglibc-ripdx6/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f7c25613bf6 __assert_fail_base /build/eglibc-ripdx6/eglibc-2.19/assert/assert.c:92:0 #7 0x7f7c25613ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x01b24292 llvm::PMTopLevelManager::setLastUser(llvm::ArrayRef, llvm::Pass*) (build-all/bin/opt+0x1b24292) #9 0x01b28210 llvm::PMDataManager::add(llvm::Pass*, bool) (build-all/bin/opt+0x1b28210) #10 0x01b25593 llvm::PMTopLevelManager::schedulePass(llvm::Pass*) (build-all/bin/opt+0x1b25593) #11 0x0075cde6 main (build-all/bin/opt+0x75cde6) #12 0x7f7c25605f45 __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:321:0 #13 0x00745e2d _start (build-all/bin/opt+0x745e2d) Abort -- 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 38907] New: "Bad machine code: Multiple connected components in live interval" after simple-register-coalescing
https://bugs.llvm.org/show_bug.cgi?id=38907 Bug ID: 38907 Summary: "Bad machine code: Multiple connected components in live interval" after simple-register-coalescing Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 20868 --> https://bugs.llvm.org/attachment.cgi?id=20868&action=edit reproducer If I remove the preservation of LiveIntervals in the coalescer (i.e. I comment out AU.addPreserved();) then the verifier complains about *** Bad machine code: Multiple connected components in live interval *** when I do llc -O1 -o - foo_amd.mir -verify-machineinstrs -start-before simple-register-coalescing -march=amdgcn In a way it's a silly case of "if I do a stupid thing in the coalescer, then something goes wrong" but really, should things fail if I remove an addPreserved call? So, if I remove AU.addPreserved(); from RegisterCoalescer::getAnalysisUsage then the following testcase # RUN: llc -O1 -o - %s -verify-machineinstrs -start-before simple-register-coalescing -march=amdgcn --- name:f3 tracksRegLiveness: true frameInfo: body: | bb.0: successors: %bb.1(0x8000) %5:sreg_32 = IMPLICIT_DEF S_BRANCH %bb.1 bb.1: successors: %bb.3(0x4000), %bb.2(0x4000) %6:sreg_32 = COPY killed %5 S_CBRANCH_SCC0 %bb.3, implicit undef $scc bb.2: successors: %bb.3(0x8000) %6:sreg_32 = IMPLICIT_DEF S_BRANCH %bb.3 bb.3: successors: %bb.1(0x8000) %5 = COPY killed %6 S_BRANCH %bb.1 ... gives me # After Rename Disconnected Subregister Components ** INTERVALS ** %1 [16r,16d:0)[112r,112d:1) 0@16r 1@112r weight:0.00e+00 RegMasks: ** MACHINEINSTRS ** # Machine code for function f3: NoPHIs, TracksLiveness 0B bb.0: successors: %bb.1(0x8000); %bb.1(100.00%) 16B dead %1:sreg_32 = IMPLICIT_DEF 32B S_BRANCH %bb.1 48B bb.1: ; predecessors: %bb.0, %bb.3 successors: %bb.3(0x4000), %bb.2(0x4000); %bb.3(50.00%), %bb.2(50.00%) 80B S_CBRANCH_SCC0 %bb.3, implicit undef $scc 96B bb.2: ; predecessors: %bb.1 successors: %bb.3(0x8000); %bb.3(100.00%) 112B dead %1:sreg_32 = IMPLICIT_DEF 128B S_BRANCH %bb.3 144Bbb.3: ; predecessors: %bb.1, %bb.2 successors: %bb.1(0x8000); %bb.1(100.00%) 176B S_BRANCH %bb.1 # End machine code for function f3. *** Bad machine code: Multiple connected components in live interval *** - function:f3 - interval:%1 [16r,16d:0)[112r,112d:1) 0@16r 1@112r weight:0.00e+00 0: valnos 0 1: valnos 1 LLVM ERROR: Found 1 machine code errors. If I don't remove the addPreserved, then the %1 definitions are not marked "dead" and the intervals become %1 [16r,48B:3)[48B,96B:1)[112r,144B:0)[144B,192B:2) 0@112r 1@48B-phi 2@144B-phi 3@16r weight:0.00e+00 instead of %1 [16r,16d:0)[112r,112d:1) 0@16r 1@112r weight:0.00e+00 and the verifier doesn't complain. (In my out-of-tree target we run a pass after the coalescer that does not preserve LiveIntervals, so it needs to be rerun and then the "dead" markings are introduced, which later makes the verifier complain. So we actually run into real problems like this without having to hack the coalescer.) -- 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 38908] New: Thread Annotation doesn't recognize a mutex is hold
https://bugs.llvm.org/show_bug.cgi?id=38908
Bug ID: 38908
Summary: Thread Annotation doesn't recognize a mutex is hold
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: mend...@gmail.com
CC: llvm-bugs@lists.llvm.org
Compiling the following snippet the compiler is not able to recognize that the
privateAddComponent caller is holding the mutex:
#include
#include
#include
#include
#define THREAD_ANNOTATION_ATTRIBUTE(x) __attribute__((x))
#define MUTEX_CAPABILITY THREAD_ANNOTATION_ATTRIBUTE(capability("mutex"))
#define ACQUIRE_CAPABILITY(m)
THREAD_ANNOTATION_ATTRIBUTE(acquire_capability(m))
#define SCOPED_LOCKABLE THREAD_ANNOTATION_ATTRIBUTE(scoped_lockable)
#define RELEASE_CAPABILITYTHREAD_ANNOTATION_ATTRIBUTE(release_capability())
#define GUARDED_BY(x) THREAD_ANNOTATION_ATTRIBUTE(guarded_by(x))
#define EXCLUDES(...)
THREAD_ANNOTATION_ATTRIBUTE(locks_excluded(__VA_ARGS__))
namespace blp {
using mutex MUTEX_CAPABILITY = std::mutex;
template
class SCOPED_LOCKABLE unique_lock
{
public:
explicit unique_lock(T& aMutex) ACQUIRE_CAPABILITY(aMutex)
: theLock(aMutex) {
}
~unique_lock() RELEASE_CAPABILITY = default;
void foo(T& aMutex) EXCLUDES(aMutex) { }
private:
std::unique_lock theLock;
};
}
class TSCollection {
public:
void addComponent(int aQuery, int aReply) EXCLUDES(theMutex) {
blp::unique_lock myGuard(theMutex);
privateAddComponent(aQuery, aReply);
}
void addDefaultComponent(int aQuery) EXCLUDES(theMutex) {
blp::unique_lock myGuard(theMutex);
privateAddComponent(aQuery, 42);
}
std::optional component(int aQuery) const EXCLUDES(theMutex) {
blp::unique_lock myGuard(theMutex);
auto it = theCollection.find(aQuery);
return it !=
theCollection.end() ? std::optional(it->second) : std::nullopt;
}
private:
void privateAddComponent(int aQuery, int aReply) {
theCollection[aQuery] = aReply;
}
mutable blp::mutex theMutex;
std::map theCollection GUARDED_BY(theMutex);
};
int main() {
std::cout << "hello" << std::endl;
}
--
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 38909] New: [clang-format] Support generators in C++
https://bugs.llvm.org/show_bug.cgi?id=38909
Bug ID: 38909
Summary: [clang-format] Support generators in C++
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: dennis.fels...@sap.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
We use lambdas to write code like:
int main()
{
int newValue;
If(match, [&]() {
newValue = false;
}).ElseIf(match2, [&]() {
newValue = true;
}).Else([&]() {
newValue = false;
});
}
Unfortunately clang-format since version 5 started indenting the ElseIf:
$ clang-format -style webkit x.cpp
int main()
{
int newValue;
If(match, [&]() {
newValue = false;
})
.ElseIf(match2, [&]() {
newValue = true;
})
.Else([&]() {
newValue = false;
});
}
I couldn't find an option to turn this behaviour off.
--
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 38910] New: Replacements::add does not de-duplicate, as documented
https://bugs.llvm.org/show_bug.cgi?id=38910
Bug ID: 38910
Summary: Replacements::add does not de-duplicate, as documented
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: steve...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The documentation contains:
/// 4. Replacement A(0, 3, "ab") and B(0, 3, "ab") are order-independent
since
///applying the same replacement twice is equivalent to applying it once.
However, instead, the method duplicates the insertion.
This incorrect behavior is also tested:
TEST_F(ApplyAtomicChangesTest, AppliesDuplicateInsertions) {
setInput("int a;");
Changes.push_back(replacementToAtomicChange("key1", 5, 0, "b"));
Changes.push_back(replacementToAtomicChange("key2", 5, 0, "b"));
EXPECT_EQ("int abb;", rewrite());
}
When I run the modernize-use-override clang-tidy check with -export-fixes and
later apply them with clang-apply-replacements, this means that I get multiple
`override` keywords in the rewritten code.
--
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 38911] New: misoptimizing EMPTY_STACK was placed into .rodata
https://bugs.llvm.org/show_bug.cgi?id=38911
Bug ID: 38911
Summary: misoptimizing EMPTY_STACK was placed into .rodata
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: zhaixi...@loongson.cn
CC: llvm-bugs@lists.llvm.org
Hi LLVM developers,
The reduced testcase provided by Dimitry Andric is:
$ cat JDK-8205969.cpp
#include
class NativeCallStack {
public:
static const NativeCallStack EMPTY_STACK;
private:
enum { DEPTH = 4 };
void* stack[DEPTH];
public:
NativeCallStack() {
for (int i = 0; i < DEPTH; ++i) {
stack[i] = nullptr;
}
}
};
const NativeCallStack NativeCallStack::EMPTY_STACK;
int main(void)
{
// The following should segfault, if EMPTY_STACK was placed into .rodata.
::new ((void*)&NativeCallStack::EMPTY_STACK) NativeCallStack();
return 0;
}
- 8< 8< 8< 8< 8< 8< ---
It is able to reproduce after compiled with clang-8 optimized for X86:
$ clang++ -O3 -S -c JDK-8205969.cpp -o JDK-8205969-opt-8.0.s
$ clang++ -O3 -c JDK-8205969.cpp -o JDK-8205969-opt-8.0.o
$ clang++ -o JDK-8205969-opt-8.0.out JDK-8205969-opt-8.0.o
$ ./JDK-8205969-opt-8.0.out
Segmentation fault
$ cat JDK-8205969-opt-8.0.s
.text
.file "JDK-8205969.cpp"
.globl main# -- Begin function main
.p2align4, 0x90
.type main,@function
main: # @main
.cfi_startproc
# %bb.0:
xorps %xmm0, %xmm0
movups %xmm0, _ZN15NativeCallStack11EMPTY_STACKE+16(%rip)
movups %xmm0, _ZN15NativeCallStack11EMPTY_STACKE(%rip)
xorl%eax, %eax
retq
.Lfunc_end0:
.size main, .Lfunc_end0-main
.cfi_endproc
# -- End function
.type _ZN15NativeCallStack11EMPTY_STACKE,@object #
@_ZN15NativeCallStack11EMPTY_STACKE
.section.rodata,"a",@progbits
^--- READ-ONLY segment
.globl _ZN15NativeCallStack11EMPTY_STACKE
.p2align3
_ZN15NativeCallStack11EMPTY_STACKE:
.zero 32
.size _ZN15NativeCallStack11EMPTY_STACKE, 32
.ident "LLVM China clang version 8.0.0
(g...@github.com:llvm-mirror/clang.git 81ef98628ebf5186d746c0986dcbf5073e842043)
(g...@github.com:llvm-mirror/llvm.git e1aac9723d55497e74d83d216329f08d9842e494)
(based on LLVM 8.0.0svn)"
.section".note.GNU-stack","",@progbits
.addrsig
- 8< 8< 8< 8< 8< 8< ---
But it is *not* able to reproduce with clang-8 not optimized for X86:
$ clang++ -O0 -S -c JDK-8205969.cpp -o JDK-8205969-unopt-8.0.s
$ clang++ -O0 -c JDK-8205969.cpp -o JDK-8205969-unopt-8.0.o
$ clang++ -o JDK-8205969-unopt-8.0.out JDK-8205969-unopt-8.0.o
$ ./JDK-8205969-unopt-8.0.out
No segfault
$ cat JDK-8205969-unopt-8.0.s
.text
.file "JDK-8205969.cpp"
.section.text.startup,"ax",@progbits
.p2align4, 0x90 # -- Begin function
__cxx_global_var_init
.type __cxx_global_var_init,@function
__cxx_global_var_init: # @__cxx_global_var_init
.cfi_startproc
# %bb.0:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq%rsp, %rbp
.cfi_def_cfa_register %rbp
movabsq $_ZN15NativeCallStack11EMPTY_STACKE, %rdi
callq _ZN15NativeCallStackC2Ev
popq%rbp
.cfi_def_cfa %rsp, 8
retq
.Lfunc_end0:
.size __cxx_global_var_init, .Lfunc_end0-__cxx_global_var_init
.cfi_endproc
# -- End function
.section
.text._ZN15NativeCallStackC2Ev,"axG",@progbits,_ZN15NativeCallStackC2Ev,comdat
.weak _ZN15NativeCallStackC2Ev # -- Begin function
_ZN15NativeCallStackC2Ev
.p2align4, 0x90
.type _ZN15NativeCallStackC2Ev,@function
_ZN15NativeCallStackC2Ev: # @_ZN15NativeCallStackC2Ev
.cfi_startproc
# %bb.0:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq%rsp, %rbp
.cfi_def_cfa_register %rbp
movq%rdi, -8(%rbp)
movq-8(%rbp), %rdi
movl$0, -12(%rbp)
movq%rdi, -24(%rbp) # 8-byte Spill
.LBB1_1:# =>This Inner Loop Header: Depth=1
cmpl$4, -12(%rbp)
jge .LBB1_4
# %bb.2:# in Loop: Header=BB1_1 Depth=1
movslq -12(%rbp), %rax
movq-24(%rbp), %rcx # 8-byte Reload
movq$0, (%rcx,%rax,8)
# %bb.3:# in Loop: Header=
[llvm-bugs] [Bug 38912] New: GVNHoist calls IDFCalculator::calculate() passing an non-empty vector
https://bugs.llvm.org/show_bug.cgi?id=38912 Bug ID: 38912 Summary: GVNHoist calls IDFCalculator::calculate() passing an non-empty vector Product: tools Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: opt Assignee: unassignedb...@nondot.org Reporter: alexandros.lamprin...@arm.com CC: llvm-bugs@lists.llvm.org The same underlying bug was initially addressed by rL340818: [GVNHoist] Prune out useless CHI insertions, where we realized GVNHoist was using excessive memory. It appears that this wasn't the right fix, since the ubsan buildbot kept failing with timeouts. On my machine compiling SemaChecking.cpp with clang++ and both GVNHoist/Ubsan enabled takes approximately half an hour. The real problem is in GVNHoist::computeInsertionPoints(), where we iterate over the Value Numbers and calculate the Iterated Dominance Frontiers without clearing the IDFBlocks vector first. -- 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 38911] misoptimizing EMPTY_STACK was placed into .rodata
https://bugs.llvm.org/show_bug.cgi?id=38911 Anton Korobeynikov changed: What|Removed |Added CC||an...@korobeynikov.info Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Anton Korobeynikov --- The transformation is correct and the code is clearly UB. 7.1.5.1 [dcl.type.cv] explicitly says: 4 Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior. -- 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 38913] New: Early-instantiated attributes are dropped from member classes
https://bugs.llvm.org/show_bug.cgi?id=38913 Bug ID: 38913 Summary: Early-instantiated attributes are dropped from member classes Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: ldio...@apple.com CC: llvm-bugs@lists.llvm.org Created attachment 20869 --> https://bugs.llvm.org/attachment.cgi?id=20869&action=edit Test case in Clang style This is lifted from this message in cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2018-September/059291.html Attributes on - member classes of class templates, - member class templates of class templates, - partial specializations of member class templates of class templates, and - explicit specializations of member class templates of class templates are not instantiated properly. As a result, attributes are dropped from those declarations. This can be seen with the attached test case, which fails. -- 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 38914] New: unexpected crash - does not happen on g++
https://bugs.llvm.org/show_bug.cgi?id=38914
Bug ID: 38914
Summary: unexpected crash - does not happen on g++
Product: libc++
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: duduar...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
This program crashes before starting.
on g++ - it runs as expected.
it seems like a bug:
#include
struct InnerCls
{
InnerCls() { std::cout<<__FUNCTION__<
class Cls
{
public:
Cls() { innerCls.foo(); }
static InnerCls innerCls;
};
template
InnerCls Cls::innerCls ;
int main()
{
Cls x;
}
--
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 38915] New: [InstCombine] Infinite loop by operating on same set of instructions in worklist
https://bugs.llvm.org/show_bug.cgi?id=38915
Bug ID: 38915
Summary: [InstCombine] Infinite loop by operating on same set
of instructions in worklist
Product: tools
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: a...@azul.com
CC: llvm-bugs@lists.llvm.org
This test goes into infinite loop when run with InstCombine on llvm ToT:
opt -instcombine test.ll <-- hangs with rerunning IC over the same set of
instructions in the worklist.
test.ll:
define void @baz(i32 %arg) {
bb:
switch i32 undef, label %bb4 [
i32 0, label %bb2
i32 1, label %bb3
i32 2, label %bb1
]
bb1: ; preds = %bb
ret void
bb2: ; preds = %bb
unreachable
bb3: ; preds = %bb
ret void
bb4: ; preds = %bb
%tmp = sub i32 0, %arg
%tmp5 = and i32 %tmp, 3
%tmp6 = sub i32 0, %tmp5
%tmp7 = sub i32 0, %tmp5
%tmp8 = sub i32 -2, %tmp5
%tmp9 = icmp sgt i32 %tmp6, -2147483647
%tmp10 = select i1 %tmp9, i32 %tmp6, i32 -2147483647
%tmp11 = mul i32 %tmp10, -1
%tmp12 = icmp sgt i32 %tmp7, -2147483647
%tmp13 = select i1 %tmp12, i32 %tmp7, i32 -2147483647
%tmp14 = mul i32 %tmp13, -1
%tmp15 = icmp sgt i32 %tmp11, %tmp14
%tmp16 = select i1 %tmp15, i32 %tmp11, i32 %tmp14
%tmp17 = sub i32 -1, %tmp16
%tmp18 = icmp sgt i32 %tmp17, %tmp8
%tmp19 = select i1 %tmp18, i32 %tmp17, i32 %tmp8
%tmp20 = sub i32 -1, %tmp19
%tmp21 = icmp sgt i32 %tmp20, 1
%tmp22 = select i1 %tmp21, i32 %tmp20, i32 1
%tmp23 = add i32 %tmp22, -1
%tmp24 = add i32 %tmp5, -1
%tmp25 = icmp sgt i32 %tmp24, %tmp23
br i1 %tmp25, label %bb26, label %bb27
bb26: ; preds = %bb4
unreachable
bb27: ; preds = %bb4
unreachable
}
--
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 38902] incorrect diagnose of user-defined reduction declared in namespace
https://bugs.llvm.org/show_bug.cgi?id=38902 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Alexey Bataev --- Fixed in r342062 -- 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 38691] addus/subus-as-native IR can be defeated by optimizer
https://bugs.llvm.org/show_bug.cgi?id=38691 Steven Johnson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Steven Johnson --- After further investigation, it looks like the pcmp issue I'm seeing isn't really injected by these fixes at all; the apparent injection point of r341708 was really just inducing some code motion that happened to change our particular test, but the real underlying issue appears to have actually been injected by r339875. At this point I think we can declare this bug fixed; I'll open a new one for the other issue. -- 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 38916] New: vector-compare code does unnecessary widening/narrowing
https://bugs.llvm.org/show_bug.cgi?id=38916
Bug ID: 38916
Summary: vector-compare code does unnecessary
widening/narrowing
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: s...@google.com
CC: llvm-bugs@lists.llvm.org
The change in https://reviews.llvm.org/rL339875 seems to have regressed the
quality of some vector-compare code generation (for x86 at least) in Halide.
Halide is attempting to generate code that is comparing two <8 x i8> vectors;
```
vec<8 x i8> ones = {1,1,1,1,1,1,1,1};
vec<8 x i8> twos = {2,2,2,2,2,2,2,2};
vec<8 x i8> a = load_vec_a();
vec<8 x i8> b = load_vec_b();
// result should contain 1 for each byte that matches, 2 for each that does
not
vec<8 x i8> result = (a == b) ? ones : twos;
```
The unoptimized LLVM IR we generate for the above is:
```
%9 = bitcast i8* %load_vec_a to <8 x i8>*
%10 = load <8 x i8>, <8 x i8>* %9
%11 = bitcast i8* %load_vec_b to <8 x i8>*
%12 = load <8 x i8>, <8 x i8>* %11
%13 = shufflevector <8 x i8> %10, <8 x i8> undef, <16 x i32>
%14 = shufflevector <8 x i8> %12, <8 x i8> undef, <16 x i32>
%15 = icmp eq <16 x i8> %13, %14
%16 = shufflevector <16 x i1> %15, <16 x i1> undef, <8 x i32>
%17 = shufflevector <8 x i1> %16, <8 x i1> undef, <16 x i32>
%18 = select <16 x i1> %17, <16 x i8> , <16 x i8>
%19 = shufflevector <16 x i8> %18, <16 x i8> undef, <8 x i32>
%20 = bitcast i8* %result to <8 x i8>*
store <8 x i8> %19, <8 x i8>* %20
```
The expectation here is that for x86 (w/SSE4), we'll end up with x86 code
something like this:
```
vmovq load_vec_a, %xmm0
vmovq load_vec_b, %xmm1
vpcmpeqb %xmm1, %xmm0, %xmm0
vpaddb.LCPI0_0(%rip), %xmm0, %xmm0 ## LCPI0_0 =
<2,2,2,2,2,2,2,2,u,u,u,u,u,u,u,u>
vmovq %xmm0, result
```
But after https://reviews.llvm.org/rL339875, however, the IR above emits
something more like:
```
vpmovzxbw load_vec_a, %xmm0
vpmovzxbw load_vec_b, %xmm1
vpcmpeqw%xmm1, %xmm0, %xmm0
vpacksswb %xmm0, %xmm0, %xmm0
vpsllw $7, %xmm0, %xmm0
vpand .LCPI0_0(%rip), %xmm0, %xmm0 ## LCPI0_0 =
<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>
vpxor %xmm1, %xmm1, %xmm1
vpcmpgtb%xmm0, %xmm1, %xmm0
vpaddb .LCPI0_1(%rip), %xmm0, %xmm0 ## LCPI0_1 =
<2,2,2,2,2,2,2,2,u,u,u,u,u,u,u,u>
vmovq %xmm0, result
```
Besides being twice as long, it's just odd -- why are we expanding the results
to 16 bit when the source, intermediate, and result are all 8 bit? (Note that
current top-of-tree produces slightly different output from this second
example, but the fundamental pathology of unnecessary-widening-and-narrowing is
still in place.)
--
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 38917] New: Failure to hoist repeated vextractf128 from switch cases
https://bugs.llvm.org/show_bug.cgi?id=38917
Bug ID: 38917
Summary: Failure to hoist repeated vextractf128 from switch
cases
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org
Simplified (masked store style) example:
https://gcc.godbolt.org/z/g7URz3
void store07(__m256i a, __m256i v, int *f) {
switch(_mm256_movemask_ps(a)) {
case 0xff:
f[7] = _mm256_extract_epi32(v, 7);
case 0x7f:
f[6] = _mm256_extract_epi32(v, 6);
case 0x3f:
f[5] = _mm256_extract_epi32(v, 5);
case 0x1f:
f[4] = _mm256_extract_epi32(v, 4);
case 0x0f:
f[3] = _mm256_extract_epi32(v, 3);
case 0x07:
f[2] = _mm256_extract_epi32(v, 2);
case 0x03:
f[1] = _mm256_extract_epi32(v, 1);
case 0x01:
f[0] = _mm256_extract_epi32(v, 0);
break;
}
}
_Z7store07Dv4_xS_Pi: # @_Z7store07Dv4_xS_Pi
vmovmskps %ymm0, %eax
cmpl $62, %eax
jg .LBB0_3
decl %eax
cmpl $30, %eax
ja .LBB0_14
jmpq *.LJTI0_0(,%rax,8)
.LBB0_3:
cmpl $63, %eax
je .LBB0_8
cmpl $255, %eax
je .LBB0_6
cmpl $127, %eax
je .LBB0_7
.LBB0_14:
retq
.LBB0_6:
vextractf128 $1, %ymm1, %xmm0
vextractps $3, %xmm0, 28(%rdi)
.LBB0_7:
vextractf128 $1, %ymm1, %xmm0
vextractps $2, %xmm0, 24(%rdi)
.LBB0_8:
vextractf128 $1, %ymm1, %xmm0
vextractps $1, %xmm0, 20(%rdi)
.LBB0_9:
vextractf128 $1, %ymm1, %xmm0
vmovss %xmm0, 16(%rdi)
.LBB0_10:
vextractps $3, %xmm1, 12(%rdi)
.LBB0_11:
vextractps $2, %xmm1, 8(%rdi)
.LBB0_12:
vextractps $1, %xmm1, 4(%rdi)
.LBB0_13:
vmovss %xmm1, (%rdi)
retq
Shouldn't CSE be able to hoist the repeated vextractf128 instructions out from
the switch cases?
--
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 38918] New: lld crashes (nullptr derference) when linking kernel with --icf=all
https://bugs.llvm.org/show_bug.cgi?id=38918 Bug ID: 38918 Summary: lld crashes (nullptr derference) when linking kernel with --icf=all Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: pho...@chromium.org CC: llvm-bugs@lists.llvm.org It's a null pointer crash in lld::elf::InputSection::copyRelocations: => P->r_addend = Sym.getVA(Addend) - Section->getOutputSection()->Addr; Looks like getOutputSection returned nullptr. -- 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 38919] New: "unsupported relocation target while parsing debug info" error when using ASan
https://bugs.llvm.org/show_bug.cgi?id=38919 Bug ID: 38919 Summary: "unsupported relocation target while parsing debug info" error when using ASan Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: pho...@chromium.org CC: llvm-bugs@lists.llvm.org When linking code with ASan instrumentation, lld generates many errors like this one: ld.lld: error: unsupported relocation target while parsing debug info -- 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 38920] New: clang ODR checker errors on (real) ODR violation in libstdc++ headers
https://bugs.llvm.org/show_bug.cgi?id=38920 Bug ID: 38920 Summary: clang ODR checker errors on (real) ODR violation in libstdc++ headers Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Modules Assignee: rtr...@google.com Reporter: richard-l...@metafoo.co.uk CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Our libstdc++ / modules buildbot is currently failing due to the modules ODR checker finding a ODR violation in a libstdc++ header: http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules-2/builds/26164/steps/compile.llvm.stage2/logs/stdio There is a real ODR violation in this code. std::_Sp_counted_base::_M_release calls __gnu_cxx::__exchange_and_add_dispatch, which is declared static. While this is a bug in libstdc++, we do aim to support libstdc++ regardless of its bugs, and so we should work around this. Assuming the above ODR violation is indeed the reason that the check is failing, we could special-case this particular function name when computing ODR hashes, and ensure that it always hashes to the same value even when resolving to two different functions in different translation units. -- 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 38860] Mapping a struct onto an aligned byte array produces incorrect output when compiled with -O2
https://bugs.llvm.org/show_bug.cgi?id=38860 Adrian Wong changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Adrian Wong --- (In reply to David Blaikie from comment #3) > *nod* A quote we sometimes throw around is: "The compiler may not break your > bad code today, but it is patient and will try harder tomorrow." Thanks for taking the time to provide an explanation, David! The quote gave me a chuckle. I'll mark this as "RESOLVED - INVALID". Cheers, Adrian -- 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 38921] New: .weak directive ignored if symbol is not already defined
https://bugs.llvm.org/show_bug.cgi?id=38921 Bug ID: 38921 Summary: .weak directive ignored if symbol is not already defined Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: j...@jms.id.au CC: llvm-bugs@lists.llvm.org When building the powerpc linux kenrel with clang, a symbol is not correctly marked weak in the ELF which breaks the build when linking the kernel image: $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$ 0058 g .text _zimage_start ld: arch/powerpc/boot/wrapper.a(crt0.o): in function '_zimage_start': (.text+0x58): multiple definition of '_zimage_start'; arch/powerpc/boot/pseries-head.o:(.text+0x0): first defined here Clang requires the .weak directive to appear after the symbol is declared. The binutils manual says: This directive sets the weak attribute on the comma separated list of symbol names. If the symbols do not already exist, they will be created. So it appears this is different with clang. The only reference I could see for this was an OpenBSD mailing list post[1]. Changing it to be after the declaration fixes building with Clang, and still works with GCC. $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$ 0058 w .text _zimage_start [1] https://groups.google.com/forum/#!topic/fa.openbsd.tech/PAgKKen2YCY Is this intentional? Can we change the behaviour to match the binutils linker? -- 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 38620] ARM: Incorrect COFF relocation type for thumb bl instruction
https://bugs.llvm.org/show_bug.cgi?id=38620 Saleem Abdulrasool changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Saleem Abdulrasool --- SVN r342109 -- 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 38922] New: XRay attributes don't get emitted when -fno-xray-instrument is provided
https://bugs.llvm.org/show_bug.cgi?id=38922 Bug ID: 38922 Summary: XRay attributes don't get emitted when -fno-xray-instrument is provided Product: XRay Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Clang Assignee: dber...@google.com Reporter: dber...@google.com CC: llvm-bugs@lists.llvm.org This causes issues when doing thinlto builds, where one module is built with -fno-xray-instrument while another is built with -fxray-instrument, then at link-time the re-lowering of functions that should have been marked "never instrument" may suddenly get instrumented. Instead of deciding at the front-end whether to emit the attribute, we should instead handle the attribute in LLVM IR properly in the back-end if we're emitting XRay instrumented 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
