[llvm-bugs] Issue 13503 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_unswitch: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef
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 Stability-Memory-AddressSanitizer Reproducible Stability-Memory-LeakSanitizer Engine-libfuzzer Proj-llvm Reported-2019-03-03 Type: Bug New issue 13503 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_unswitch: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13503 Detailed report: https://oss-fuzz.com/testcase?key=5716861147152384 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_asan_llvm Platform Id: linux Crash Type: Direct-leak Crash Address: Crash State: llvm::BitcodeReaderValueList::getValueFwdRef llvm::MetadataLoader::MetadataLoaderImpl::parseOneMetadata llvm::MetadataLoader::MetadataLoaderImpl::parseMetadata Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201811280235:201811290236 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5716861147152384 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13505 in oss-fuzz: llvm/clangd-fuzzer: ASSERT: DirInfo && "The directory of a virtual file should already be in the cache."
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-03-03 Type: Bug New issue 13505 by ClusterFuzz-External: llvm/clangd-fuzzer: ASSERT: DirInfo && "The directory of a virtual file should already be in the cache." https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13505 Detailed report: https://oss-fuzz.com/testcase?key=5752852570439680 Project: llvm Fuzzer: libFuzzer_llvm_clangd-fuzzer Fuzz target binary: clangd-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: DirInfo && "The directory of a virtual file should already be in the cache." clang::FileManager::getVirtualFile clang::ASTReader::getInputFile Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201901220414:201902020421 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5752852570439680 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40940] New: clang crashing on __builtin_assume
https://bugs.llvm.org/show_bug.cgi?id=40940
Bug ID: 40940
Summary: clang crashing on __builtin_assume
Product: new-bugs
Version: 8.0
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ois...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 21556
--> https://bugs.llvm.org/attachment.cgi?id=21556&action=edit
bugpoint reduction
Clang-8 crash somewhere along computeKnownBits.
Compile with -O -mssse3:
typedef char__v16qi __attribute__((__vector_size__(16)));
typedef long long __m128i __attribute__((__vector_size__(16)));
typedef long long int64_t;
void expand_p6(__m128i *in, __m128i *out)
{
*out = __builtin_ia32_pshufb128(*in, (__v16qi){ 0,1,2,3,4,5,-1,-1,
6,7,8,9,10,11,-1,-1 });
}
int64_t extract_p6(__m128i *in)
{
union { __m128i m; int64_t i[2]; } t;
expand_p6(in, &t.m);
__builtin_assume(!(t.i[0] >> 48));
return t.i[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] [Bug 40941] New: 4.5 Billion line file use 15GB of RAM
https://bugs.llvm.org/show_bug.cgi?id=40941
Bug ID: 40941
Summary: 4.5 Billion line file use 15GB of RAM
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: j...@jguk.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
GCC handles 4.5 Billion line file ok. Using ~8.64GB of RAM.
Clang 7 goes up to 15GB. Clang 6 rushes up to limit and crashes.
Would be better if it managed to use less RAM than GCC at least.
Any file will do, eg. this test case
// gcc -Wall -o cre_line cre_line.c
#include
int main()
{
printf("int main() {\n");
for(size_t i = 0; i != 45; ++i)
{
printf("\n");
}
printf("#warning msg1\n return 0; }\n\n");
return 0;
}
this is clang 6, sorry clang 8 doesn't appear to be in Ubuntu stable.
$ clang -Wall -o test2 test.c
LLVM ERROR: out of memory
#0 0x7ff82f3640ea llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81e0ea)
#1 0x7ff82f362366 llvm::sys::RunSignalHandlers()
(/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c366)
#2 0x7ff82f36249b (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c49b)
#3 0x7ff8325f4890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#4 0x7ff82dc22e97 gsignal
/build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#5 0x7ff82dc24801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0
#6 0x7ff82f2f712b llvm::report_bad_alloc_error(char const*, bool)
(/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x7b112b)
#7 0x7ff82f30e2a1 llvm::SmallVectorBase::grow_pod(void*, unsigned long,
unsigned long) (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x7c82a1)
#8 0x55825925fc3b (/usr/lib/llvm-6.0/bin/clang+0x46ec3b)
#9 0x55825926004d clang::SourceManager::getLineNumber(clang::FileID,
unsigned int, bool*) const (/usr/lib/llvm-6.0/bin/clang+0x46f04d)
#10 0x558259261dbd
clang::SourceManager::getPresumedLoc(clang::SourceLocation, bool) const
(/usr/lib/llvm-6.0/bin/clang+0x470dbd)
#11 0x55825a98a569 clang::FullSourceLoc::getPresumedLoc(bool) const
(/usr/lib/llvm-6.0/bin/clang+0x1b99569)
#12 0x55825971ef08
clang::DiagnosticRenderer::emitDiagnostic(clang::FullSourceLoc,
clang::DiagnosticsEngine::Level, llvm::StringRef,
llvm::ArrayRef, llvm::ArrayRef,
llvm::PointerUnion)
(/usr/lib/llvm-6.0/bin/clang+0x92df08)
#13 0x5582596c66f5
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
clang::Diagnostic const&) (/usr/lib/llvm-6.0/bin/clang+0x8d56f5)
#14 0x5582592563f0
clang::DiagnosticIDs::EmitDiag(clang::DiagnosticsEngine&,
clang::DiagnosticIDs::Level) const (/usr/lib/llvm-6.0/bin/clang+0x4653f0)
#15 0x558259257f0a
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const
(/usr/lib/llvm-6.0/bin/clang+0x466f0a)
#16 0x558259250963 clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool)
(/usr/lib/llvm-6.0/bin/clang+0x45f963)
#17 0x55825a914435
clang::Preprocessor::HandleUserDiagnosticDirective(clang::Token&, bool)
(/usr/lib/llvm-6.0/bin/clang+0x1b23435)
#18 0x55825a91f412 clang::Preprocessor::HandleDirective(clang::Token&)
(/usr/lib/llvm-6.0/bin/clang+0x1b2e412)
#19 0x55825a8e62ad clang::Lexer::LexTokenInternal(clang::Token&, bool)
(/usr/lib/llvm-6.0/bin/clang+0x1af52ad)
#20 0x55825a959e0f clang::Preprocessor::Lex(clang::Token&)
(/usr/lib/llvm-6.0/bin/clang+0x1b68e0f)
#21 0x558259af6b9e (/usr/lib/llvm-6.0/bin/clang+0xd05b9e)
#22 0x558259b8b97e clang::Parser::ParseCompoundStatementBody(bool)
(/usr/lib/llvm-6.0/bin/clang+0xd9a97e)
#23 0x558259b8e559 clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) (/usr/lib/llvm-6.0/bin/clang+0xd9d559)
#24 0x558259afe94b
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*)
(/usr/lib/llvm-6.0/bin/clang+0xd0d94b)
#25 0x558259b1ffdf clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*)
(/usr/lib/llvm-6.0/bin/clang+0xd2efdf)
#26 0x558259afa0d1
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
(/usr/lib/llvm-6.0/bin/clang+0xd090d1)
#27 0x558259afa729 (/usr/lib/llvm-6.0/bin/clang+0xd09729)
#28 0x558259b009e5
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) (/usr/lib/llvm-6.0/bin/clang+0xd0f9e5)
#29 0x558259b019d9
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&)
(/usr/lib/llvm-6.0/bin/clang+0xd109d9)
#30 0x00
[llvm-bugs] [Bug 40940] clang crashing on __builtin_assume
https://bugs.llvm.org/show_bug.cgi?id=40940 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||r355292 Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sanjay Patel --- Should be fixed with: https://reviews.llvm.org/rL355292 -- 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 40942] New: using ASAN together with ifunc resolvers
https://bugs.llvm.org/show_bug.cgi?id=40942 Bug ID: 40942 Summary: using ASAN together with ifunc resolvers Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ois...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21557 --> https://bugs.llvm.org/attachment.cgi?id=21557&action=edit testcase Using sanitizers appears to lead to problems with ifunc resolvers. Compiling the attached testcase with -fsanitize=address produces an executable that segfaults in the resolver function. Shouldn't the compiler infer proper attributes for the ifunc resolver function? -- 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 13518 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::Preprocessor::PeekAhead
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-03-04 Type: Bug New issue 13518 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::Preprocessor::PeekAhead https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13518 Detailed report: https://oss-fuzz.com/testcase?key=5117789277257728 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: 0x7ffe6f2db998 Crash State: clang::Preprocessor::PeekAhead clang::Parser::ParseOptionalCXXScopeSpecifier clang::Parser::TryAnnotateCXXScopeToken Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5117789277257728 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40943] New: lldb crashes (on linux) when debugging optimized code (-O2)
https://bugs.llvm.org/show_bug.cgi?id=40943
Bug ID: 40943
Summary: lldb crashes (on linux) when debugging optimized code
(-O2)
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: dav...@freebsd.org
CC: apra...@apple.com, lab...@google.com,
llvm-bugs@lists.llvm.org, ztur...@google.com
$ cat outer.c
void optimize_me_not() {}
$ cat abc.c
a;
main() {
optimize_me_not();
{
int b[1];
b[0] = 1;
a = 0;
}
}
$ clang-trunk abc.c /home/davide/reduce-crash/outer.c -g -O2 -o a.out
$
$ cat cmds
b 3
r
kill
quit
$ lldb-trunk a.out -s cmds -b
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) command source -s 0 'cmds'
Executing commands in '/home/davide/reduce-crash/cmds'.
Segmentation fault (core dumped)
$ clang-trunk --version
clang version 9.0.0 (trunk 355281)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
$ lldb-trunk --version
lldb version 9.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk revision
355281)
clang revision 355281
llvm revision 355281
$ uname -a
Linux 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64
x86_64 x86_64 GNU/Linux
--
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 40944] New: Wrong debug info generated at -O1 (-O0 is correct)
https://bugs.llvm.org/show_bug.cgi?id=40944
Bug ID: 40944
Summary: Wrong debug info generated at -O1 (-O0 is correct)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Keywords: wrong-debug
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: llvm-bugs@lists.llvm.org
$ cat 1.c
unsigned char a;
char b = -1;
int main() {
int l_135 = 1102062129;
l_135 = (a = b) | 9;
optimize_me_not();
}
$ cat outer.c
void optimize_me_not() {}
### -O0
* thread #1, name = 'a.out', stop reason = breakpoint 2.1
frame #0: 0x004004a6 a.out`main at 1.c:6:3
3int main() {
4 int l_135 = 1102062129;
5 l_135 = (a = b) | 9;
-> 6 optimize_me_not();
7}
(lldb) frame var
(int) l_135 = 255
### -O1
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0040048d a.out`main at 1.c:6:3
3int main() {
4 int l_135 = 1102062129;
5 l_135 = (a = b) | 9;
-> 6 optimize_me_not();
7}
(lldb) frame var
(lldb) frame var l_135
(int) l_135 = 1102062129
$ clang-trunk --version
clang version 9.0.0 (trunk 355281)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
$ lldb-trunk --version
lldb version 9.0.0 (https://llvm.org/svn/llvm-project/lldb/trunk revision
355281)
clang revision 355281
llvm revision 355281
--
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 40838] Wrong debug info generated at -O1/-O2/-O3 (-O0 is correct)
https://bugs.llvm.org/show_bug.cgi?id=40838 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 40945] New: [Win] Generic lambda causes stack overflow
https://bugs.llvm.org/show_bug.cgi?id=40945
Bug ID: 40945
Summary: [Win] Generic lambda causes stack overflow
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mikhail.strelni...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
This results in infinite recursion on Windows:
inline constexpr auto good = [](auto v) { return !v; };
inline constexpr auto bad = [](auto v) { return !good(v); };
int foo()
{
return 42;
}
int main()
{
auto r = foo();
bad(r);
}
https://godbolt.org/z/TGGHg8
--
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 13519 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: P.first->second == EHScope && "MBB is part of two scopes!"
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2019-03-04 Type: Bug New issue 13519 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: P.first->second == EHScope && "MBB is part of two scopes!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13519 Detailed report: https://oss-fuzz.com/testcase?key=5659782709510144 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: ASSERT Crash Address: Crash State: P.first->second == EHScope && "MBB is part of two scopes!" collectEHScopeMembers llvm::getEHScopeMembership 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=5659782709510144 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
