[llvm-bugs] [Bug 42646] New: Completion offers namespace items after Class::
https://bugs.llvm.org/show_bug.cgi?id=42646
Bug ID: 42646
Summary: Completion offers namespace items after Class::
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: nikolai.kos...@qt.io
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
This is a regression from clang-7 to clang-8/trunk.
### Test with clang 8/trunk
~ % F=/tmp/reproducer.cpp
~ % cat -n $F
1 namespace std {};
2 class Class { static void foo(); };
3 Class::
4
~ % CINDEXTEST_EDITING=1
/d2/llvm/trunk/vanilla/builds/DebugShared/bin/c-index-test
-code-completion-at=$F:3:8 $F | grep std
Namespace:{TypedText std}{Text ::} (75)
### Test with clang-7
~ % CINDEXTEST_EDITING=1 /usr/bin/c-index-test-7 -code-completion-at=$F:3:8 $F
| grep std
zsh: done CINDEXTEST_EDITING=1 /usr/bin/c-index-test-7
-code-completion-at=$F:3:8 $F |
zsh: exit 1 grep --color=auto std
Works as expected without "CINDEXTEST_EDITING=1". However, for an IDE the
effect of CINDEXTEST_EDITING=1 is crucial (preamble generation + caching
completions).
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41009] Can't initialise literal sampler when building with -cl-std=c++
https://bugs.llvm.org/show_bug.cgi?id=41009 Neil Hickey changed: What|Removed |Added Status|CONFIRMED |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42647] New: A denial of service vulnerability in function findBaseDefiningValue(llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp) via an bitcode file which has been overrided th
https://bugs.llvm.org/show_bug.cgi?id=42647
Bug ID: 42647
Summary: A denial of service vulnerability in function
findBaseDefiningValue(llvm/lib/Transforms/Scalar/Rewri
teStatepointsForGC.cpp) via an bitcode file which has
been overrided the module target triple.
Product: tools
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: zhangxia...@gmail.com
CC: llvm-bugs@lists.llvm.org
n llvm opt tools 8.0.0 and older version, an issue was discovered.The
findBaseDefiningValue function in
llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp allows attackers to
cause a denial of service(assertion failure and opt tool crashed) via an
bitcode file which has been overrided the module target triple.
The bitcode file which can cause denial of service has been in the attachment.
Reproduce steps:
# opt -mem2reg -rewrite-statepoints-for-gc -always-inline -o b0o_new.bc
b0_new.bc
Please check the rewrite-statepoints-for-gc feature in the opt tool.
If you have confirmed the vulnerability, should i submit this issue for CVE?
The details crashed logs as bellow:
opt:
/home/wenzhuo/llvm-project/llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:525:
{anonymous}::BaseDefiningValueResult findBaseDefiningValue(llvm::Value*):
Assertion `cast(Def->getType())->getAddressSpace() ==
cast(CI->getType())->getAddressSpace() && "unsupported
addrspacecast"' failed.
Stack dump:
0. Program arguments: /usr/local/bin/opt -mem2reg
-rewrite-statepoints-for-gc -always-inline -o b0o_new.bc b02.bc
1. Running pass 'Make relocations explicit at statepoints' on module
'b02.bc'.
#0 0x043152b1 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/wenzhuo/llvm-project/llvm/lib/Support/Unix/Signals.inc:494:0
#1 0x04315344 PrintStackTraceSignalHandler(void*)
/home/wenzhuo/llvm-project/llvm/lib/Support/Unix/Signals.inc:558:0
#2 0x04313352 llvm::sys::RunSignalHandlers()
/home/wenzhuo/llvm-project/llvm/lib/Support/Signals.cpp:68:0
#3 0x04314d03 SignalHandler(int)
/home/wenzhuo/llvm-project/llvm/lib/Support/Unix/Signals.inc:357:0
#4 0x7f553aaa1390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#5 0x7f55397b0428 raise
/build/glibc-LK5gWL/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#6 0x7f55397b202a abort /build/glibc-LK5gWL/glibc-2.23/stdlib/abort.c:91:0
#7 0x7f55397a8bd7 __assert_fail_base
/build/glibc-LK5gWL/glibc-2.23/assert/assert.c:92:0
#8 0x7f55397a8c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#9 0x04224460 findBaseDefiningValue(llvm::Value*)
/home/wenzhuo/llvm-project/llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:529:0
#10 0x042247cb findBaseDefiningValueCached(llvm::Value*,
llvm::MapVector,
llvm::detail::DenseMapPair >,
std::vector,
std::allocator > > >&)
/home/wenzhuo/llvm-project/llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:614:0
#11 0x0422491c findBaseOrBDV(llvm::Value*,
llvm::MapVector,
llvm::detail::DenseMapPair >,
std::vector,
std::allocator > > >&)
/home/wenzhuo/llvm-project/llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:625:0
#12 0x04225372 findBasePointer(llvm::Value*,
llvm::MapVector,
llvm::detail::DenseMapPair >,
std::vector,
std::allocator > >
>&)::'lambda0'(llvm::Value*)::operator()(llvm::Value*) const
/home/wenzhuo/llvm-project/llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:815:0
#13 0x042260d6 findBasePointer(llvm::Value*,
llvm::MapVector,
llvm::detail::DenseMapPair >,
std::vector,
std::allocator > > >&)
/home/wenzhuo/llvm-project/llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:826:0
#14 0x04227d04 findBasePointers(llvm::SetVector >,
llvm::DenseSet > > const&,
llvm::MapVector,
llvm::detail::DenseMapPair >,
std::vector,
std::allocator > > >&,
llvm::DominatorTree*, llvm::MapVector,
llvm::detail::DenseMapPair >,
std::vector,
std::allocator > > >&)
/home/wenzhuo/llvm-project/llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:1163:0
#15 0x04227e57 findBasePointers(llvm::DominatorTree&,
llvm::MapVector,
llvm::detail::DenseMapPair >,
std::vector,
std::allocator > > >&, llvm::CallBase*,
(anonymous namespace)::PartiallyConstructedSafepointRecord&)
/home/wenzhuo/llvm-project/llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:1181:0
#16 0x0422cdfb insertParsePoints(llvm::Function&, llvm::DominatorTree&,
llvm::TargetTransformInfo&, llvm::SmallVectorImpl&)
/home/wenzhuo/llvm-project/llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:2230:0
#17 0x0422e984
llvm::RewriteStatepointsForGC::runOnFunction(llvm::Function&,
llvm::DominatorTree&, llvm::TargetTransformInfo&, llvm::TargetLibraryInfo
const&)
/home/wenzhuo/llvm-project/llv
[llvm-bugs] [Bug 42649] New: [REG 7 -> 8] Completion does not offer INT_MAX from limits.h
https://bugs.llvm.org/show_bug.cgi?id=42649
Bug ID: 42649
Summary: [REG 7 -> 8] Completion does not offer INT_MAX from
limits.h
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: nikolai.kos...@qt.io
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
~ % echo $T
/tmp/reproducer-macros.cpp
~ % cat -n $T
1 #include
2
3 int main() {}
### Test with clang-8 / trunk
~ % CINDEXTEST_EDITING=1 /usr/bin/c-index-test-8 -code-completion-at=$T:2:1 $T
| grep " INT"
zsh: done CINDEXTEST_EDITING=1 /usr/bin/c-index-test-8
-code-completion-at=$T:2:1 $T |
zsh: exit 1 grep --color=auto " INT"
### Test with clang-7
~ % CINDEXTEST_EDITING=1 /usr/bin/c-index-test-7 -code-completion-at=$T:2:1 $T
| grep " INT"
macro definition:{TypedText INT_MAX} (70)
macro definition:{TypedText INT_MIN} (70)
macro definition:{TypedText INT_WIDTH} (70)
Works as expected without "CINDEXTEST_EDITING=1". However, for an IDE the
effect of CINDEXTEST_EDITING=1 is crucial (preamble generation + caching
completions).
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42589] Crash when building the Linux kernel for MIPS
https://bugs.llvm.org/show_bug.cgi?id=42589 Simon Atanasyan changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Simon Atanasyan --- Fixed at r366299. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39975] [DAGCombine] Missed truncate(extract()) -> extract(bitcast()) opportunities
https://bugs.llvm.org/show_bug.cgi?id=39975 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Sanjay Patel --- I didn't realize it, but we solved the original example too. :) Resolving as 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42650] New: -finclude-default-header broken in r366307
https://bugs.llvm.org/show_bug.cgi?id=42650 Bug ID: 42650 Summary: -finclude-default-header broken in r366307 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: OpenCL Assignee: unassignedclangb...@nondot.org Reporter: kevin.pe...@arm.com CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org Trying to compile any .cl file with the following command: ./build/bin/clang -cc1 -emit-llvm -finclude-default-header file.cl results in the following error with recent revisions: :1:10: fatal error: 'opencl-c.h' file not found #include "opencl-c.h" ^~~~ 1 error generated. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42651] New: noreturn attributes prevent template function pointer arguments from working
https://bugs.llvm.org/show_bug.cgi?id=42651
Bug ID: 42651
Summary: noreturn attributes prevent template function pointer
arguments from working
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: j...@alien8.de
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I'm working on a piece of code that has template functions specialized on
function pointers. These pointers usually point to functions declared noreturn.
This generally works with gcc, but fails with clang due to errors like:
% clang++ -std=c++11 -c syscall.cpp
syscall.cpp:8:7: error: address of overloaded function 'send_msg' cannot be
static_cast to type 'void (*)()'
d ? static_cast(send_msg) : nullptr;
^~~~
syscall.cpp:6:27: note: candidate function template
template void a::send_msg() {
^
syscall.cpp:10:18: error: explicit instantiation of 'send_msg' does not refer
to a function template, variable
template, member function, member class, or static data member
template void a::send_msg();
^
syscall.cpp:6:27: note: candidate template ignored: invalid
explicitly-specified argument for 1st template parameter
template void a::send_msg() {
^
2 errors generated.
creduce reduced the problem to this:
```
class a {
__attribute__((noreturn)) static void b();
__attribute__((noreturn)) static void c();
template static void send_msg();
};
template void a::send_msg() {
int d;
d ? static_cast(send_msg) : nullptr;
}
template void a::send_msg();
```
Removing the noreturn attributes works around the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 21617] wrong optimization of C++11 code on ARM and other targets
https://bugs.llvm.org/show_bug.cgi?id=21617 John Brawn changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||john.br...@arm.com --- Comment #4 from John Brawn --- Looking at the .ll file this was reported on trunk some time prior to 3.5.0, but with 3.5.0 (and later versions) I see no load removal. So it looks like maybe this is a bug that was present on trunk but fixed sometime before 3.5.0 was released. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42652] New: [X86] Poor vectorization array-of-bools to bitmask
https://bugs.llvm.org/show_bug.cgi?id=42652
Bug ID: 42652
Summary: [X86] Poor vectorization array-of-bools to bitmask
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
https://godbolt.org/z/XHMi3b
const unsigned count = 16;
auto BitMask(const bool *src) {
uint64_t mask = 0;
for (unsigned i = 0; i != count; ++i) {
if (src[i])
mask |= (1ull << i);
}
return mask;
}
This should fold to a vpcmpeqb and vpmovmskb (a to iX bitcast),
instead we get a massive vectorization explosion.
Increasing the count variable (or making it non-constant) is similarly awful.
define dso_local i64 @_Z7BitMaskPKb(i8* nocapture readonly) local_unnamed_addr
#0 {
%2 = load i8, i8* %0, align 1, !tbaa !2, !range !6
%3 = zext i8 %2 to i64
%4 = getelementptr inbounds i8, i8* %0, i64 1
%5 = load i8, i8* %4, align 1, !tbaa !2, !range !6
%6 = icmp eq i8 %5, 0
%7 = select i1 %6, i64 0, i64 2
%8 = getelementptr inbounds i8, i8* %0, i64 2
%9 = load i8, i8* %8, align 1, !tbaa !2, !range !6
%10 = icmp eq i8 %9, 0
%11 = select i1 %10, i64 0, i64 4
%12 = getelementptr inbounds i8, i8* %0, i64 3
%13 = load i8, i8* %12, align 1, !tbaa !2, !range !6
%14 = icmp eq i8 %13, 0
%15 = select i1 %14, i64 0, i64 8
%16 = getelementptr inbounds i8, i8* %0, i64 4
%17 = bitcast i8* %16 to <4 x i8>*
%18 = load <4 x i8>, <4 x i8>* %17, align 1, !tbaa !2
%19 = icmp eq <4 x i8> %18, zeroinitializer
%20 = select <4 x i1> %19, <4 x i64> zeroinitializer, <4 x i64>
%21 = getelementptr inbounds i8, i8* %0, i64 8
%22 = bitcast i8* %21 to <8 x i8>*
%23 = load <8 x i8>, <8 x i8>* %22, align 1, !tbaa !2
%24 = icmp eq <8 x i8> %23, zeroinitializer
%25 = select <8 x i1> %24, <8 x i64> zeroinitializer, <8 x i64>
%26 = shufflevector <8 x i64> %25, <8 x i64> undef, <8 x i32>
%27 = or <8 x i64> %25, %26
%28 = shufflevector <8 x i64> %27, <8 x i64> undef, <8 x i32>
%29 = or <8 x i64> %27, %28
%30 = shufflevector <8 x i64> %29, <8 x i64> undef, <8 x i32>
%31 = or <8 x i64> %29, %30
%32 = extractelement <8 x i64> %31, i32 0
%33 = shufflevector <4 x i64> %20, <4 x i64> undef, <4 x i32>
%34 = or <4 x i64> %20, %33
%35 = shufflevector <4 x i64> %34, <4 x i64> undef, <4 x i32>
%36 = or <4 x i64> %34, %35
%37 = extractelement <4 x i64> %36, i32 0
%38 = or i64 %32, %37
%39 = or i64 %38, %15
%40 = or i64 %39, %11
%41 = or i64 %40, %7
%42 = or i64 %41, %3
ret i64 %42
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42653] New: [X86][AVX] Rematerializable lower 'allones' subvector masks
https://bugs.llvm.org/show_bug.cgi?id=42653
Bug ID: 42653
Summary: [X86][AVX] Rematerializable lower 'allones' subvector
masks
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
https://gcc.godbolt.org/z/ESwT78
We should be able to rematerialize masks where the lower subvector half is -1
and the upper 0 by using a smaller destination and the implicit zeroing of the
upper bits:
#include
__m128i low128_128() {
// GOOD
return _mm_setr_epi32(-1,-1,-1,-1);
}
__m256i low256_128() {
// BAD: vpcmpeqd %xmm0, %xmm0, %xmm0
return _mm256_setr_epi32(-1,-1,-1,-1,0,0,0,0);
}
__m512i low512_128() {
// BAD: vpcmpeqd %xmm0, %xmm0, %xmm0
return _mm512_setr_epi32(-1,-1,-1,-1,0,0,0,0,0,0,0,0,0,0,0,0);
}
__m512i low512_256() {
// BAD: vpcmpeqd %ymm0, %ymm0, %ymm0
return _mm512_setr_epi32(-1,-1,-1,-1,-1,-1,-1,-1,0,0,0,0,0,0,0,0);
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 14442 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: Op && "Cannot dereference end iterator!"
Updates: Labels: Deadline-Approaching Comment #2 on issue 14442 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: Op && "Cannot dereference end iterator!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14442#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34820] Make lld's -gdb-index work without -ggnu-pubnames
https://bugs.llvm.org/show_bug.cgi?id=34820 David Blaikie changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #3 from David Blaikie --- I think this should be addressed - but not necessarily by having lld correctly parse all the DWARF & build names from scratch. I'll still argue this bug is a good place for this request - because as it currently stands, lld produces in incorrect index in the absence of gnu-pubnames (so a request that this "work" in a broad sense, as in "is correct" - not necessarily "indexes everything") To summarize a recent discussion: * given an input with a CU without gnu-pubnames, lld currently includes that CU in the gdb-index, but without any names indexed - this leads consumers to not manually index the CU because they believe it's already covered by the index * lld should either index the contents (expensive in both link time and linker implementation complexity - probably undesirable as the first resolution of this bug indicated) or produce an index that does not suggest such CUs are covered by it * additionally, probably a warning that the index is incomplete would be nice (perhaps when -gdb-index is used, a warning if any CU is missing pubnames, and an error if /all/ CUs are missing pubnames) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 15934 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-sccp: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-sccp
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-07-17 Type: Bug New issue 15934 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-sccp: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-sccp https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15934 Detailed report: https://oss-fuzz.com/testcase?key=5690013724966912 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-sccp Fuzz target binary: llvm-opt-fuzzer--x86_64-sccp Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-sccp Sanitizer: memory (MSAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5690013724966912 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 15935 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_unswitch: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unswitch
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-07-17 Type: Bug New issue 15935 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_unswitch: Out-of-memory in llvm_llvm-opt-fuzzer--x86_64-loop_unswitch https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15935 Detailed report: https://oss-fuzz.com/testcase?key=5710447971401728 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_unswitch Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_unswitch Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-opt-fuzzer--x86_64-loop_unswitch Sanitizer: memory (MSAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5710447971401728 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32394] New ARM constant pool optimization passes wrongly aligned data to NEON load optimization
https://bugs.llvm.org/show_bug.cgi?id=32394 John Brawn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||john.br...@arm.com --- Comment #6 from John Brawn --- This was fixed in r343359. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 11753] Incorrect code generated for 64bit types on ARM
https://bugs.llvm.org/show_bug.cgi?id=11753 John Brawn changed: What|Removed |Added Resolution|--- |FIXED CC||john.br...@arm.com Status|NEW |RESOLVED --- Comment #11 from John Brawn --- I can't reproduce this with llvm 3.5.0 (the oldest I have installed), or any newer llvm, so it looks like it was fixed sometime before that. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42654] New: Lambda not convertable to std::function with some templates inbetween
https://bugs.llvm.org/show_bug.cgi?id=42654
Bug ID: 42654
Summary: Lambda not convertable to std::function with some
templates inbetween
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: jva...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Reproduction: https://godbolt.org/z/gQqPaO (Clang + MSVC)
Credits to a colleague of mine.
Workaround: https://godbolt.org/z/zI5umV > replace using statement by:
template using Integer = std::conditional_t, int,
int>;
// clang++ -std=c++17 -Werror -Wall -stdlib=libc++
#include
#include
#include
template
class Environment final
{
public:
template
using Integer = int;
using Function = std::function...)>; // expands to
std::function
using MyTuple = std::tuple...>; // expands to
std::function
auto run(Function func) -> void
{
auto ints = MyTuple{};
std::apply(func, ints);
}
};
int main()
{
auto env = Environment{};
env.run([](int, int){});
}
>> ERRORS:
:27:13: error: no viable conversion from '(lambda at :27:13)'
to 'Environment::Function' (aka 'function')
env.run([](int, int){});
^~~~~~
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/functional:2276:5:
note: candidate constructor not viable: no known conversion from '(lambda at
:27:13)' to 'std::nullptr_t' (aka 'nullptr_t') for 1st argument
function(nullptr_t) _NOEXCEPT {}
^
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/functional:2277:5:
note: candidate constructor not viable: no known conversion from '(lambda at
:27:13)' to 'const std::__1::function &' for 1st argument
function(const function&);
^
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/functional:2278:5:
note: candidate constructor not viable: no known conversion from '(lambda at
:27:13)' to 'std::__1::function &&' for 1st argument
function(function&&) _NOEXCEPT;
^
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/functional:2280:5:
note: candidate template ignored: requirement '__callable<(lambda at
:27:13), false>::value' was not satisfied [with _Fp = (lambda at
:27:13)]
function(_Fp);
^
:27:13: note: candidate function
env.run([](int, int){});
^
:17:23: note: passing argument to parameter 'func' here
auto run(Function func) -> void
^
In file included from :2:
In file included from
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/functional:497:
In file included from
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/memory:662:
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/tuple:1377:5:
error: attempt to use a deleted function
_VSTD::__invoke_constexpr(
^
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/__config:758:15:
note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_ABI_NAMESPACE
^
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/tuple:1374:26:
note: in instantiation of exception specification for
'__apply_tuple_impl &, std::__1::tuple
&, 0, 1>' requested here
constexpr decltype(auto) __apply_tuple_impl(_Fn && __f, _Tuple && __t,
^
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/tuple:1386:12:
note: in instantiation of function template specialization
'std::__1::__apply_tuple_impl &,
std::__1::tuple &, 0, 1>' requested here
_VSTD::__apply_tuple_impl(
^
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/tuple:1384:26:
note: in instantiation of exception specification for
'apply &, std::__1::tuple &>'
requested here
constexpr decltype(auto) apply(_Fn && __f, _Tuple && __t)
^
:20:14: note: in instantiation of function template specialization
'std::__1::apply &, std::__1::tuple
&>' requested here
std::apply(func, ints);
^
:27:9: note: in instantiation of member function 'Environment::run' requested here
env.run([](int, int){});
^
/opt/compiler-explorer/clang-trunk-20190717/bin/../include/c++/v1/type_traits:1680:5:
note: '~__nat' has been explicitly marked deleted here
~__nat() = delete;
^
In file included from :2:
In file included
[llvm-bugs] [Bug 42655] New: Thread safety analysis incorrectly warns when using std::scoped_lock with multiple locks
https://bugs.llvm.org/show_bug.cgi?id=42655 Bug ID: 42655 Summary: Thread safety analysis incorrectly warns when using std::scoped_lock with multiple locks Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: C++17 Assignee: unassignedclangb...@nondot.org Reporter: ohgodta...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Example: https://godbolt.org/z/d3qZS6 When using the std::scoped_lock constructor to acquire multiple locks, thread safety analysis seems to think none of the locks are taken in the ensuing block. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42656] New: Allow linking of fPIC objects into regular executables.
https://bugs.llvm.org/show_bug.cgi?id=42656 Bug ID: 42656 Summary: Allow linking of fPIC objects into regular executables. Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: s...@chromium.org CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org Currently this is not supported under wasm but is supported on other platforms. We have a couple of options for how to implement this: 1. Linker relaxation This would rewrite the "get_global + load/store" and "get_global + call_indirect" into simple load/start or call_indirect instructions. 2. Create module-internal globals for address and table offsets. I think I'll start with (2) since is simple and doesn't involve any new relocation types. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37911] clang-cl emits bogus error LNK2019: unresolved external symbol _wmemchr
https://bugs.llvm.org/show_bug.cgi?id=37911 Nico Weber changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||nicolaswe...@gmx.de --- Comment #3 from Nico Weber --- Duping into newer bug with more information. *** This bug has been marked as a duplicate of bug 41226 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37933] lld creates redundant debug entries for enums
https://bugs.llvm.org/show_bug.cgi?id=37933 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Reid Kleckner --- Nope, it's fixed, Amy's patch landed as r363089. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42657] New: lld-link needs to copy .xdata into the PDB
https://bugs.llvm.org/show_bug.cgi?id=42657 Bug ID: 42657 Summary: lld-link needs to copy .xdata into the PDB Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: amcca...@google.com, lab...@google.com, llvm-bugs@lists.llvm.org, r...@google.com The use case is for the debugger to be able to load a minidump and unwind the stack with just the PDB and without the images from the dump. To do that, the debugger needs access to the unwind opcodes normally carried in the .xdata section. This is analogous to copying the .eh_frame data from the main executable into the stripped DWARF debug symbol object. It looks like we would implement this by adding another "dbgstream" analogous to the NewFPO data dbg stream. The DbiStreamBuilder::DbgStreams field is a list of such streams. We also, of course, need to dump this 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42658] New: getAccess on template instanced CXXRecords are incorrect
https://bugs.llvm.org/show_bug.cgi?id=42658
Bug ID: 42658
Summary: getAccess on template instanced CXXRecords are
incorrect
Product: clang
Version: 8.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: release blocker
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: lolo9...@hotmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Test code:
class TEST
{
template
struct PRIVATE_TEMPLATE
{
T t;
void PRIVATE_METHOD() {}
};
PRIVATE_TEMPLATE PRIVATE_VAR;
};
Using getAccess() on PRIVATE_TEMPLATE as CXXRecord decl will return
AS_none. Even getTemplateInstantiationPattern() and getting that access returns
AS_none.
This was tested from Windows, compiled using clang-cl.
Revision "c470ac50a8a45aa62ba50d435ff3048c6c274273" from llvm-project repo:
https://github.com/llvm/llvm-project
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42659] New: x86 FeatureAVX2 ought to imply FeatureFMA
https://bugs.llvm.org/show_bug.cgi?id=42659 Bug ID: 42659 Summary: x86 FeatureAVX2 ought to imply FeatureFMA Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dgr...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Discussed here: https://android-review.googlesource.com/c/platform/frameworks/ml/+/975323/2#message-7a51026cf2d1d2d51fbde40e78b064d37a078567 If I pass -mavx2 to the compiler, I should not need to pass -mfma also in order to get FMA synthesis: Every AVX2 implementation supports FMA. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38992] Crash on ill-formed deduction guide in c++17 mode
https://bugs.llvm.org/show_bug.cgi?id=38992 rtr...@google.com changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from rtr...@google.com --- I no longer see the crash at trunk. According to godbolt, this did affect 7.0 and 8.0, but has been fixed since the last release. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 15943 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: Out-of-memory in llvm_llvm-isel-fuzzer--wasm32-O2
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-07-18 Type: Bug New issue 15943 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--wasm32-O2: Out-of-memory in llvm_llvm-isel-fuzzer--wasm32-O2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15943 Detailed report: https://oss-fuzz.com/testcase?key=5727927666212864 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--wasm32-O2 Fuzz target binary: llvm-isel-fuzzer--wasm32-O2 Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: llvm_llvm-isel-fuzzer--wasm32-O2 Sanitizer: memory (MSAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5727927666212864 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42660] New: indvars makes function broken with "opt -newgvn -reg2mem -licm -ipconstprop -loop-interchange -jump-threading -lcssa -indvars"
https://bugs.llvm.org/show_bug.cgi?id=42660
Bug ID: 42660
Summary: indvars makes function broken with "opt -newgvn
-reg2mem -licm -ipconstprop -loop-interchange
-jump-threading -lcssa -indvars"
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: csz...@163.com
CC: llvm-bugs@lists.llvm.org
Created attachment 22254
--> https://bugs.llvm.org/attachment.cgi?id=22254&action=edit
.bc file of the source code
$clang -v
clang version 9.0.0 (trunk 363125)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jack-zhou/Documents/llvm/llvm_truck/llvm2/build1/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.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.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$clang -O3 -c -emit-llvm -femit-all-decls -mllvm -disable-llvm-optzns small.c
$opt -newgvn -reg2mem -licm -ipconstprop -loop-interchange -jump-threading
-lcssa -indvars small.bc -o small-opt.bc
PHI nodes must have at least one entry. If the block is dead, the PHI should
be removed!
%cleanup.dest23.lcssa37.lcssa38 = phi i32
PHI nodes must have at least one entry. If the block is dead, the PHI should
be removed!
%.lcssa55 = phi i8*
in function d
LLVM ERROR: Broken function found, compilation aborted!
short a;
short(c)();
static int d(g) {
if (c())
h:
for (;;) {
int e;
if (g)
continue;
for (;;) {
char *b, *l;
int m, f, i, j, k;
if (a)
goto h;
}
}
return d(1);
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
