[llvm-bugs] Issue 10023 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Select) && "Input should be a SelectInst!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-08-23 Type: Bug New issue 10023 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: isa(Select) && "Input should be a SelectInst!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10023 Detailed report: https://oss-fuzz.com/testcase?key=5094136156258304 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-instcombine Fuzz target binary: llvm-opt-fuzzer--x86_64-instcombine Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isa(Select) && "Input should be a SelectInst!" ComputeNumSignBitsImpl ComputeNumSignBitsImpl Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201808221503:201808230127 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5094136156258304 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38676] New: LTO ignores -fPIC/-fPIE when building a non PIE executable
https://bugs.llvm.org/show_bug.cgi?id=38676
Bug ID: 38676
Summary: LTO ignores -fPIC/-fPIE when building a non PIE
executable
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mh+l...@glandium.org
CC: llvm-bugs@lists.llvm.org
$ cat hello.c
#include
int main() {
printf("Hello, world\n");
return 0;
}
$ clang-7 -o hello hello.c -O3 -fPIC -flto=thin # same result with -flto
$ objdump -d hello
(...)
00401130 :
401130: 50 push %rax
401131: bf 04 20 40 00 mov$0x402004,%edi
401136: e8 f5 fe ff ff callq 401030
40113b: 31 c0 xor%eax,%eax
40113d: 59 pop%rcx
40113e: c3 retq
40113f: 90 nop
(...)
Note how the string is loaded with an absolute address, compared to:
$ clang-7 -o hello hello.c -O3 -fPIC
$ objdump -d hello
(...)
00401130 :
401130: 50 push %rax
401131: 48 8d 3d cc 0e 00 00lea0xecc(%rip),%rdi# 402004
<_IO_stdin_used+0x4>
401138: e8 f3 fe ff ff callq 401030
40113d: 31 c0 xor%eax,%eax
40113f: 59 pop%rcx
401140: c3 retq
401141: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
401148: 00 00 00
40114b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
(...)
FWIW, GCC does respect -fPIC/-fPIE on LTOed non-PIE executables.
--
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 38677] New: isSignedMinMaxClamp - isa(Select) && "Input should be a SelectInst!"
https://bugs.llvm.org/show_bug.cgi?id=38677
Bug ID: 38677
Summary: isSignedMinMaxClamp - isa(Select) &&
"Input should be a SelectInst!"
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, efrie...@codeaurora.org,
llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com
isSignedMinMaxClamp is asserting in the following case, reduced from
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10023
; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "llvm/test/Transforms/InstCombine/phi-select-constant.ll"
target triple = "x86_64-unknown-linux-gnu"
@A = extern_weak global i32, align 4
@B = extern_weak global i32, align 4
define i32 @foo(i1 %which) {
entry:
br i1 true, label %final, label %delay
delay:; preds = %entry
br label %final
final:; preds = %delay, %entry
%use2 = phi i1 [ false, %entry ], [ icmp eq (i32* @A, i32* @B), %delay ]
%value = select i1 %use2, i32 2, i32 1
%B7 = mul i32 %value, 2147483647
%C3 = icmp ule i32 %B7, 0
store i1 %C3, i1* undef
ret i32 %value
}
--
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 38679] New: -GS stack buffer checks are expensive
https://bugs.llvm.org/show_bug.cgi?id=38679 Bug ID: 38679 Summary: -GS stack buffer checks are expensive Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: dma...@mozilla.com CC: froy...@gmail.com, h...@chromium.org, llvm-bugs@lists.llvm.org, r...@google.com We recently observed that compiling Firefox with `-GS-` gives a 4-6% improvement to our perf test suite in clang-cl builds. Adding the same flag to MSVC builds gives a <1% improvement if anything. Is there anything that can be done to improve clang's implementation? I found this review (a bit old, not sure if it's still relevant) https://reviews.llvm.org/D20346 that says "I think we can look into situations where Clang emits stack guards and MSVC doesn't if that turns out to be a problem later." As a first guess: https://msdn.microsoft.com/en-us/library/8dbf701c.aspx#Anchor_3 describes some limitations on the buffers that MSVC checks. I wonder if clang that into account? -- 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 38680] New: The RegisterCoalescer don't propagate undef flag when removing IMPLICIT_DEF
https://bugs.llvm.org/show_bug.cgi?id=38680 Bug ID: 38680 Summary: The RegisterCoalescer don't propagate undef flag when removing IMPLICIT_DEF Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: karl-johan.karls...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 20760 --> https://bugs.llvm.org/attachment.cgi?id=20760&action=edit llc -O0 -mtriple i686-- -o - ./registercoalescer_implicitdef.mir -run-pass=simple-register-coalescing $ llc -O0 -mtriple i686-- -o - ./registercoalescer_implicitdef.mir -run-pass=simple-register-coalescing # Machine code for function main: NoPHIs, TracksLiveness bb.0: %1:gr32 = ADD32ri8 %1:gr32, 1, implicit-def dead $eflags CMP32ri8 %0:gr32, 42, implicit-def $eflags # End machine code for function main. *** Bad machine code: Reading virtual register without a def *** - function:main - basic block: %bb.0 (0x6d981f8) - instruction: CMP32ri8 %0:gr32, 42, implicit-def $eflags - operand 0: %0:gr32 LLVM ERROR: Found 1 machine code errors. -- 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 38681] New: Debian (sid) libomp5-8 issues.
https://bugs.llvm.org/show_bug.cgi?id=38681 Bug ID: 38681 Summary: Debian (sid) libomp5-8 issues. Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: llvm-bugs@lists.llvm.org The libomp5-8 and libomp5-7 are not co-installable. If libomp5-8 is installed, then there is openmp support in clang-8, but not in clang-7. I suspect the opposite is true, too. It is because libomp is installed in clang-8 specific directory, so linking 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 38682] New: Race condition in __make_async_assoc_state
https://bugs.llvm.org/show_bug.cgi?id=38682
Bug ID: 38682
Summary: Race condition in __make_async_assoc_state
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ldio...@apple.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The following program exhibits a race condition, which can be seen by running
it under Tsan:
--
#include
#include
#include
#include
static int worker(std::vector const& data) {
return std::accumulate(data.begin(), data.end(), 0);
}
int main() {
std::vector const v{1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
for (int i = 0; i != 20; ++i) {
std::future fut = std::async(std::launch::async, worker, v);
std::future fut2 = std::async(std::launch::async, worker, v);
int answer = fut.get();
int answer2 = fut2.get();
assert(answer == answer2);
}
}
--
$ clang++ -std=c++11 -fsanitize=thread main.cpp -o main.exe && ./main.exe
--
WARNING: ThreadSanitizer: data race (pid=97622)
Write of size 4 at 0x7b2c0088 by thread T1 (mutexes: write M14):
#0 void std::__1::__assoc_state::set_value(int&&) :1062560
(main.exe:x86_64+0x1556b)
#1 std::__1::__async_assoc_state > const&),
std::__1::vector > > >::__execute()
:1062560 (main.exe:x86_64+0x147de)
#2 void*
std::__1::__thread_proxy >, void
(std::__1::__async_assoc_state > const&),
std::__1::vector > > >::*)(),
std::__1::__async_assoc_state > const&),
std::__1::vector > > >*> >(void*) :1062560
(main.exe:x86_64+0x16b82)
Previous read of size 4 at 0x7b2c0088 by main thread:
#0 std::__1::future::future(std::__1::__assoc_state*)
:1062560 (main.exe:x86_64+0x171f1)
#1 std::__1::future::future(std::__1::__assoc_state*)
:1062560 (main.exe:x86_64+0x143c8)
#2 std::__1::future std::__1::__make_async_assoc_state >
const&), std::__1::vector > >
>(std::__1::__async_func
> const&), std::__1::vector > >&&) :1062560
(main.exe:x86_64+0x13a13)
#3 std::__1::future > const&)>::type,
std::__1::decay >
const&>::type>::type> std::__1::async > const&), std::__1::vector > const&>(std::__1::launch, int
(&&&)(std::__1::vector > const&),
std::__1::vector > const&&&) :1062560
(main.exe:x86_64+0x1196a)
#4 main :1062560 (main.exe:x86_64+0x1104c)
Location is heap block of size 176 at 0x7b2c allocated by main
thread:
#0 operator new(unsigned long) :1062592
(libclang_rt.tsan_osx_dynamic.dylib:x86_64h+0x6e733)
#1 std::__1::future std::__1::__make_async_assoc_state >
const&), std::__1::vector > >
>(std::__1::__async_func
> const&), std::__1::vector > >&&) :1062592
(main.exe:x86_64+0x136c8)
#2 std::__1::future > const&)>::type,
std::__1::decay >
const&>::type>::type> std::__1::async > const&), std::__1::vector > const&>(std::__1::launch, int
(&&&)(std::__1::vector > const&),
std::__1::vector > const&&&) :1062592
(main.exe:x86_64+0x1196a)
#3 main :1062592 (main.exe:x86_64+0x1104c)
Mutex M14 (0x7b2c0018) created at:
#0 pthread_mutex_lock :1062448
(libclang_rt.tsan_osx_dynamic.dylib:x86_64h+0x3945e)
#1 std::__1::mutex::lock() :1062448 (libc++.1.dylib:x86_64+0x3a698)
#2 std::__1::__async_assoc_state > const&),
std::__1::vector > > >::__execute()
:1062448 (main.exe:x86_64+0x147de)
#3 void*
std::__1::__thread_proxy >, void
(std::__1::__async_assoc_state > const&),
std::__1::vector > > >::*)(),
std::__1::__async_assoc_state > const&),
std::__1::vector > > >*> >(void*) :1062448
(main.exe:x86_64+0x16b82)
Thread T1 (tid=572648, running) created by main thread at:
#0 pthread_create :1062640
(libclang_rt.tsan_osx_dynamic.dylib:x86_64h+0x2a13d)
#1 std::__1::thread::thread >
const&), std::__1::vector > > >::*)(),
std::__1::__async_assoc_state > const&),
std::__1::vector > > >*, void>(void
(std::__1::__async_assoc_state > const&),
std::__1::vector > > >::*&&)(),
std::__1::__async_assoc_state > const&),
std::__1::vector > > >*&&) :1062640
(main.exe:x86_64+0x160d0)
#2 std::__1::thread::thread >
const&), std::__1::vector > > >::*)(),
std::__1::__async_assoc_state > const&),
std::__1::vector > > >*, void>(void
(std::__1::__async_assoc_state > const&),
std::__1::vector > > >::*&&)(),
std::__1::__async_assoc_state > const&),
std::__1::vector > > >*&&) :1062640
(main.exe:x86_64+0x14358)
#3 std::__1::future std::__1::__make_async_assoc_state >
const&), std::__1::vector > >
>(std::__1::__async_func
> const&), std::__1::vector > >&&) :1062640
(main.exe:x86_64+0x139b0)
#4 std::__1::future > const&)>::type,
std::__1::decay
[llvm-bugs] [Bug 38683] New: [NewGVN] Running NewGVN twice back-to-back discovers additional equivalences
https://bugs.llvm.org/show_bug.cgi?id=38683
Bug ID: 38683
Summary: [NewGVN] Running NewGVN twice back-to-back discovers
additional equivalences
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: florian.h...@arm.com
CC: llvm-bugs@lists.llvm.org
running `opt -newgvn -newgvn` on the code below eliminates %bf.set.1 and
%bf.clear.1, but `opt -newgvn` does not.
@a = external global i64
define void @fn1(i1 %bc) {
entry:
br label %for.cond
for.cond: ; preds = %for.cond1.1,
%entry
%tmp = phi i1 [ 1, %entry ], [ 1, %for.cond ]
%conv = zext i1 %tmp to i32
%lv = load i32, i32* bitcast (i64* @a to i32*)
%bf.clear = and i32 %lv, -131072
%bf.set = or i32 %conv, %bf.clear
%bf.clear.1 = and i32 %bf.set, -131072
%bf.set.1 = or i32 1, %bf.clear.1
br i1 %bc, label %for.cond, label %exit
exit: ; preds = %for.cond1
store i32 %bf.set.1, i32* bitcast (i64* @a to i32*)
ret void
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38677] isSignedMinMaxClamp - isa(Select) && "Input should be a SelectInst!"
https://bugs.llvm.org/show_bug.cgi?id=38677 Craig Topper changed: What|Removed |Added Fixed By Commit(s)||r340546 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Craig Topper --- Should be fixed after r340546 -- 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 37595] -fvisibility-inlines-hidden marks static local variables as hidden when it shouldn't
https://bugs.llvm.org/show_bug.cgi?id=37595 Reid Kleckner changed: What|Removed |Added Fixed By Commit(s)||r340386 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Reid Kleckner --- Marking fixed by r340386. -- 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 38670] miscompilation: segfault with -O2
https://bugs.llvm.org/show_bug.cgi?id=38670 Eli Friedman changed: What|Removed |Added Status|NEW |RESOLVED CC||efrie...@codeaurora.org Resolution|--- |INVALID --- Comment #1 from Eli Friedman --- -fsanitize=undefined says "runtime error: load of misaligned address 0x00ec5f14 for type 'aint' (aka 'int'), which requires 16 byte alignment". -- 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
