[llvm-bugs] [Bug 36023] New: False positive / hidden assumption on separate tests of static variable
https://bugs.llvm.org/show_bug.cgi?id=36023
Bug ID: 36023
Summary: False positive / hidden assumption on separate tests
of static variable
Product: clang
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: achurch+l...@achurch.org
CC: llvm-bugs@lists.llvm.org
scan-build (clang 5.0.1) reports a null dereference at the marked line in this
code:
test.c
static int n = 1;
extern void bar(void);
void foo(void)
{
int *p;
if (n > 0) {
p = &n;
} else {
p = 0;
}
bar();
for (int i = 0; i < n; i++) {
*p += i; // False positive assuming n is not externally modified.
}
}
If n is declared locally in foo() (whether static or not) or if I remove the
bar() call, the error is not reported, which makes me think that the analyzer
is assuming bar() could modify the value of n. However, clearly the address of
n can never escape this file, so at least in this case the assumption is
clearly unwarranted. Even if the file was sufficiently complex that the
analyzer couldn't make that determination, I think it would be sensible to have
the analyzer explicitly state the assumption that bar() is modifying the value
of n in its report, because otherwise it just looks like an analyzer bug.
--
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 35733] Missing leading underscore for 32-bit stdcall exports
https://bugs.llvm.org/show_bug.cgi?id=35733 Martin Storsjö changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Martin Storsjö --- This has been fixed by LLVM commit r323035 and LLD commit r323036. (They need to go together.) If this is up for backporting to 6.0, the LLD commit also requires r321790. -- 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 36024] New: Merge r322993 into the 6.0 branch: [Dominators] Visit affected node candidates found at different root levels
https://bugs.llvm.org/show_bug.cgi?id=36024 Bug ID: 36024 Summary: Merge r322993 into the 6.0 branch: [Dominators] Visit affected node candidates found at different root levels Product: tools Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: opt Assignee: unassignedb...@nondot.org Reporter: kubakuder...@gmail.com CC: llvm-bugs@lists.llvm.org The patch fixes a bug in the core of the incremental DomTree updater found in PR35969. -- 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 31265] [Meta] Load/Store/Bitcast Handling of bool vectors
https://bugs.llvm.org/show_bug.cgi?id=31265 Bug 31265 depends on bug 35520, which changed state. Bug 35520 Summary: Wrong codegen for i1 vector truncating stores https://bugs.llvm.org/show_bug.cgi?id=35520 What|Removed |Added Status|ASSIGNED|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 35520] Wrong codegen for i1 vector truncating stores
https://bugs.llvm.org/show_bug.cgi?id=35520 Jonas Paulsson changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jonas Paulsson --- trunk@323042 -- 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 36025] New: asan: AddressSanitizer-*-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc fails on Gentoo stand-alone build
https://bugs.llvm.org/show_bug.cgi?id=36025 Bug ID: 36025 Summary: asan: AddressSanitizer-*-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc fails on Gentoo stand-alone build Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: mgo...@gentoo.org CC: llvm-bugs@lists.llvm.org Blocks: 35804 Created attachment 19715 --> https://bugs.llvm.org/attachment.cgi?id=19715&action=edit sys-libs:compiler-rt-sanitizers-6.0.:20180120-132820.log.xz When testing the 6.0 branch for Gentoo, I have two new ASAN test failures: AddressSanitizer-i386-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc AddressSanitizer-x86_64-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc In both cases, the test executable segfaults without outputting anything. Curious enough, I can't reproduce this when building compiler-rt in-tree with other LLVM components. I've attempted running the working in-tree executable with LD_LIBRARY_PATH pointing to libasan built stand-alone, and it segfaulted like the stand-alone build -- therefore, I suspect the problem lies in libasan itself and not the test. I'd appreciate any suggestions how to debug this further. I'm attaching the build log for compiler-rt sanitizers. FAIL: AddressSanitizer-i386-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc (1354 of 4782) TEST 'AddressSanitizer-i386-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc' FAILED Script: -- /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0._build/lib/llvm/6/bin/clang --driver-mode=g++ -fsanitize=address -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only -m32 /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0./test/asan/TestCases/Linux/asan_rt_confict_test-1.cc -o /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0._build/test/asan/I386LinuxDynamicConfig/TestCases/Linux/Output/asan_rt_confict_test-1.cc.tmp env LD_PRELOAD=libclang_rt.asan-i386.so not /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0._build/test/asan/I386LinuxDynamicConfig/TestCases/Linux/Output/asan_rt_confict_test-1.cc.tmp 2>&1 | FileCheck /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0./test/asan/TestCases/Linux/asan_rt_confict_test-1.cc -- Exit Code: 1 Command Output (stderr): -- + /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0._build/lib/llvm/6/bin/clang --driver-mode=g++ -fsanitize=address -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only -m32 /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0./test/asan/TestCases/Linux/asan_rt_confict_test-1.cc -o /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0._build/test/asan/I386LinuxDynamicConfig/TestCases/Linux/Output/asan_rt_confict_test-1.cc.tmp + FileCheck /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0./test/asan/TestCases/Linux/asan_rt_confict_test-1.cc + env LD_PRELOAD=libclang_rt.asan-i386.so not /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0._build/test/asan/I386LinuxDynamicConfig/TestCases/Linux/Output/asan_rt_confict_test-1.cc.tmp /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0./test/asan/TestCases/Linux/asan_rt_confict_test-1.cc:13:11: error: expected string not found in input // CHECK: Your application is linked against incompatible ASan runtimes ^ :1:1: note: scanning from here ERROR: ld.so: object 'libclang_rt.asan-i386.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ^ :2:1: note: possible intended match here Error: Segmentation fault ^ -- FAIL: AddressSanitizer-x86_64-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc (2197 of 4782) TEST 'AddressSanitizer-x86_64-linux-dynamic :: TestCases/Linux/asan_rt_confict_test-1.cc' FAILED Script: -- /var/tmp/portage/sys-libs/compiler-rt-sanitizers-6.0./work/compiler-rt-sanitizers-6.0._build/lib/llvm/6/bin/clang --driver-mode=g++ -fsanitize=address -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only -m64 /var/tmp/portage/sys-libs/compiler-
[llvm-bugs] [Bug 36026] New: LeakSanitizer throws fatal error around std::async
https://bugs.llvm.org/show_bug.cgi?id=36026
Bug ID: 36026
Summary: LeakSanitizer throws fatal error around std::async
Product: new-bugs
Version: 6.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: gja...@googlemail.com
CC: llvm-bugs@lists.llvm.org
Hello,
I encounter the following leak sanitizer error on Ubuntu Bionic:
#include
int main()
{
auto write = std::async(std::launch::async, []() {});
write.wait();
return 0;
}
$ clang++-6.0 -fsanitize=address -o testcase testcase.cpp && ./testcase
==8777==LeakSanitizer has encountered a fatal error.
==8777==HINT: For debugging, try setting environment variable
LSAN_OPTIONS=verbosity=1:log_threads=1
==8777==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
Environment:
* Ubuntu Bionic on amd64
* Clang 1:6.0~svn321357 from llvm-toolchain-snapshot (in universe-proposed
repo)
* Libstdc++ 7.2.0-19ubuntu1
Thanks,
Gregor
Full Debug output with LSAN_OPTIONS=verbosity=1:log_threads=1
==8784==AddressSanitizer: libc interceptors initialized
|| `[0x10007fff8000, 0x7fff]` || HighMem||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x8fff7000, 0x02008fff6fff]` || ShadowGap ||
|| `[0x7fff8000, 0x8fff6fff]` || LowShadow ||
|| `[0x, 0x7fff7fff]` || LowMem ||
MemToShadow(shadow): 0x8fff7000 0x91ff6dff 0x004091ff6e00
0x02008fff6fff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
thread_local_quarantine_size_kb=1024K
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x7fff8000
==8784==Installed the sigaction for signal 11
==8784==Installed the sigaction for signal 7
==8784==Installed the sigaction for signal 8
==8784==T0: stack [0x7fff2012a000,0x7fff2092a000) size 0x80;
local=0x7fff20928d88
==8784==AddressSanitizer Init done
==8784==T1: stack [0x7f0e63aff000,0x7f0e642fef40) size 0x7fff40;
local=0x7f0e642fee58
==8784==T1 TSDDtor
==8784==T1 exited
==8786==Could not attach to thread 8784 (errno 1).
==8786==Failed suspending threads.
==8784==LeakSanitizer has encountered a fatal error.
==8784==HINT: For debugging, try setting environment variable
LSAN_OPTIONS=verbosity=1:log_threads=1
==8784==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
--
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 36027] New: Merge r323039 into the 6.0 branch
https://bugs.llvm.org/show_bug.cgi?id=36027 Bug ID: 36027 Summary: Merge r323039 into the 6.0 branch Product: compiler-rt Version: 6.0 Hardware: Other OS: OpenBSD Status: NEW Severity: release blocker Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: b...@comstyle.com CC: llvm-bugs@lists.llvm.org Blocks: 35804 Please merge r323039 to implement __clear_cache() for OpenBSD/mips64. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=35804 [Bug 35804] [meta] 6.0.0 Release Blockers -- 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 36028] New: Incorrect use of pushf/popf enables/disables interrupts on amd64 kernels
https://bugs.llvm.org/show_bug.cgi?id=36028
Bug ID: 36028
Summary: Incorrect use of pushf/popf enables/disables
interrupts on amd64 kernels
Product: libraries
Version: 6.0
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: jonloo...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19716
--> https://bugs.llvm.org/attachment.cgi?id=19716&action=edit
Patch to make LLVM do a slightly better job at restoring the EFLAGS register
I am a FreeBSD kernel developer. While making a seemingly-simple change to the
FreeBSD kernel, I found that interrupt handling was suddenly incorrect. After
troubleshooting for some time, I found that this was due to the way LLVM's x86
backend is using pushf/popf to save/restore EFLAGS across function calls.
Simple reproduction (which requires no headers):
---Start File---
void spinlock_acquire(void);
void spinlock_release(void);
void fx(void);
void otherfx(void);
static int count = 0;
void
fx(void)
{
_Bool needtocall;
spinlock_acquire();
needtocall = (++count == 0);
spinlock_release();
if (needtocall)
otherfx();
}
---End File---
In the above file, assume that spinlock_acquire() may disable interrupts and
spinlock_release() my enable interrupts.
If you compile this code using clang (5.0.0, 5.0.1, or 6.0.0 all behave
similarly in the critical respect) with the -O2 and -S flags for a generic
x86-64 cpu, you will see that LLVM generates this assembly:
---Start Assembly---
.text
.file "popfqtest.c"
.globl fx # -- Begin function fx
.p2align4, 0x90
.type fx,@function
fx: # @fx
.cfi_startproc
# BB#0: # %entry
pushq %rbp
.Lcfi0:
.cfi_def_cfa_offset 16
.Lcfi1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
.Lcfi2:
.cfi_def_cfa_register %rbp
pushq %rbx
pushq %rax
.Lcfi3:
.cfi_offset %rbx, -24
callq spinlock_acquire
inclcount(%rip)
pushfq
popq%rbx
callq spinlock_release
addq$8, %rsp
pushq %rbx
popfq
je .LBB0_2
# BB#1: # %if.end
popq%rbx
popq%rbp
retq
.LBB0_2:# %if.then
popq%rbx
popq%rbp
jmp otherfx # TAILCALL
.Lfunc_end0:
.size fx, .Lfunc_end0-fx
.cfi_endproc
# -- End function
.type count,@object # @count
.local count
.comm count,4,4
.ident "FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880)
(based on LLVM 5.0.1)"
.section".note.GNU-stack","",@progbits
---End Assembly---
The critical part is the way that LLVM handles the conditional:
1. Increment the value. This will set ZF if count reaches 0:
inclcount(%rip)
2. Now, save the status flags (particularly, ZF) using pushfq. Critically,
pushfq saves the entire EFLAGS value, which includes the interrupt flag.
Because we are holding a spin mutex, interrupts are disabled at this point:
pushfq
popq%rbx
3. Now, call the function to unlock the spin mutex, which will potentially
enable interrupts.
callq spinlock_release
4. Now, restore the status flags. Critically, popfq restores the entire EFLAGS
value, which includes the interrupt flag. Because interrupts were disabled when
the flags were stored, these instructions will disable them again:
addq$8, %rsp
pushq %rbx
popfq
5. Now, use the status flags to determine whether to call the function:
je .LBB0_2
After running this code, interrupts may remain erroneously disabled.
(This is a contrived minimal test case, but I did run into this bug while
testing a code change in the kernel. Interrupts remained erroneously disabled
after dropping a spin lock.)
By now, the bug should be obvious: LLVM shouldn't save and restore the entire
EFLAGS register. It doesn't know what changes these other function calls make
to the values of the EFLAGS register about which clang doesn't care (e.g. IF,
IOPL, AC, etc.). By saving and restoring EFLAGS across function calls, it can
load incorrect values for these other flags.
It looks like the correct solutions are to either not save EFLAGS across
function calls, or to just save the individual flag(s) that need to be
evaluated across the function call. (For example, a simple setz/test would
probably be sufficient -- and more efficient -- in this particular case.)
However, these ap
[llvm-bugs] [Bug 36029] New: After r318497, --as-needed does not seem to work correctly anymore
https://bugs.llvm.org/show_bug.cgi?id=36029
Bug ID: 36029
Summary: After r318497, --as-needed does not seem to work
correctly anymore
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org
Using recent versions of lld 6.0.0 in FreeBSD, we've noticed that libgcc_s.so
always gets linked into executables and libraries, even if none of its
functions appear to be used.
E.g.:
$ cat main.c
int main(void) { return 0; }
$ cc -c main.c -o main.o
(The following is what cc normally runs to link a plain executable)
$ ld.lld --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both
--enable-new-dtags -o main /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o
-L/usr/lib main.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
$ readelf -d main
Dynamic section at offset 0x3028 contains 19 entries:
TagType Name/Value
0x0001 NEEDED Shared library: [libgcc_s.so.1]
0x0001 NEEDED Shared library: [libc.so.7]
0x0015 DEBUG0x0
[...]
This appears to have regressed with https://reviews.llvm.org/rL318497 ("Remove
IsLocal"). Linking with lld just before that avoids pulling in libgcc_s.so:
$ ~/obj/lld-318496/bin/ld.lld --eh-frame-hdr -dynamic-linker
/libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o main
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib main.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/crtend.o /usr/lib/crtn.o
$ readelf -d main
Dynamic section at offset 0x3028 contains 18 entries:
TagType Name/Value
0x0001 NEEDED Shared library: [libc.so.7]
0x0015 DEBUG0x0
[...]
--
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 36030] New: total crash on big static array
https://bugs.llvm.org/show_bug.cgi?id=36030
Bug ID: 36030
Summary: total crash on big static array
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: shmuelhan...@gmail.com
CC: llvm-bugs@lists.llvm.org
Hi,
This:
void foo()
{
static int arr[10] = {0};
}
Cause my whole machine to hang badly and crash, when I try to compile it using
clang 3.8.1-24. I am using debian 9.2.
--
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] Issue 5532 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.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-01-21 Type: Bug New issue 5532 by ClusterFuzz-External: llvm/llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5532 Detailed report: https://oss-fuzz.com/testcase?key=6297749109604352 Project: llvm Fuzzer: libFuzzer_llvm_llvm-dwarfdump-fuzzer Fuzz target binary: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::DWARFFormValue::getFixedByteSize llvm::DWARFAbbreviationDeclaration::extract Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201708280446:201708291805 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6297749109604352 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 have questions for the OSS-Fuzz team, 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] Issue 5537 in oss-fuzz: llvm/clang-proto-fuzzer: ASSERT: isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.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-01-21 Type: Bug New issue 5537 by ClusterFuzz-External: llvm/clang-proto-fuzzer: ASSERT: isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5537 Detailed report: https://oss-fuzz.com/testcase?key=6643839252037632 Project: llvm Fuzzer: libFuzzer_llvm_clang-proto-fuzzer Fuzz target binary: clang-proto-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant llvm::ScalarEvolution::getAddRecExpr llvm::ScalarEvolution::getMulExpr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712190608:201712210617 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6643839252037632 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 have questions for the OSS-Fuzz team, 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
