[llvm-bugs] Issue 18906 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.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 OS-Linux Proj-llvm Reported-2019-11-13 Type: Bug New issue 18906 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18906 Detailed Report: https://oss-fuzz.com/testcase?key=5641149917691904 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal isTopLevelPadForMSVC llvm::calculateSEHStateNumbers 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=5641149917691904 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing 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. Comments on individual Monorail issues are not monitored. -- 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 43987] New: PowerPC64: clang crash during MySQL 5.6 compilation
https://bugs.llvm.org/show_bug.cgi?id=43987 Bug ID: 43987 Summary: PowerPC64: clang crash during MySQL 5.6 compilation Product: clang Version: 9.0 Hardware: Other OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: C Assignee: unassignedclangb...@nondot.org Reporter: pku...@anongoth.pl CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22805 --> https://bugs.llvm.org/attachment.cgi?id=22805&action=edit crash data The following crash happens when compiling MySQL 5.6.45 on FreeBSD/powerpc64-elfv2: Wrong types for attribute: inalloca nest noalias nocapture nonnull readnone readonly signext sret zeroext byval dereferenceable(1) dereferenceable_or_null(1) %call = call signext i32 @my_atomic_add32(i32* %9, %union.U_32 signext %10) Wrong types for attribute: inalloca nest noalias nocapture nonnull readnone readonly signext sret zeroext byval dereferenceable(1) dereferenceable_or_null(1) %call20 = call signext i32 @my_atomic_cas32(i32* %26, i32* %28, %union.U_32 signext %29) in function _lf_pinbox_get_pins fatal error: error in backend: Broken function found, compilation aborted! Preprocessed source and the running script are attached. -- 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 43988] New: formatting broken when using inline if inside of templates in class initializer list
https://bugs.llvm.org/show_bug.cgi?id=43988
Bug ID: 43988
Summary: formatting broken when using inline if inside of
templates in class initializer list
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: steffen.seck...@tum.de
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
clang-format gets confused when dealing with inline ifs in templates within
class initializer lists.
The behavior got worse with clang-format-9, as the indentation of the following
entries in the initializer list are wrongly indented.
==using braces and clang-format-9==
template class Base { Base(int i){}; };
template class Derived : public Base {
public:
Derived()
: Base<(someBool ? 2 : 3)>{35}, _someMember{3}, _someMember2{2}, //
<-- desired indentation
_someMember3{2} {}
private:
int _someMember;
int _someMember2;
int _someMember3;
};
==without braces and clang-format-9==
template class Base { Base(int i){}; };
template class Derived : public Base {
public:
Derived()
: Base < someBool
? 2
: 3 > {35},
_someMember{3}, _someMember2{2}, _someMember3{2} {}
// <-- wrong indentation
private:
int _someMember;
int _someMember2;
int _someMember3;
};
==without braces and clang-format-8==
template class Base { Base(int i){}; };
template class Derived : public Base {
public:
Derived()
: Base < someBool
? 2
: 3 > {35},
_someMember{3}, _someMember2{2}, _someMember3{2} {}
// <-- slightly better indentation, but still wrong.
private:
int _someMember;
int _someMember2;
int _someMember3;
};
clang-format-9 version:
9.0.1-+2019110812332108004e858e4ac00-1~exp1~20191108215024.72
clang-format-8 version: 8.0.1-svn369350-1~exp1~20190820121219.79
--
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 43989] New: libclang_rt.fuzzer-x86_64.a is missing in libclang-common-dev Debian/Ubuntu package
https://bugs.llvm.org/show_bug.cgi?id=43989 Bug ID: 43989 Summary: libclang_rt.fuzzer-x86_64.a is missing in libclang-common-dev Debian/Ubuntu package Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: chf...@gmail.com CC: llvm-bugs@lists.llvm.org In release 9, the libclang_rt.fuzzer-x86_64.a is available in libclang-common-9-dev package so the command clang fuzz.cpp -fsanitize=fuzzer works out of the box In the version 10, the fuzzer libraries are missing. I'm getting clang++-10 fuzz.cpp -fsanitize=fuzzer /usr/bin/ld: cannot find /usr/lib/llvm-10/lib/clang/10.0.0/lib/linux/libclang_rt.fuzzer-x86_64.a: No such file or directory clang: error: linker command failed with exit code 1 (use -v to see invocation) -- 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 43990] New: Incorrect error on static_assert expression
https://bugs.llvm.org/show_bug.cgi?id=43990
Bug ID: 43990
Summary: Incorrect error on static_assert expression
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: pk...@outlook.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 22806
--> https://bugs.llvm.org/attachment.cgi?id=22806&action=edit
Code to produce the issue described.
The C++11 code below produces a compilation error stating that the
static_assert expression is not an integral constant expression. GCC trunk
compiles this. Commenting-out the static assert removes the error.
template
constexpr bool bar(T &) { return true; }
template
constexpr bool foo(T &x) { static_assert(bar(x),""); return bar(x); }
int main(int argc, char *argv[])
{
int i;
constexpr bool x = foo(i);
return 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 43991] New: Don't assume that there is only one SHT_SYMTAB_SHNDX section
https://bugs.llvm.org/show_bug.cgi?id=43991 Bug ID: 43991 Summary: Don't assume that there is only one SHT_SYMTAB_SHNDX section Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org llvm-readobj/elf incorrectly assumes taht there is a maximum of one SHT_SYMTAB_SHNDX section. This section is then used any time the section index for a symbol needs to be looked up. This is incorrect. The SHT_SYMTAB_SHNDX sections are paired up with symbol tables via their sh_link fields. In practice, it's relatively unlikely to see two SHT_SYMTAB_SHNDX sections, but it matters in the unlikely case of a dynamic object having many sections. In such a case, there should be two SHT_SYMTAB_SHNDX sections, one for the static symbol table and the other for the dynamic symbol table, with corresponding sh_link fields set (the dynamic one is also referenced by the DT_SYMTAB_SHNDX dynamic tag). Due to their nature, these sections cannot be combined into one. There are cases in the llvm-readobj code where a dynamic symbol could end up looking up the section index in the wrong table, so this should be 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] Issue 16605 in oss-fuzz: llvm:llvm-isel-fuzzer--x86_64-O2: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #2 on issue 16605 by sheriff...@chromium.org: llvm:llvm-isel-fuzzer--x86_64-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16605#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 42344] Add an option to disable inline line tables similar to MSVC /Zo-
https://bugs.llvm.org/show_bug.cgi?id=42344 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Reid Kleckner --- (In reply to Amy Huang from comment #5) > Disabling inline line tables is done here > https://github.com/llvm/llvm-project/commit/ > 6d03890384517919a3ba7fe4c35535425f278f89 > and it gets rid of inline debug info in the inliner. Thanks! Marking this 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 32254] invalid x86_64 Reference Kind
https://bugs.llvm.org/show_bug.cgi?id=32254 Andrew Kelley changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Andrew Kelley --- This bug was fixed by https://github.com/llvm/llvm-project/commit/91864f82c7d7bd1a151fdfd076a3a67a2893b868 -- 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 43994] New: BPF code generation emits "|" instead of "+", causing problems for BPF verifier
https://bugs.llvm.org/show_bug.cgi?id=43994 Bug ID: 43994 Summary: BPF code generation emits "|" instead of "+", causing problems for BPF verifier Product: clang Version: 9.0 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: eugene@oracle.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 22808 --> https://bugs.llvm.org/attachment.cgi?id=22808&action=edit C code, run script, generated BPF code Here is an issue with clang/LLVM's BPF code generation. Technically, the generated code is not wrong, but it causes an unnecessary problem for the BPF verifier. Consider the C source code BPF.c. The generated BPF code can be seen in objdump.txt and verifier.txt. Here are the C and BPF code, redacted for readability and shown side-by-side: BPF.c objdump.txt/verifier.txt = u64 dest = -1; *(u64 *)(r10-24) = -1 u64 offset; u64 garbage = 0x3141592654; *(u64 *)(r10- 8) = 0x3141592654 // set offset to some mystery value r1 = r10-16 bpf_probe_read(&offset, r2 = 8 sizeof (offset), &garbage); r3 = r10- 8 call bpf_probe_read#4 // clip offset to be offset within dest r1 = *(u64 *)(r10 - 16) offset &= sizeof (dest) - 1;r1 &= 7 *(u64 *)(r10 - 16) = r1 // copy byte to mystery offset in dest r2 = r10-24 bpf_probe_read(((u64) &dest) + offset, r1 |= r2 ==> PROBLEM! 1, &garbage); r2 = 1 r3 = r10- 8 call bpf_probe_read#4 return 0; r0 = 0 exit To compute ((u64)&dest)+offset, the generated BPF uses "offset |= &dest". The replacement of "+" with "|" presumably gives the correct result in this particular case, but then the BPF verifier complains: R1 bitwise operator |= on pointer prohibited That is, the replacement of "+" with "|" causes this correct program to be rejected unnecessarily by the BPF verifier. This problem occurred on a system with an upstream kernel with % uname -r 5.3.0+ with clang/LLVM built from source: % clang --version clang version 9.0.0 (trunk 364493) [...] -- 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 43995] New: Segfault during parsing of invalid template code
https://bugs.llvm.org/show_bug.cgi?id=43995 Bug ID: 43995 Summary: Segfault during parsing of invalid template code Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: lennart.br...@posteo.de CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 22809 --> https://bugs.llvm.org/attachment.cgi?id=22809&action=edit stack trace, preprocessed source, and run script Hi there, while I was trying to minimize a reproducer for a different bug, I ended up with a piece of code that lets clang's parser segfault. Version: clang version 10.0.0 (trunk) (llvm/trunk 375507) See attachment for stack trace, preprocessed source, and run script. Best Lennart -- 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 43948] [SLPVectorizer] miscompile of reduction with extra uses
https://bugs.llvm.org/show_bug.cgi?id=43948 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||a3e61946c5bd Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sanjay Patel --- Hopefully, fixed here: https://reviews.llvm.org/rGa3e61946c5bd -- 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 43996] New: bad code produced... sometimes??
https://bugs.llvm.org/show_bug.cgi?id=43996 Bug ID: 43996 Summary: bad code produced... sometimes?? Product: clang Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: st...@yandex.ru CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22810 --> https://bugs.llvm.org/attachment.cgi?id=22810&action=edit test case, you must see it to believe Well, this is probably the weirdest bug I've ever seen. The attached is a fully automated test-case (without which no one would even try it out, as people will likely think I am crazy). The thing is, if you compile this test-case _multiple times_, sometimes you get the bad binary that will crash! No no, read on, I have a proof! :) The script that I created, will run the compilation in a loop. It will also record the generated asm from every compilation cycle. As soon as the bad build is detected, the script will output the asm diff between good and bad builds, and will stop execution. If the problem happens on the first loop, then no diff is printed for obvious reasons, and you'll need to restart the test to get the diff output. And yes, I tested this on multiple machines. -- 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 43997] New: [LLD/ELF] LLD change inflates elf binary size when linked with no-rosegment
https://bugs.llvm.org/show_bug.cgi?id=43997 Bug ID: 43997 Summary: [LLD/ELF] LLD change inflates elf binary size when linked with no-rosegment Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: de...@google.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org Created attachment 22811 --> https://bugs.llvm.org/attachment.cgi?id=22811&action=edit qemu reproducible tarball The problem was discovered when the elf binary size of some packages after llvm toolchain update has drastically increased. The binaries were built with ld.lld --no-rosegment. For example qemu_x86_64 elf binary size changed from 4MB to 1.6GB. After bisection I located the commit which introduced the problem: 06bb7dfbd445fe928b0ae0263ba9df1acd861c41 [ELF] Map the ELF header at imageBase Here is the difference of readelf before and after the commit: BEFORE: - $ readelf --sections --wide qemu-x86_64 Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS6000 001000 245dc6 00 AX 0 0 32 AFTER: - $ readelf --sections qemu-x86_64 Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS6000 5fe0 245dc6 00 AX 0 0 32 Steps to reproduce: tar -axf qemu.tar && cd qemu ld.lld @response.txt ls -lh qemu-x86_64 readelf --sections --wide qemu-x86_64 -- 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 43990] Incorrect error on static_assert expression
https://bugs.llvm.org/show_bug.cgi?id=43990 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- This is a GCC bug (though one we see filed quite a lot; the language rules seem to not match people's intuition here). The evaluation semantics of the expression 'x' (because it's of reference type) involve locating the object that the reference binds to, which can't be done in this case because we don't know the value of the function parameter 'x'. So the evaluation of the static_assert condition is non-constant, which is invalid. In case you're interested, this is the language rule that's violated here: http://eel.is/c++draft/expr.const#4.12 -- 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 43998] New: Poor performance of OpenMP distribute construct
https://bugs.llvm.org/show_bug.cgi?id=43998
Bug ID: 43998
Summary: Poor performance of OpenMP distribute construct
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: csda...@lbl.gov
CC: llvm-bugs@lists.llvm.org
The OpenMP distribute construct performs significantly worse than manually
dividing loop iterations between thread teams. Please see the test program
below which shows the performance of both methods on a system with Intel
Skylake CPUs and NVIDIA V100 GPUs. The performance difference is ~700x. I am
using LLVM/Clang from Nov 11 2019, although there is the same issue when using
LLVM/Clang from Aug 28 2019.
$ make
clang++ -std=c++11 -Ofast -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -o
test.exe test.cpp
$ srun -n 1 ./test.exe
Number of sites = 1048576
Executing 100 iterations
Time w/distribute = 2.087 seconds
Time workaround = 0.003 seconds
$ cat test.cpp
#include
#include
#include
#include
typedef std::chrono::system_clock Clock;
#define ITERATIONS 100
#define TOTAL_SITES 1048576
int main(int argc, char *argv[])
{
int total_sites = TOTAL_SITES;
printf("Number of sites = %d\n", total_sites);
printf("Executing %d iterations\n", ITERATIONS);
auto tstart = Clock::now();
for (int iters=0; iters(Clock::now()-tstart).count()
/ 1.0E6;
printf("Time w/distribute = %.3f seconds\n", sec);
tstart = Clock::now();
for (int iters=0; iters total_sites) istart = total_sites;
int iend = istart + sites_per_team;
if (iend > total_sites) iend = total_sites;
/* This is the total_sites loop manually chopped up */
for (int i = istart; i < iend; ++i) {
;
}
}
}
sec =
std::chrono::duration_cast(Clock::now()-tstart).count()
/ 1.0E6;
printf("Time workaround = %.3f seconds\n", sec);
}
The performance of the distribute construct can be improved by reducing the
number of teams using the num_teams clause. However, the performance is never
competitive compared to manually dividing loop iterations between thread teams.
Thanks,
Chris
--
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 43081] clang v8 crash during optimization pass
https://bugs.llvm.org/show_bug.cgi?id=43081 Dimitry Andric changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #8 from Dimitry Andric --- Fixed by llvmorg-10-init-9808-g3db6783d8a7: https://github.com/llvm/llvm-project/commit/3db6783d8a7 -- 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
