[llvm-bugs] Issue 3659 in oss-fuzz: llvm/clang-fuzzer: ASSERT: BitWidth && "bitwidth too small"
Comment #2 on issue 3659 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/clang-fuzzer: ASSERT: BitWidth && "bitwidth too small" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3659#c2 ClusterFuzz has detected this issue as fixed in range 201710210625:201710220448. Detailed report: https://oss-fuzz.com/testcase?key=5142514165088256 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: BitWidth && "bitwidth too small" llvm::APSInt::getMaxValue AnalyzeImplicitConversions Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710150453:201710160455 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710210625:201710220448 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5142514165088256 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 3659 in oss-fuzz: llvm/clang-fuzzer: ASSERT: BitWidth && "bitwidth too small"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 3659 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/clang-fuzzer: ASSERT: BitWidth && "bitwidth too small" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3659#c3 ClusterFuzz testcase 5142514165088256 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 3727 in oss-fuzz: llvm/llvm-special-case-list-fuzzer: Global-buffer-overflow in p_bracket
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-10-22 New issue 3727 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-special-case-list-fuzzer: Global-buffer-overflow in p_bracket https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3727 Detailed report: https://oss-fuzz.com/testcase?key=5367749363630080 Project: llvm Fuzzer: libFuzzer_llvm_llvm-special-case-list-fuzzer Fuzz target binary: llvm-special-case-list-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Global-buffer-overflow READ 1 Crash Address: 0x006a18bc Crash State: p_bracket p_ere p_ere Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5367749363630080 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] [Bug 35021] Segmentation fault on running clang-analyze checks
https://bugs.llvm.org/show_bug.cgi?id=35021 Alexander Kornienko changed: What|Removed |Added Assignee|unassignedclangbugs@nondot. |dcough...@apple.com |org | Product|clang-tools-extra |clang CC||llvm-bugs@lists.llvm.org Component|clang-tidy |Static Analyzer --- Comment #6 from Alexander Kornienko --- It's quite difficult to isolate the -- 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 35029] New: libclang: unterminated conditional directive when generating preamble
https://bugs.llvm.org/show_bug.cgi?id=35029
Bug ID: 35029
Summary: libclang: unterminated conditional directive when
generating preamble
Product: clang
Version: 5.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: puremourn...@gmail.com
CC: llvm-bugs@lists.llvm.org
Since clang 5.0 (and currently in master), libclang reports "unterminated
conditional directive" when an "include guarded" file transitively includes
itself. Or at least that's how it appears.
There are two simple test cases, both of which compile fine when _not_ in
"editing" mode, but raise "unterminated conditional directive" when building a
preamble.
More info: https://github.com/Valloric/YouCompleteMe/issues/2795
Tests reproduced with both clang 5.0 prebuilt binaries and a build of master as
of yesterday (Sat 21st October).
Test case 1: Header includes itself.
```circular.h
#ifndef TEST_C
#define TEST_C
#include "test.c"
int main() {}
#endif
```
Normal compilation
```
BeniMac:basic ben$ /Users/ben/Development/llvm.git-build/bin/c-index-test
-test-load-source local circular.h
// CHECK: :2:9: macro definition=__llvm__
// CHECK: :3:9: macro definition=__clang__
// CHECK: :4:9: macro definition=__clang_major__
// CHECK: :5:9: macro definition=__clang_minor__
// CHECK: :6:9: macro definition=__clang_patchlevel__
...
works.
```
In editing mode:
```
BeniMac:basic ben$ CINDEXTEST_EDITING=1
/Users/ben/Development/llvm.git-build/bin/c-index-test -test-load-source local
circular.h
// CHECK: circular.h:6:5: FunctionDecl=main:6:5 (Definition) Extent=[6:1 -
6:14]
// CHECK: circular.h:6:12: CompoundStmt= Extent=[6:12 - 6:14]
./circular.h:1:2: error: unterminated conditional directive
Number FIX-ITs = 0
```
Test case 2 (perhaps more realistic in editor scenarios, where users use
`-include b.h` to make completion work within `a.h`):
```a.h
#include "b.h"
#ifndef A_H
#define A_H
int main() {}
#endif /* A_H */
```
```b.h
#ifndef B_H
#define B_H
#include "a.h"
#endif /* B_H */
```
Again, compilation is fine until using the editor flags:
```
BeniMac:basic ben$ CINDEXTEST_EDITING=1
/Users/ben/Development/llvm.git-build/bin/c-index-test -test-load-source local
a.h
// CHECK: a.h:4:5: FunctionDecl=main:4:5 (Definition) Extent=[4:1 - 4:14]
// CHECK: a.h:4:12: CompoundStmt= Extent=[4:12 - 4:14]
./a.h:2:2: error: unterminated conditional directive
Number FIX-ITs = 0
```
I _suspect_ (truly a guess), that this commit is the culprit, though I haven't
proven it: https://reviews.llvm.org/D15994#95a083c2
--
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 35030] New: clang-format does weird things to comment indentation in __asm blocks
https://bugs.llvm.org/show_bug.cgi?id=35030
Bug ID: 35030
Summary: clang-format does weird things to comment indentation
in __asm blocks
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
In:
__declspec(naked) bool SafeTerminateProcess(HANDLE process, UINT exit_code) {
__asm {
push ebp
mov ebp, esp
push [ebp+12]
push [ebp+8]
call TerminateProcess
// Convert from BOOL to bool.
test eax, eax
setne al
// TerminateProcess() is supposed to be stdcall (callee clean-up), and esp
// and ebp are expected to already be equal. But if it’s been patched badly
// by something that’s cdecl (caller clean-up), this next move will get
// things back on track.
mov esp, ebp
pop ebp
ret
}
}
Out:
// This function is written in assembler source because it’s important for it
// to not be inlined, for it to allocate a stack frame, and most critically,
// for it to not trust esp on return from TerminateProcess().
// __declspec(naked) conveniently prevents inlining and allows us to control
// stack layout.
__declspec(naked) bool SafeTerminateProcess(HANDLE process, UINT exit_code) {
__asm {
push ebp
mov ebp, esp
push [ebp+12]
push [ebp+8]
call TerminateProcess
// Convert from BOOL to bool.
test eax, eax
setne al
// TerminateProcess() is supposed to be stdcall (callee clean-up), and
// esp and ebp are expected to already be equal. But if it’s been
// patched badly by something that’s cdecl (caller clean-up), this next
// move will get things back on track.
mov esp, ebp
pop ebp
ret
}
}
Should just keep the initial version.
--
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 28241] Wrong optimization of type-punning with two pointers involved
https://bugs.llvm.org/show_bug.cgi?id=28241 Alexander Cherepanov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Alexander Cherepanov --- Dup of bug 11966. Anyway, fixed in clang 5. -- 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 35031] New: clang-cl /FA should probably default to intel syntax
https://bugs.llvm.org/show_bug.cgi?id=35031 Bug ID: 35031 Summary: clang-cl /FA should probably default to intel syntax Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org clang-cl /FA currently produces AT&T asm output. I can pass `-mllvm --x86-asm-syntax=intel` to force intel syntax (the regular clang driver supports `-masm=intel`, but clang-cl understandably doesn't expose that), but since cl.exe produces intel syntax, we probably want to default to that for clang-cl too? -- 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 11966] possible union bug
https://bugs.llvm.org/show_bug.cgi?id=11966 Alexander Cherepanov changed: What|Removed |Added Resolution|DUPLICATE |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 28241] Wrong optimization of type-punning with two pointers involved
https://bugs.llvm.org/show_bug.cgi?id=28241 Alexander Cherepanov changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Alexander Cherepanov --- *** This bug has been marked as a duplicate of bug 11966 *** -- 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 35032] New: lld's debug info is not compatible with valgrind
https://bugs.llvm.org/show_bug.cgi?id=35032
Bug ID: 35032
Summary: lld's debug info is not compatible with valgrind
Product: lld
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Assume we have this C source file.
$ cat foo.c
#include
int main() { for (int i = 0; i < 100; i++) malloc(10); }
When I link an executable with bfd or gold, ms_print correctly prints out the
source location where we allocate heap memory.
$ clang -g -o foo foo.c
$ valgrind --tool=massif --massif-out-file=massif.foo ./foo
$ ms_print massif.foo
(omit)
->41.67% (127,990B) 0x40053D: main (in /ssd/b/foo)
However, if we use lld, it doesn't.
$ clang -g -o foo foo.c -fuse-ld=lld
$ valgrind --tool=massif --massif-out-file=massif.foo ./foo
$ ms_print massif.foo
->41.67% (127,990B) 0x20111D: ??? (in /ssd/b/foo)
->41.67% (127,990B) 0x4E4FF43: (below main) (libc-start.c:287)
Looks like we are producing debug info which valgrind cannot read.
--
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 31955] LLVM Fails to disassemble embedded rounding control
https://bugs.llvm.org/show_bug.cgi?id=31955 Craig Topper changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Craig Topper --- Fixed in r316308 -- 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 10988] x86 MC encoder and disassembler bugs umbrella
https://bugs.llvm.org/show_bug.cgi?id=10988 Bug 10988 depends on bug 31955, which changed state. Bug 31955 Summary: LLVM Fails to disassemble embedded rounding control https://bugs.llvm.org/show_bug.cgi?id=31955 What|Removed |Added Status|NEW |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] Issue 3729 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-10-23 New issue 3729 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3729 Detailed report: https://oss-fuzz.com/testcase?key=4648045753925632 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isa(Val) && "cast() argument of incompatible type!" llvm::BasicAAResult::DecomposeGEPExpression llvm::BasicAAResult::aliasGEP Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4648045753925632 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 3730 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-10-23 New issue 3730 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3730 Detailed report: https://oss-fuzz.com/testcase?key=4796527571632128 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc7f33ab88 Crash State: clang::DiagnosticIDs::isUnrecoverable clang::DiagnosticIDs::ProcessDiag clang::DiagnosticsEngine::EmitCurrentDiagnostic Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710121744:201710130152 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4796527571632128 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] [Bug 33356] The [[clang::xray_log_args(1)]] attribute does not apply to the implicit `this` for C++ methods
https://bugs.llvm.org/show_bug.cgi?id=33356 Dean Michael Berris changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dean Michael Berris --- This has been fixed a while back, closing now to reflect the state. -- 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 32274] XRay should not use C++ standard libraries internally
https://bugs.llvm.org/show_bug.cgi?id=32274 Dean Michael Berris changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #3 from Dean Michael Berris --- Re-opening to reflect the most recent state: we should not be using anything from the C++ standard library. This is based on the conversation we've had in llvm-dev@: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118126.html In particular: """ The sanitizers don't use any of the C++ std library. More than that, they don't include *any* system headers in most of the sources (exception is some OS-dependent .cc files). This rule is *somewhat* documented, e.g. tsan/rtl/tsan_rtl.h: // - No system headers included in header files (*). // - Platform specific headres included only into platform-specific files (*). """ http://lists.llvm.org/pipermail/llvm-dev/2017-October/118132.html -- 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 11304] [x86 disassembler] Certain VEX instructions ignore the W-bit that shouldn't
https://bugs.llvm.org/show_bug.cgi?id=11304 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Craig Topper --- Fixed in r316285 -- 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 10988] x86 MC encoder and disassembler bugs umbrella
https://bugs.llvm.org/show_bug.cgi?id=10988 Bug 10988 depends on bug 11304, which changed state. Bug 11304 Summary: [x86 disassembler] Certain VEX instructions ignore the W-bit that shouldn't https://bugs.llvm.org/show_bug.cgi?id=11304 What|Removed |Added Status|NEW |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] Issue 3731 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-10-23 New issue 3731 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--x86_64-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3731 Detailed report: https://oss-fuzz.com/testcase?key=5975111963246592 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::X86InstrInfo::copyPhysReg ExpandPostRA::runOnMachineFunction Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5975111963246592 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
