[llvm-bugs] [Bug 47059] New: crash when completion a symbol
https://bugs.llvm.org/show_bug.cgi?id=47059 Bug ID: 47059 Summary: crash when completion a symbol Product: lldb Version: 11.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: ingo.koe...@ableton.com CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org Created attachment 23832 --> https://bugs.llvm.org/attachment.cgi?id=23832&action=edit crash call stack A crash when completing a symbol on the debugger command line. I am seeing it in lldb 10/11 as released in debian. The attached call stack is from a master build, though. The debugged target has quite a lot of symbols, i guess. best, Ingo -- 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 29156] reproducible assert with -Wdocumentation with clang r279749 with creduce'd test case
https://bugs.llvm.org/show_bug.cgi?id=29156 Mark de Wever changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Mark de Wever --- Thanks for the reply. Not sure about godbolt I recall seeing some clang bugs to be easily reproducible there. But locally I tested with assertions enabled. -- 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 40399] This code snippet takes a very long time to JIT
https://bugs.llvm.org/show_bug.cgi?id=40399 Alexandre Bique changed: 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47060] New: PHI/Aggregate merging
https://bugs.llvm.org/show_bug.cgi?id=47060
Bug ID: 47060
Summary: PHI/Aggregate merging
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
I'm seeing roughly the following as remnants of clang C++ exception handling
on unwind branch:
https://godbolt.org/z/hxMTs6
declare void @something0()
declare void @something1()
declare void @something2()
define {i8*, i32} @square({i8*, i32} %arg0, {i8*, i32} %arg1, {i8*, i32} %arg2,
i1 %cond) {
entry:
br i1 %cond, label %v0, label %v1
v0:
%i121 = extractvalue { i8*, i32 } %arg0, 0
%i122 = extractvalue { i8*, i32 } %arg0, 1
call void @something0()
br label %end
v1:
%i1212 = extractvalue { i8*, i32 } %arg1, 0
%i1222 = extractvalue { i8*, i32 } %arg1, 1
call void @something1()
br label %end
end:
%exn.slot.4 = phi i8* [ %i121, %v0 ], [ %i1212, %v1 ]
%ehselector.slot.4 = phi i32 [ %i122, %v0 ], [ %i1222, %v1 ]
call void @something2()
%lpad.val = insertvalue { i8*, i32 } undef, i8* %exn.slot.4, 0
%lpad.val302 = insertvalue { i8*, i32 } %lpad.val, i32 %ehselector.slot.4, 1
ret {i8*, i32} %lpad.val302
}
All that is redundant and should roughly just be:
https://godbolt.org/z/a6q1Ea
declare void @something0()
declare void @something1()
declare void @something2()
define {i8*, i32} @square({i8*, i32} %arg0, {i8*, i32} %arg1, {i8*, i32} %arg2,
i1 %cond) {
entry:
br i1 %cond, label %v0, label %v1
v0:
call void @something0()
br label %end
v1:
call void @something1()
br label %end
end:
%r = phi {i8*, i32} [ %arg0, %v0 ], [ %arg1, %v1 ]
call void @something2()
ret {i8*, i32} %r
}
If that happens, the resume block of an exception will be recognized as being
empty,
and invoke will be simplified into a call. (not depicted in examples,
see http://reviews.llvm.org/rGe492f0e03b01a5e4ec4b6333abb02d303c3e479e)
I guess, this is a missing fold in instcombine.
Question is: *what* fold is missing? How lax are we okay with it being?
The most simple solution is to look for 'insert of phi', where each incoming
value is an 'extract',
where types of the destination and source match and the lanes match, and just
merge all those extracts
into the block with insert, by forming a PHI for the sources of extracts and
extracting from said new PHI.
This will be rather simple do to.
If that happens for all new inserts, we already know how to fold the rest away:
https://godbolt.org/z/jcY1zo
More complicated (but more proper) solution would be to start looking from the
final insert,
and ensure that we can just replace chain of inserts with the PHI of extract
sources.
Do we want to go with the former or latter approach?
--
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 47061] New: Failure to optimize bit magic to xor+and
https://bugs.llvm.org/show_bug.cgi?id=47061
Bug ID: 47061
Summary: Failure to optimize bit magic to xor+and
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(int a, int b, int c)
{
return (a && !b && c) || (!a && b && c);
}
This can be optimized to `((bool)a ^ (bool)b) & (bool)c`. This transformation
is done by GCC, but not by LLVM.
--
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 47062] New: sphinx docs docs fail to compile with: "duplicate token description of SimpleValue, other instance in TableGen/LangRef"
https://bugs.llvm.org/show_bug.cgi?id=47062
Bug ID: 47062
Summary: sphinx docs docs fail to compile with: "duplicate
token description of SimpleValue, other instance in
TableGen/LangRef"
Product: Documentation
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: General docs
Assignee: unassignedb...@nondot.org
Reporter: tmfin...@gmail.com
CC: llvm-bugs@lists.llvm.org
The llvm that sphinx documentation has some warnings, which are treated as
errors by default.
OS: Ubuntu 20.04..1
sphinx-build: 3.1.2
cmake: 3.16.3
# By default, build will fail #
$ mkdir build; cd build
$ cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_HTML=true ../llvm/
...
$ make docs-llvm-html
...
/usr/local/lib/python3.8/dist-packages/recommonmark/parser.py:75: UserWarning:
Container node skipped: type=document
warn("Container node skipped: type={0}".format(mdnode.t))
...
Warning, treated as error:
/llvm/docs/TableGen/LangRef.rst:270:duplicate token description of SimpleValue,
other instance in TableGen/LangRef
# Set "SPHINX_WARNINGS_AS_ERRORS=false" to allow build to continue #
$ mkdir build; cd build
$ cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_HTML=true
-DSPHINX_WARNINGS_AS_ERRORS=false ../llvm/
$ make docs-llvm-html
/usr/local/lib/python3.8/dist-packages/recommonmark/parser.py:75: UserWarning:
Container node skipped: type=document
warn("Container node skipped: type={0}".format(mdnode.t))
llvm/docs/TableGen/LangRef.rst:270: WARNING: duplicate token description of
SimpleValue, other instance in TableGen/LangRef
llvm/docs/TableGen/LangRef.rst:275: WARNING: duplicate token description of
SimpleValue, other instance in TableGen/LangRef
llvm/docs/TableGen/LangRef.rst:281: WARNING: duplicate token description of
SimpleValue, other instance in TableGen/LangRef
llvm/docs/TableGen/LangRef.rst:286: WARNING: duplicate token description of
SimpleValue, other instance in TableGen/LangRef
llvm/docs/TableGen/LangRef.rst:291: WARNING: duplicate token description of
SimpleValue, other instance in TableGen/LangRef
llvm/docs/TableGen/LangRef.rst:299: WARNING: duplicate token description of
SimpleValue, other instance in TableGen/LangRef
llvm/docs/TableGen/LangRef.rst:306: WARNING: duplicate token description of
SimpleValue, other instance in TableGen/LangRef
llvm/docs/TableGen/LangRef.rst:317: WARNING: duplicate token description of
SimpleValue, other instance in TableGen/LangRef
llvm/docs/TableGen/LangRef.rst:324: WARNING: duplicate token description of
SimpleValue, other instance in TableGen/LangRef
Snippet from "llvm/docs/TableGen/LangRef.rst":
===
.. productionlist::
SimpleValue: `TokInteger`
This represents the numeric value of the integer.
.. productionlist::
SimpleValue: `TokString`+
Multiple adjacent string literals are concatenated like in C/C++. The value
is the concatenation of the strings.
===
Possible related upstream Sphinx issue:
https://github.com/sphinx-doc/sphinx/issues/7427
At least as a short-term fix, SPHINX_WARNINGS_AS_ERRORS could default to false.
--
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 47063] New: Frontend crash msg: Error generating preprocessed source(s)
https://bugs.llvm.org/show_bug.cgi?id=47063 Bug ID: 47063 Summary: Frontend crash msg: Error generating preprocessed source(s) Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: xw111lu...@gmail.com CC: llvm-bugs@lists.llvm.org Since Aug 7. 4a7aedb843a591900b419e86dcf46d9bec4c5526 See compiler crash on miniQMC. https://cdash.qmcpack.org/CDash/viewBuildError.php?buildid=133000 -- 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 33165] Simpify* cannot distribute instructions for simplification due to undef
https://bugs.llvm.org/show_bug.cgi?id=33165 Florian Hahn changed: What|Removed |Added Status|REOPENED|RESOLVED Fixed By Commit(s)||d236e1c7b606c461b5cb8a8a87d ||50ead5d1bcbb9 Resolution|--- |FIXED --- Comment #16 from Florian Hahn --- I think we can consider this closed with https://reviews.llvm.org/rGd236e1c7b606 which prevents optimizations based on undef for NewGVN. -- 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 30995] [META][GVN] NewGVN Integration
https://bugs.llvm.org/show_bug.cgi?id=30995 Bug 30995 depends on bug 33165, which changed state. Bug 33165 Summary: Simpify* cannot distribute instructions for simplification due to undef https://bugs.llvm.org/show_bug.cgi?id=33165 What|Removed |Added Status|REOPENED|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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47064] New: Failure to optimize multiplication by copysign to abs
https://bugs.llvm.org/show_bug.cgi?id=47064
Bug ID: 47064
Summary: Failure to optimize multiplication by copysign to abs
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
float f(float x)
{
return x * copysignf(1.0f, x);
}
This can be optimized to `fabsf(x);`. This transformation is done by GCC, but
not by LLVM. Similar transformations can also be done, such as `x *
copysignf(1.0f, -x)` -> `-fabsf(x)`, and are done by GCC, but not by LLVM.
--
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 47065] New: Failure to optimize out strcmp based on size of string
https://bugs.llvm.org/show_bug.cgi?id=47065
Bug ID: 47065
Summary: Failure to optimize out strcmp based on size of string
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
extern char a[4];
bool f()
{
return strcmp(a, "string") == 0;
}
This can be optimized to `return false`. This transformation is done by GCC,
but not by LLVM.
--
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 46490] New: Failure to optimize sprintf of single string to strcpy instead of using strlen+strcpy
https://bugs.llvm.org/show_bug.cgi?id=46490
Bug ID: 46490
Summary: Failure to optimize sprintf of single string to strcpy
instead of using strlen+strcpy
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: RESOLVED
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
Status: RESOLVED
Resolution: DUPLICATE
void f(char *p, const char *s)
{
sprintf(p, "%s", s);
}
This can be optimized to `strcpy(p, s)`. This transformation is done by GCC.
but not by LLVM, which instead transforms it to `memcpy(p, s, strlen(s) + 1)`
--- Comment #1 from Gabriel Ravier ---
Oops, looks like this somehow got duplicated. Marked as duplicate of
https://bugs.llvm.org/show_bug.cgi?id=46489
*** This bug has been marked as a duplicate of bug 46489 ***
--
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 46489] New: Failure to optimize sprintf of single string to strcpy instead of using strlen+strcpy
https://bugs.llvm.org/show_bug.cgi?id=46489
Bug ID: 46489
Summary: Failure to optimize sprintf of single string to strcpy
instead of using strlen+strcpy
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
void f(char *p, const char *s)
{
sprintf(p, "%s", s);
}
This can be optimized to `strcpy(p, s)`. This transformation is done by GCC.
but not by LLVM, which instead transforms it to `memcpy(p, s, strlen(s) + 1)`
--- Comment #1 from Gabriel Ravier ---
*** Bug 46490 has been marked as a duplicate of this 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47066] New: Use vpermps instead of vpermilps
https://bugs.llvm.org/show_bug.cgi?id=47066
Bug ID: 47066
Summary: Use vpermps instead of vpermilps
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
#define N 16
float f1[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
float f2[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
void foo ()
{
int j;
for (j=0; jhttps://godbolt.org/z/7bToc7
Interestingly, if I changed float to double, Clang matches ICC:
https://godbolt.org/z/h13beq
--
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 46147] Crash on clang_getCursor with lambda expression
https://bugs.llvm.org/show_bug.cgi?id=46147 Aaron Puchert changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||6e089e98a9d5d7d0dda259f68b8 ||ba7f4556cc5b3 Status|NEW |RESOLVED CC||christian.kandeler@theqtcom ||pany.com --- Comment #7 from Aaron Puchert --- Someone fixed the bug in https://reviews.llvm.org/D82629, so I'll close this. The fix will be in Clang 11. (In reply to Richard Smith from comment #6) > I think we got this aspect of the design of lambda ASTs wrong. We shouldn't > ever be tracking capture initializers on the `FieldDecl`, we should instead > always track them as subexpressions of the `LambdaExpr`. I'm still interested in looking into that, let's see if I can find the time. -- 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 24790 in oss-fuzz: llvm:clang-objc-fuzzer: Heap-buffer-overflow in clang::Lexer::getTokenPrefixLength
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 Security_Severity-Medium Reported-2020-08-10 Type: Bug-Security New issue 24790 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Heap-buffer-overflow in clang::Lexer::getTokenPrefixLength https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24790 Detailed Report: https://oss-fuzz.com/testcase?key=6326215485685760 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Heap-buffer-overflow READ 1 Crash Address: 0x7fd2d09dff07 Crash State: clang::Lexer::getTokenPrefixLength clang::StringLiteralParser::CopyStringFragment clang::StringLiteralParser::init Sanitizer: address (ASAN) Recommended Security Severity: Medium Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201910210337:201910220425 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6326215485685760 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 47067] New: automatically recognise the same file extensions as gcc does
https://bugs.llvm.org/show_bug.cgi?id=47067 Bug ID: 47067 Summary: automatically recognise the same file extensions as gcc does Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: dapaixaoc...@gmail.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk clang is supposed to be -- and it mostly is -- compatible with gcc, but it still doesn't recognises all file extensions gcc does out of the box. sure, it obviously recognises common extensions like `*.c`, `*.cpp`, `*.h`, and `*.hpp`, but not some less known file extensions like `.h++` and `.hp`, which gcc does. i think clang should, in order to have better compatibility/parity with gcc. here's all file extensions gcc recognises but clang doesn't: * .hh * .HH * .hp * .HPP * .h++ * .sx * .tcc -- 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 47068] New: Worse zero struct init with = T{} than with memset
https://bugs.llvm.org/show_bug.cgi?id=47068
Bug ID: 47068
Summary: Worse zero struct init with = T{} than with memset
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
class pt {
int x;
int y;
};
class pt2 {
int x;
char y;
};
void foo(pt* s) {
*s = {};
}
void bar(pt2* s) {
*s = {};
}
For foo case, codegen is fine. The padding is problematic here.
Clang:
ret
bar(pt2*):
mov DWORD PTR [rdi], 0
mov BYTE PTR [rdi+4], 0
ret
ICC:
bar(pt2*):
xor eax, eax #18.4
mov QWORD PTR [rdi], rax #18.8
ret
So ideally we should have:
mov QWORD PTR [rdi], 0
define dso_local void @_Z3fooP2pt(%class.pt* nocapture %0) local_unnamed_addr
#0 {
%2 = bitcast %class.pt* %0 to i64*
store i64 0, i64* %2, align 4
ret void
}
define dso_local void @_Z3barP3pt2(%class.pt2* nocapture %0) local_unnamed_addr
#1 {
%2 = bitcast %class.pt2* %0 to i40*
store i40 0, i40* %2, align 4, !tbaa.struct !2
ret void
}
Looking at dumps, SROA to blame?
--
With
class pt3 {
int x;
int y;
char z;
};
Unoptimized:
define dso_local void @_Z3bazP3pt3(%class.pt3* %0) #0 {
%2 = alloca %class.pt3*, align 8
%3 = alloca %class.pt3, align 4
store %class.pt3* %0, %class.pt3** %2, align 8
%4 = bitcast %class.pt3* %3 to i8*
call void @llvm.memset.p0i8.i64(i8* align 4 %4, i8 0, i64 12, i1 false)
%5 = load %class.pt3*, %class.pt3** %2, align 8
%6 = bitcast %class.pt3* %5 to i8*
%7 = bitcast %class.pt3* %3 to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %6, i8* align 4 %7, i64 9,
i1 false)
ret void
}
Optimized:
define dso_local void @_Z3bazP3pt3(%class.pt3* nocapture %0) local_unnamed_addr
#2 {
%2 = bitcast %class.pt3* %0 to i8*
call void @llvm.memset.p0i8.i64(i8* nonnull align 4 dereferenceable(9) %2, i8
0, i64 9, i1 false)
ret void
}
In this case, we are doing bad job when combing memset and memcpy in
MemCpyOptimizer. It should be:
call void @llvm.memset.p0i8.i64(i8* nonnull align 4 dereferenceable(12) %2, i8
0, i64 12, i1 false)
--
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 47069] New: clang-10: error: unable to execute command: Floating point exception (core dumped)
https://bugs.llvm.org/show_bug.cgi?id=47069
Bug ID: 47069
Summary: clang-10: error: unable to execute command: Floating
point exception (core dumped)
Product: new-bugs
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: anbu1024...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
$ cat test.c
extern char x[];
extern char y[];
extern char z[];
void foo ()
{
__atomic_exchange ( & x , & y , & z , & z ) ;
}
---
$ clang --version
clang version 10.0.1
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/tom/Documents/llvm/10.0.1/install-all/bin
---
$ clang test.c
test.c:8:43: warning: incompatible pointer to integer conversion passing 'char
(*)[]' to parameter of type 'int' [-Wint-conversion]
__atomic_exchange ( & x , & y , & z , & z ) ;
^~~
Stack dump:
0. Program arguments:
/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -discard-value-names -main-file-name test.c
-mrelocation-model static -mthread-model posix -mframe-pointer=all -fmath-errno
-fno-rounding-math -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -dwarf-column-info -fno-split-dwarf-inlining
-debugger-tuning=gdb -resource-dir
/home/tom/Documents/llvm/10.0.1/install-all/lib/clang/10.0.1 -internal-isystem
/usr/local/include -internal-isystem
/home/tom/Documents/llvm/10.0.1/install-all/lib/clang/10.0.1/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir
/home/tom/Documents/git/ESmith/FoundBugs2020-11/0-round-2020.08.04_06-45-30
-ferror-limit 19 -fmessage-length 0 -fgnuc-version=4.2.1 -fobjc-runtime=gcc
-fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o /tmp/test-32057a.o
-x c test.c
1. parser at end of file
2. test.c:6:6: LLVM IR generation of declaration 'foo'
3. test.c:6:6: Generating code for declaration 'foo'
#0 0x01883b1a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1883b1a)
#1 0x0188181c llvm::sys::RunSignalHandlers()
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x188181c)
#2 0x01881983 SignalHandler(int)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1881983)
#3 0x7f88cc18b390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x01bdc6c9
clang::CodeGen::CodeGenFunction::EmitAtomicExpr(clang::AtomicExpr*)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1bdc6c9)
#5 0x01d3315a (anonymous
namespace)::ScalarExprEmitter::Visit(clang::Expr*)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1d3315a)
#6 0x01d33a50
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1d33a50)
#7 0x01cea2f7 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr
const*, clang::CodeGen::AggValueSlot, bool)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1cea2f7)
#8 0x01cfd4e5
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1cfd4e5)
#9 0x01ad069d clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt
const*, llvm::ArrayRef)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1ad069d)
#10 0x01ad0dc4
clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt
const&, bool, clang::CodeGen::AggValueSlot)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1ad0dc4)
#11 0x01b0cad8
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1b0cad8)
#12 0x01b18719
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1b18719)
#13 0x01b4a4c4
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl,
llvm::GlobalValue*)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1b4a4c4)
#14 0x01b48324
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*)
(/home/tom/Documents/llvm/10.0.1/install-all/bin/clang-10+0x1b48324)
#15 0x01b489d8
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl)
(/home/tom/Doc
[llvm-bugs] [Bug 47070] New: Bit-wise operators should not be used where logical operators should be used.( & should be &&)（llvm-project/clang-tools-extra/clangd/RIFF.cpp:line 32）
https://bugs.llvm.org/show_bug.cgi?id=47070
Bug ID: 47070
Summary: Bit-wise operators should not be used where logical
operators should be used.( & should be
&&)（llvm-project/clang-tools-extra/clangd/RIFF.cpp:lin
e 32）
Product: clang-tools-extra
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: clangd
Assignee: unassignedclangb...@nondot.org
Reporter: i...@ustchcs.com
CC: llvm-bugs@lists.llvm.org
Bit-wise operators should not be used where logical operators should be used.(
& should be &&)
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/clang-tools-extra/clangd/RIFF.cpp:line 32
32if (Len % 2 & !Stream.empty()) { // Skip padding byte.
33 if (Stream.front())
34return makeError("nonzero padding byte");
35 Stream = Stream.drop_front();
36}
37return std::move(C);
38 }
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-5.2: Bit-wise operators should not be used where logical operators
should be used.( & should be &&))
--
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 47071] New: Bit-wise operators should not be used where logical operators should be used. ( | should be ||)(llvm-project/clang/lib/Parse/ParseStmtAsm.cpp:line 584)
https://bugs.llvm.org/show_bug.cgi?id=47071
Bug ID: 47071
Summary: Bit-wise operators should not be used where logical
operators should be used. ( | should be
||)(llvm-project/clang/lib/Parse/ParseStmtAsm.cpp:line
584)
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: i...@ustchcs.com
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Bit-wise operators should not be used where logical operators should be used. (
| should be ||)
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/clang/lib/Parse/ParseStmtAsm.cpp:line 584
584if (!MAI || !MII | !MOFI || !STI) {
585 Diag(AsmLoc, diag::err_msasm_unable_to_create_target)
586 << "target MC unavailable";
587 return EmptyStmt();
588}
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-5.2: Bit-wise operators should not be used where logical operators
should be used. ( | should be ||))
--
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 47072] New: Expressions with side-effects (including function calls) should not appear in assert().（llvm-project/llvm/utils/TableGen/RegisterInfoEmitter.cpp: line 1291 ）
https://bugs.llvm.org/show_bug.cgi?id=47072
Bug ID: 47072
Summary: Expressions with side-effects (including function
calls) should not appear in
assert().（llvm-project/llvm/utils/TableGen/RegisterInf
oEmitter.cpp: line 1291 ）
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Object
Assignee: unassignedb...@nondot.org
Reporter: i...@ustchcs.com
CC: llvm-bugs@lists.llvm.org
Expressions with side-effects (including function calls) should not appear in
assert().
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/llvm/utils/TableGen/RegisterInfoEmitter.cpp: line 1291
1290for (const auto &RC : RegisterClasses) {
1291 assert(RC.EnumValue == EV++ && "Unexpected order of register
classes");
1292 (void)EV;
1293 const RegSizeInfo &RI = RC.RSI.get(M);
1294 OS << " { " << RI.RegSize << ", " << RI.SpillSize << ", "
1295 << RI.SpillAlignment;
1296 std::vector VTs;
1297 for (const ValueTypeByHwMode &VVT : RC.VTs)
1298VTs.push_back(VVT.get(M).SimpleTy);
1299 OS << ", VTLists+" << VTSeqs.get(VTs) << " },// "
1300 << RC.getName() << '\n';
1301}
1302 }
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-13.2: Expressions with side-effects (including function calls)
should not appear in assert().)
--
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 47072] Expressions with side-effects (including function calls) should not appear in assert().（llvm-project/llvm/utils/TableGen/RegisterInfoEmitter.cpp: line 1291 ）
https://bugs.llvm.org/show_bug.cgi?id=47072 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED CC||craig.top...@gmail.com Fixed By Commit(s)||1675f8a2516d0a6f90744aef106 ||6482ee072bbc8 Resolution|--- |FIXED --- Comment #1 from Craig Topper --- Should be fixed by 1675f8a2516d0a6f90744aef1066482ee072bbc8 -- 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 47073] New: In the for-range statement, erase() should not be used to remove the elements which the loop iterates over.(Potential defects)（llvm-project/llvm/utils/TableGen/CodeGenDAGP
https://bugs.llvm.org/show_bug.cgi?id=47073
Bug ID: 47073
Summary: In the for-range statement, erase() should not be used
to remove the elements which the loop iterates
over.(Potential
defects)（llvm-project/llvm/utils/TableGen/CodeGenDAGPa
tterns.cpp:line 59 and line 771）
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Object
Assignee: unassignedb...@nondot.org
Reporter: i...@ustchcs.com
CC: llvm-bugs@lists.llvm.org
In the for-range statement, erase() should not be used to remove the elements
which the loop iterates over.(Potential defects)
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:line 59
55for (MVT T : S) {
56 if (!P(T))
57continue;
58 Erased = true;
59 S.erase(T);
60}
61return Erased;
62 }
llvm-project/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:line 771
764std::set Ovs;
765for (MVT T : Out) {
766 if (!T.isOverloaded())
767continue;
768
769 Ovs.insert(T);
770 // MachineValueTypeSet allows iteration and erasing.
771 Out.erase(T);
772}
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-13.15: In the for-range statement, erase() should not be used to
remove the elements which the loop iterates over.)
--
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 47074] New: condition_variable::wait_for doesn't wait if duration is large
https://bugs.llvm.org/show_bug.cgi?id=47074
Bug ID: 47074
Summary: condition_variable::wait_for doesn't wait if duration
is large
Product: libc++
Version: 10.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Standards Issues
Assignee: unassignedclangb...@nondot.org
Reporter: g...@bond.id.au
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Created attachment 23833
--> https://bugs.llvm.org/attachment.cgi?id=23833&action=edit
Test cases with sample findings for various versions/OS
The following code should wait forever, but it does not, it returns
immediately:
#include
#include
#include
using namespace std::chrono;
int main() {
std::mutex m;
std::unique_lock l(m);
std::condition_variable cv;
std::cout << "sleeping forever" << std::endl;
cv.wait_for(l, milliseconds::max(), []() { return false; });
std::cout << "returned!" << std::endl;
}
Tested on FreeBSD, Ubuntu16 & MacOS, clang version 6, 8 & 10
Behaviour is somewhat variable, depending on OS and compiler version (at least
for the small sample I have access to). Basically, given a duration past a
certain size (somewhere around 1<<52 units of any duration type), wait_for() no
longer waits at all. On some versions/platforms, the 2-argument wait_for()
does not appear to wait at all, even for small durations.
This looks like some kind of overflow in the duration conversion.
Bug filed under libraries, but problem may be in the compiler intrinsics.
See attached somewhat more detailed test cases and notes on the limits I have
discovered.
--
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 47075] New: then-branch and else-branch of the same if-statement should not be the same.(llvm-project/clang/lib/Basic/Targets/ARM.cpp:line 981<-->988)
https://bugs.llvm.org/show_bug.cgi?id=47075
Bug ID: 47075
Summary: then-branch and else-branch of the same if-statement
should not be the
same.(llvm-project/clang/lib/Basic/Targets/ARM.cpp:lin
e 981<-->988)
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: i...@ustchcs.com
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
then-branch and else-branch of the same if-statement should not be the same.
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/clang/lib/Basic/Targets/ARM.cpp:line 981<-->988
979case 'K':
980 if (isThumb()) {
981if (!supportsThumb2())
982 // FIXME: should check if immediate value can be obtained from
shifting
983 // a value between 0 and 255 left by any amount
984 Info.setRequiresImmediate();
985else
986 // FIXME: should check if immediate value would be valid for a
Thumb2
987 // data-processing instruction when inverted
988 Info.setRequiresImmediate();
989 } else
990// FIXME: should check if immediate value would be valid for an
ARM
991// data-processing instruction when inverted
992Info.setRequiresImmediate();
993 return true;
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-2.1: then-branch and else-branch of the same if-statement should not
be the same.)
--
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 47076] New: then-branch and else-branch of the same if-statement should not be the same.(llvm-project/clang/lib/Basic/Targets/ARM.cpp:line 981<-->988)
https://bugs.llvm.org/show_bug.cgi?id=47076
Bug ID: 47076
Summary: then-branch and else-branch of the same if-statement
should not be the
same.(llvm-project/clang/lib/Basic/Targets/ARM.cpp:lin
e 981<-->988)
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: i...@ustchcs.com
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
then-branch and else-branch of the same if-statement should not be the same.
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/clang/lib/Basic/Targets/ARM.cpp:line 981<-->988
979case 'K':
980 if (isThumb()) {
981if (!supportsThumb2())
982 // FIXME: should check if immediate value can be obtained from
shifting
983 // a value between 0 and 255 left by any amount
984 Info.setRequiresImmediate();
985else
986 // FIXME: should check if immediate value would be valid for a
Thumb2
987 // data-processing instruction when inverted
988 Info.setRequiresImmediate();
989 } else
990// FIXME: should check if immediate value would be valid for an
ARM
991// data-processing instruction when inverted
992Info.setRequiresImmediate();
993 return true;
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-2.1: then-branch and else-branch of the same if-statement should not
be the same.)
--
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 47077] New: Avoid doing equality comparisons between floating expressions.(llvm-project/clang/lib/CodeGen/CGExpr.cpp:line 5228)
https://bugs.llvm.org/show_bug.cgi?id=47077
Bug ID: 47077
Summary: Avoid doing equality comparisons between floating
expressions.(llvm-project/clang/lib/CodeGen/CGExpr.cpp
:line 5228)
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: i...@ustchcs.com
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Avoid doing equality comparisons between floating expressions.
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/clang/lib/CodeGen/CGExpr.cpp:line 5228
5226 void CodeGenFunction::SetFPAccuracy(llvm::Value *Val, float Accuracy) {
5227assert(Val->getType()->isFPOrFPVectorTy());
5228if (Accuracy == 0.0 || !isa(Val))
5229 return;
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-5.15: Avoid doing equality comparisons between floating
expressions.)
--
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 47078] New: Avoid doing equality comparisons between floating expressions.(llvm-project/clang-tools-extra/clangd/index/dex/Iterator.cpp:line 427)
https://bugs.llvm.org/show_bug.cgi?id=47078
Bug ID: 47078
Summary: Avoid doing equality comparisons between floating
expressions.(llvm-project/clang-tools-extra/clangd/ind
ex/dex/Iterator.cpp:line 427)
Product: clang-tools-extra
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: clangd
Assignee: unassignedclangb...@nondot.org
Reporter: i...@ustchcs.com
CC: llvm-bugs@lists.llvm.org
Avoid doing equality comparisons between floating expressions.
commit e3546c78cabfbf670391a57766872f0a8e28a423
llvm-project/clang-tools-extra/clangd/index/dex/Iterator.cpp:line 427
425 std::unique_ptr Corpus::boost(std::unique_ptr
Child,
426 float Factor) const {
427if (Factor == 1)
428 return Child;
429if (Child->kind() == Iterator::Kind::False)
430 return Child;
431return std::make_unique(std::move(Child), Factor);
432 }
Reported by: Ustchcs Toolsets Bugfinder
(bugfinder-5.15: Avoid doing equality comparisons between floating
expressions.)
--
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 47076] then-branch and else-branch of the same if-statement should not be the same.(llvm-project/clang/lib/Basic/Targets/ARM.cpp:line 981<-->988)
https://bugs.llvm.org/show_bug.cgi?id=47076 Eli Friedman changed: What|Removed |Added Resolution|--- |DUPLICATE CC||efrie...@quicinc.com Status|NEW |RESOLVED --- Comment #1 from Eli Friedman --- *** This bug has been marked as a duplicate of bug 47075 *** -- 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
