[llvm-bugs] [Bug 40519] New: clang++ fails to compile SFINAE member function overloaded with using-imported fallback function from base class
https://bugs.llvm.org/show_bug.cgi?id=40519
Bug ID: 40519
Summary: clang++ fails to compile SFINAE member function
overloaded with using-imported fallback function from
base class
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: hrog...@fusionsystems.org
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
When overloading an SFINAE-qualified member function with a using-imported
templated member function from a base class, the compiler fails to correctly
resolve the overload (the base class member function is supposed to be a
fallback).
The following code compiles with gcc since 7.1, but not clang 7.0.1. Note: msvc
19.16, icc 19.0.1 (latest on godbolt.org) also fail to compile this.
#include
template struct A;
struct B { };
template struct A { typedef R T; };
struct C {
template
void foo(T) { puts("Hello World"); }
};
struct D : public C {
using C::foo;
template
typename A::T foo(T) { puts("Goodbye World"); }
};
struct E { };
int main()
{
D{}.foo(E{});
D{}.foo(B{});
}
--
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 40520] New: clang-format BreakBeforeBraces: Custom and IndentBraces: true
https://bugs.llvm.org/show_bug.cgi?id=40520
Bug ID: 40520
Summary: clang-format BreakBeforeBraces: Custom and
IndentBraces: true
Product: clang
Version: 5.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: fedor.birju...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
I tried these settings:
BreakBeforeBraces: Custom
BraceWrapping:
IndentBraces: true
Expecting to see something like this:
void func()
{
// ...
}
class X
{
public:
// ...
}
namespace Y
{
namespace Z
{
// ...
}
}
for (;;)
{
// ...
}
if ()
{
// ...
}
else
{
// ...
}
But it did not work as expected.
Any ideas?
Tried that for all versions >=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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40521] New: Infinite loop in DAG combining
https://bugs.llvm.org/show_bug.cgi?id=40521 Bug ID: 40521 Summary: Infinite loop in DAG combining Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 21403 --> https://bugs.llvm.org/attachment.cgi?id=21403&action=edit reproducer Reproduce with llc bbi-23735.ll -o - With -debug we see some repeated printouts: Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36> t126:1, t129, FrameIndex:i64<1>, undef:i64 Combining: t126: i64,ch = load<(dereferenceable load 4 from %ir.f, align 8), zext from i32> t0, FrameIndex:i64<0>, undef:i64 Combining: t129: i64 = and t127, Constant:i64<4095> Creating new node: t130: i32 = truncate t126 Creating constant: t131: i32 = Constant<4095> Creating new node: t132: i32 = srl t130, Constant:i8<15> Creating new node: t133: i32 = and t132, Constant:i32<4095> Creating new node: t134: i64 = zero_extend t133 ... into: t134: i64 = zero_extend t133 Combining: t126: i64,ch = load<(dereferenceable load 4 from %ir.f, align 8), zext from i32> t0, FrameIndex:i64<0>, undef:i64 Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36> t126:1, t134, FrameIndex:i64<1>, undef:i64 Combining: t134: i64 = zero_extend t133 Combining: t133: i32 = and t132, Constant:i32<4095> Combining: t131: i32 = Constant<4095> Combining: t132: i32 = srl t130, Constant:i8<15> Combining: t130: i32 = truncate t126 Creating new node: t135: i32,ch = load<(dereferenceable load 4 from %ir.f, align 8)> t0, FrameIndex:i64<0>, undef:i64 ... into: t135: i32,ch = load<(dereferenceable load 4 from %ir.f, align 8)> t0, FrameIndex:i64<0>, undef:i64 Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36> t135:1, t134, FrameIndex:i64<1>, undef:i64 Combining: t134: i64 = zero_extend t133 Creating new node: t136: i64,ch = load<(dereferenceable load 4 from %ir.f, align 8), zext from i32> t0, FrameIndex:i64<0>, undef:i64 Creating new node: t137: i64 = srl t136, Constant:i8<15> Creating constant: t138: i64 = Constant<4095> Creating new node: t139: i64 = and t137, Constant:i64<4095> Replacing.1 t134: i64 = zero_extend t133 With: t139: i64 = and t137, Constant:i64<4095> and 0 other values Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36> t136:1, t139, FrameIndex:i64<1>, undef:i64 Combining: t136: i64,ch = load<(dereferenceable load 4 from %ir.f, align 8), zext from i32> t0, FrameIndex:i64<0>, undef:i64 Combining: t139: i64 = and t137, Constant:i64<4095> Creating new node: t140: i32 = truncate t136 Creating constant: t141: i32 = Constant<4095> Creating new node: t142: i32 = srl t140, Constant:i8<15> Creating new node: t143: i32 = and t142, Constant:i32<4095> Creating new node: t144: i64 = zero_extend t143 ... into: t144: i64 = zero_extend t143 Combining: t136: i64,ch = load<(dereferenceable load 4 from %ir.f, align 8), zext from i32> t0, FrameIndex:i64<0>, undef:i64 Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36> t136:1, t144, FrameIndex:i64<1>, undef:i64 This starts happening with r329516 but I've no idea if that commit is really to blame or if it just exposes some old problem. r329516: [DAGCombiner] Fold (zext (and/or/xor (shl/shr (load x), cst), cst)) In our real world application, we found the following optimization is missed in DAGCombiner (zext (and/or/xor (shl/shr (load x), cst), cst)) -> (and/or/xor (shl/shr (zextload x), (zext cst)), (zext cst)) If the user of original zext is an add, it may enable further lea optimization on x86. This patch add a new function CombineZExtLogicopShiftLoad to do this optimization. Differential Revision: https://reviews.llvm.org/D44402 -- 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 40522] New: [SLPVectorizer] Failure to use vector store as a seed point
https://bugs.llvm.org/show_bug.cgi?id=40522
Bug ID: 40522
Summary: [SLPVectorizer] Failure to use vector store as a seed
point
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: a.bat...@hotmail.com, llvm-bugs@lists.llvm.org,
spatel+l...@rotateright.com
https://godbolt.org/z/6NyXmr
void test1(float a, float b, float c, float d, int *p) {
int4 result = (int4) { (int) a, (int) b, (int) c, (int) d };
*p++ = result[0];
*p++ = result[1];
*p++ = result[2];
*p++ = result[3];
}
void test1_vec(float a, float b, float c, float d, int4 *p) {
int4 result = (int4) { (int) a, (int) b, (int) c, (int) d };
*p = result;
}
We will vectorize the first variant but not the second.
--
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 40523] New: [DebugInfo@O2]: LLVM ERROR: Broken function found, while removing Debug Intrinsics
https://bugs.llvm.org/show_bug.cgi?id=40523 Bug ID: 40523 Summary: [DebugInfo@O2]: LLVM ERROR: Broken function found, while removing Debug Intrinsics Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: international.phan...@gmail.com CC: apra...@apple.com, chackz0...@gmail.com, greg.bedw...@sony.com, htmldevelo...@gmail.com, jeremy.morse.l...@gmail.com, llvm-bugs@lists.llvm.org, mikael.hol...@ericsson.com, paul.robin...@am.sony.com, v...@apple.com Created attachment 21404 --> https://bugs.llvm.org/attachment.cgi?id=21404&action=edit Test case that reproduces the crash. Given the attached test case and using the following command line: opt -S -o - bbi-23595.ll -simplifycfg you get llvm.dbg.label intrinsic requires a !dbg attachment call void @llvm.dbg.label(metadata !1) label %entry i16 ()* @_Z7test_itv in function _Z7test_itv LLVM ERROR: Broken function found, compilation aborted! -- 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 40521] Infinite loop in DAG combining
https://bugs.llvm.org/show_bug.cgi?id=40521 Mikael Holmén changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Mikael Holmén --- Probably the same problem as https://bugs.llvm.org/show_bug.cgi?id=39098 *** This bug has been marked as a duplicate of bug 39098 *** -- 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 12781 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: N->getOpcode() != ISD::DELETED_NODE && "Node was deleted but visit returned NULL
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@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-01-30 Type: Bug New issue 12781 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: N->getOpcode() != ISD::DELETED_NODE && "Node was deleted but visit returned NULL https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12781 Detailed report: https://oss-fuzz.com/testcase?key=5635146621911040 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--wasm32-O2 Fuzz target binary: llvm-isel-fuzzer--wasm32-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: N->getOpcode() != ISD::DELETED_NODE && "Node was deleted but visit returned NULL DAGCombiner::combine llvm::SelectionDAG::Combine Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201810170227:20181623 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5635146621911040 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 40524] New: INVOKEing pointer to const&-qualified member function with rvalue results in an error
https://bugs.llvm.org/show_bug.cgi?id=40524
Bug ID: 40524
Summary: INVOKEing pointer to const&-qualified member function
with rvalue results in an error
Product: libc++
Version: unspecified
Hardware: PC
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: lu...@math.hu-berlin.de
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Following code is rejected:
#include
struct S
{
void foo() const&;
};
void bar()
{
(S{}.*&S::foo)(); // OK
std::mem_fn(&S::foo)(S{}); // Error
}
Bullet point 1.1 of [func.require] reads (citing N4296)
Define INVOKE (f, t1, t2, ..., tN) as follows:
(t1.*f)(t2, ..., tN) when f is a pointer to a member function of a class T and
t1 is an object of
type T or a reference to an object of type T or a reference to an object of a
type derived from T;
I assume the problem is that T is substituted with S const& when applicability
of that bullet point is checked, but S const& is not a class, so T must be
substituted with S.
--
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 40525] New: Incorrect encoding of DWARF 5 loc list entry
https://bugs.llvm.org/show_bug.cgi?id=40525 Bug ID: 40525 Summary: Incorrect encoding of DWARF 5 loc list entry Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: paul_robin...@playstation.sony.com CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com Report from Philip Craig, philipjcr...@gmail.com, quoted here: I've been working on DWARF v5 parsing in another project, and I was testing on LLVM's output, and I noticed a bug in the location list entry. See section 2.6.2 of the v5 standard: "A counted location description operand consists of an unsigned ULEB integer giving the length of the location description (see Section 2.6.1 on page 39) that immediately follows." but LLVM encodes the length as a 16 bit int here: https://github.com/llvm-mirror/llvm/blob/c35ddbd43e57090947d74b7670d53ee1106c50f2/lib/CodeGen/AsmPrinter/DwarfDebug.cpp#L1981 This function is correct for DWARF v4, but needs updating for entries in .debug_loclists. llvm-dwarfdump will need fixing to parse it correctly too. I've checked that gcc emits a ULEB and gdb parses it as a ULEB. -- 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 40526] New: dependence analysis degradations due to removal of GEP analysis in D35430
https://bugs.llvm.org/show_bug.cgi?id=40526
Bug ID: 40526
Summary: dependence analysis degradations due to removal of GEP
analysis in D35430
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: andreas.hom...@nxp.com
CC: llvm-bugs@lists.llvm.org
We are currently moving a project from LLVM4 to LLVM7 and found major
degradations in some of our benchmarks that are due to the removal of the GEP
based da analysis by D35430.
The now purely SCEV based da pass is no longer able to handle this case:
#define N 200
int a[N][N];
void test(void)
{
for (int i = 0; i < N; ++i) {
for (int j = i + 1; j < N; ++j) {
a[i][j] = a[j][i];
}
}
}
With LLVM4 we get
$ clang -S -emit-llvm -O1 test.c
$ opt -analyze -da test.ll
Printing analysis 'Dependence Analysis' for function 'test':
da analyze - none!
da analyze - none!
da analyze - none!
With LLVM7 the above incorrectly prints:
da analyze -
input [* *]!
anti [<= *|<]!
none!
So, it fails to classify the first and second dependence correctly. The first
is for ld/ld, so it is not that important, but the second is for the ld/st
dependency.
The LLVM4 GEP based analysis for the ld/st uses this:
da analyze - common nesting levels = 2
maximum nesting levels = 2
SrcPtrSCEV = @a
DstPtrSCEV = @a
using GEPs
subscript 0
src = 0
dst = 0
class = 0
loops = {}
subscript 1
src = {{1,+,1}<%for.body>,+,1}<%for.body4>
dst = {0,+,1}<%for.body>
class = 3
loops = {1 2}
subscript 2
src = {0,+,1}<%for.body>
dst = {{1,+,1}<%for.body>,+,1}<%for.body4>
class = 3
loops = {1 2}
Separable = {0}
Coupled = {2}
and Banerjee can handle this.
With LLVM7 we only get a single SCEV subscript:
da analyze - common nesting levels = 2
maximum nesting levels = 2
SrcPtrSCEV = @a
DstPtrSCEV = @a
using SCEVs
SrcSCEV = {{(800 + @a),+,804}<%for.body>,+,800}<%for.body4>
DstSCEV = {{(4 + @a),+,804}<%for.body>,+,4}<%for.body4>
subscript 0
src = {{(800 + @a),+,804}<%for.body>,+,800}<%for.body4>
dst = {{(4 + @a),+,804}<%for.body>,+,4}<%for.body4>
class = 3
loops = {1 2}
Separable = {0}
Coupled = {}
Which is not handled by da’s delinearization or by any of the following da
analysis methods.
The GEP based analysis was removed by D35430, but I am not sure what this
removal really fixes. It also seems to break other cases that previously
worked, e.g., for loop interchange. The Coupled.ll in this review has two
dimensions in the code, so I am not seeing why there should be only one
dimension. Also, the new result, for
;; for (long int i = 0; i < 50; i++) {
;;A[i][3*i - 6] = i;
;;*B++ = A[i][i];
define void @couple6([100 x i32]* %A, i32* %B, i32 %n) nounwind uwtable ssp {
entry:
br label %for.body
; CHECK-LABEL: couple6
; CHECK: da analyze - none!
; CHECK: da analyze - flow [<]!
; CHECK: da analyze - confused!
; CHECK: da analyze - none!
; CHECK: da analyze - confused!
; CHECK: da analyze - none!
is not correct either, the load/store intersect at i==3, so ideally this would
be reported as splitable.
The GEPs usually come from a compiler’s FE and are a direct representation of
the source code. Just not using this seems to be a mistake, especially since
there is currently no mechanism (e.g., da’s de-linearization) to recover this
for trivial and common cases like my example above.
I would propose to undo this commit and look for another way to fix this that
will not remove the GEP part.
--
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 40527] New: Missed opportunity to remove a dead store
https://bugs.llvm.org/show_bug.cgi?id=40527
Bug ID: 40527
Summary: Missed opportunity to remove a dead store
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: gli...@google.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
When compiling the following code:
void alloc_sock(int *err);
int try_send();
int send(int len) {
int err;
if (len) {
err = -1;
alloc_sock(&err);
err = try_send();
}
return -1;
}
with
$ clang -O2 -g -ftrivial-auto-var-init=pattern
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -c t.c
Clang produces an extra store of $0x to |err|, which is introduced by
the -ftrivial-auto-var-init and not removed by other optimizations in the
pipeline:
$ objdump -d t.o
:
0: 50 push %rax
1: c7 44 24 04 aa aa aamovl $0x,0x4(%rsp)
8: aa
9: 85 ff test %edi,%edi
b: 74 1d je 2a
d: c7 44 24 04 ff ff ffmovl $0x,0x4(%rsp)
14: ff
15: 48 8d 7c 24 04 lea0x4(%rsp),%rdi
1a: e8 00 00 00 00 callq 1f
1f: 31 c0 xor%eax,%eax
21: e8 00 00 00 00 callq 26
26: 89 44 24 04 mov%eax,0x4(%rsp)
2a: b8 ff ff ff ff mov$0x,%eax
2f: 59 pop%rcx
30: c3 retq
As noted by JF Bastien here: https://reviews.llvm.org/D54604, "Seems like the
optimizer should sink the store enough that it appears only once on each path."
--
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 40528] New: [DTU] DomTreeUpdater's Eager strategy fails to update DomTree, Lazy strategy works OK
https://bugs.llvm.org/show_bug.cgi?id=40528
Bug ID: 40528
Summary: [DTU] DomTreeUpdater's Eager strategy fails to update
DomTree, Lazy strategy works OK
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: max.kazant...@azul.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
I wrote a unit test https://reviews.llvm.org/D57448 which demonstrates that DTU
with Eager strategy fails to update the DomTree properly. Apply the patch and
run unit tests. The failure looks like:
1 FAILED TEST
DominatorTree is different than a freshly computed one!
Current:
=
Inorder Dominator Tree: DFSNumbers invalid: 0 slow queries.
[1] %BB {4294967295,4294967295} [0]
[2] %BB1 {4294967295,4294967295} [1]
[3] %BB17 {4294967295,4294967295} [2]
[3] %BB2 {4294967295,4294967295} [2]
[4] %Split {4294967295,4294967295} [3]
[5] %BB3 {4294967295,4294967295} [4]
[6] %BB4 {4294967295,4294967295} [5]
[7] %BB5 {4294967295,4294967295} [6]
[8] %BB16 {4294967295,4294967295} [7]
[8] %BB15 {4294967295,4294967295} [7]
[8] %BB14 {4294967295,4294967295} [7]
[8] %BB13 {4294967295,4294967295} [7]
[8] %BB12 {4294967295,4294967295} [7]
[8] %BB11 {4294967295,4294967295} [7]
[8] %BB8 {4294967295,4294967295} [7]
[9] %BB28 {4294967295,4294967295} [8]
[9] %BB27 {4294967295,4294967295} [8]
[9] %BB26 {4294967295,4294967295} [8]
[9] %BB23 {4294967295,4294967295} [8]
[9] %BB24 {4294967295,4294967295} [8]
[9] %BB25 {4294967295,4294967295} [8]
[9] %BB29 {4294967295,4294967295} [8]
[9] %BB22 {4294967295,4294967295} [8]
[9] %BB20 {4294967295,4294967295} [8]
[9] %BB21 {4294967295,4294967295} [8]
[8] %BB10 {4294967295,4294967295} [7]
[8] %BB9 {4294967295,4294967295} [7]
[8] %BB7 {4294967295,4294967295} [7]
[4] %BB19 {4294967295,4294967295} [3]
Freshly computed tree:
=
Inorder Dominator Tree: DFSNumbers invalid: 0 slow queries.
[1] %BB {4294967295,4294967295} [0]
[2] %BB1 {4294967295,4294967295} [1]
[3] %BB17 {4294967295,4294967295} [2]
[3] %BB2 {4294967295,4294967295} [2]
[4] %Split {4294967295,4294967295} [3]
[5] %BB3 {4294967295,4294967295} [4]
[6] %BB4 {4294967295,4294967295} [5]
[7] %BB5 {4294967295,4294967295} [6]
[8] %BB16 {4294967295,4294967295} [7]
[8] %BB15 {4294967295,4294967295} [7]
[8] %BB14 {4294967295,4294967295} [7]
[8] %BB13 {4294967295,4294967295} [7]
[8] %BB12 {4294967295,4294967295} [7]
[8] %BB11 {4294967295,4294967295} [7]
[8] %BB8 {4294967295,4294967295} [7]
[9] %BB28 {4294967295,4294967295} [8]
[9] %BB27 {4294967295,4294967295} [8]
[9] %BB26 {4294967295,4294967295} [8]
[9] %BB23 {4294967295,4294967295} [8]
[9] %BB24 {4294967295,4294967295} [8]
[9] %BB25 {4294967295,4294967295} [8]
[9] %BB29 {4294967295,4294967295} [8]
[10] %BB6 {4294967295,4294967295} [9]
[9] %BB22 {4294967295,4294967295} [8]
[9] %BB20 {4294967295,4294967295} [8]
[9] %BB21 {4294967295,4294967295} [8]
[8] %BB10 {4294967295,4294967295} [7]
[8] %BB9 {4294967295,4294967295} [7]
[8] %BB7 {4294967295,4294967295} [7]
[4] %BB19 {4294967295,4294967295} [3]
If we use Lazy update strategy instead of Eager, the very same tests passes.
I stepped over it while working on improving LoopSimplifyCFG. I worked this bug
around by patch https://reviews.llvm.org/D57316. But it seems that it is a very
fundamental problem that compromises the DomTree updater.
--
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 40529] New: Reorder the fldcw w.r.t fmul in x86_64 fix , results in wrong output.
https://bugs.llvm.org/show_bug.cgi?id=40529
Bug ID: 40529
Summary: Reorder the fldcw w.r.t fmul in x86_64 fix ,results
in wrong output.
Product: clang
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: umesh.kalap...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
the below llvm code :
define linkonce_odr dso_local dereferenceable(96)
%"class.std::basic_ostream"*
@_ZSt6_WriteIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_e(%"class.std::basic_ostream"*
dereferenceable(96) %_Os, x86_fp80 %_Dx) local_unnamed_addr #4 comdat {
entry:
%_Ex = alloca i32, align 4
%0 = bitcast i32* %_Ex to i8*
call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %0) #8
%call = call x86_fp80 @frexpl(x86_fp80 %_Dx, i32* nonnull %_Ex) #8
%mul = fmul x86_fp80 %call, 0xK401E8000
%conv = fptosi x86_fp80 %mul to i64
%conv1 = sitofp i64 %conv to x86_fp80
%sub = fsub x86_fp80 %mul, %conv1
%call2 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c(%"class.std::basic_ostream"*
nonnull dereferenceable(96) %_Os, i8 signext 32)
%call3 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZNSolsEl(%"class.std::basic_ostream"* nonnull %call2, i64 %conv)
%mul.1 = fmul x86_fp80 %sub, 0xK401E8000
%conv.1 = fptosi x86_fp80 %mul.1 to i64
%conv1.1 = sitofp i64 %conv.1 to x86_fp80
%sub.1 = fsub x86_fp80 %mul.1, %conv1.1
%call2.1 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c(%"class.std::basic_ostream"*
nonnull dereferenceable(96) %_Os, i8 signext 32)
%call3.1 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZNSolsEl(%"class.std::basic_ostream"* nonnull %call2.1, i64 %conv.1)
%mul.2 = fmul x86_fp80 %sub.1, 0xK401E8000
%conv.2 = fptosi x86_fp80 %mul.2 to i64
%conv1.2 = sitofp i64 %conv.2 to x86_fp80
%sub.2 = fsub x86_fp80 %mul.2, %conv1.2
%call2.2 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c(%"class.std::basic_ostream"*
nonnull dereferenceable(96) %_Os, i8 signext 32)
%call3.2 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZNSolsEl(%"class.std::basic_ostream"* nonnull %call2.2, i64 %conv.2)
%mul.3 = fmul x86_fp80 %sub.2, 0xK401E8000
%conv.3 = fptosi x86_fp80 %mul.3 to i64
%call2.3 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c(%"class.std::basic_ostream"*
nonnull dereferenceable(96) %_Os, i8 signext 32)
%call3.3 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZNSolsEl(%"class.std::basic_ostream"* nonnull %call2.3, i64 %conv.3)
%call4 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c(%"class.std::basic_ostream"*
nonnull dereferenceable(96) %_Os, i8 signext 32)
%1 = load i32, i32* %_Ex, align 4, !tbaa !64
%call5 = tail call dereferenceable(96) %"class.std::basic_ostream"*
@_ZNSolsEi(%"class.std::basic_ostream"* nonnull %call4, i32 %1)
call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull %0) #8
ret %"class.std::basic_ostream"* %_Os
}
in the X86 backend ,when we have statements that converts the "double" to
"long long " then backend sets the rounding to "round to zero" by emitting
the following instruction ,before conversion like
MOV16mi %stack.8, 1, $noreg, 0, $noreg, 3199 :: (store 2 into %stack.8)
FLDCW16m %stack.8, 1, $noreg, 0, $noreg, implicit-def dead $fpsw :: (load 2
from %stack.8)
MOV16mr %stack.8, 1, $noreg, 0, $noreg, %32:gr16 :: (store 2 into %stack.8)
IST_Fp64m80 %stack.7, 1, $noreg, 0, $noreg, %6:rfp80, implicit-def dead $fpsw
and restore previous FDCW status after conversion ,but
the msched scheduler recording the "FLDCW16m along mov16mi " before
"LD_Fp32m80" attached the log(msched.log) for the reference ,results the below
code and gives not the precise output.
:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq%rsp, %rbp
.cfi_def_cfa_register %rbp
pushq %r14
pushq %rbx
subq$112, %rsp
.cfi_offset %rbx, -32
.cfi_offset %r14, -24
movq%rdi, %r14
fldt16(%rbp)
fstpt (%rsp)
leaq-40(%rbp), %rdi
callq frexpl
fnstcw -24(%rbp)
flds.LCPI83_0(%rip)
fld %st(0)
fstpt -52(%rbp) # 10-byte Folded Spill
movzwl -24(%rbp), %eax
movw$3199, -24(%rbp)# imm = 0xC7F
fldcw
[llvm-bugs] [Bug 33732] -fsanitize-coverage=trace-cmp passes parameters incorrectly
https://bugs.llvm.org/show_bug.cgi?id=33732 Alexander Potapenko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexander Potapenko --- Think so. -- 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 40530] New: Please backport r352610 to 8.0 ([clang] [Driver] [NetBSD] Append -rpath for shared compiler-rt runtimes)
https://bugs.llvm.org/show_bug.cgi?id=40530 Bug ID: 40530 Summary: Please backport r352610 to 8.0 ([clang] [Driver] [NetBSD] Append -rpath for shared compiler-rt runtimes) Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: mgo...@gentoo.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Blocks: 40331 Please backport r352610 to 8.0 branch. TIA. [clang] [Driver] [NetBSD] Append -rpath for shared compiler-rt runtimes Append appropriate -rpath when using shared compiler-rt runtimes, e.g. '-fsanitize=address -shared-libasan'. There's already a similar logic in CommonArgs.cpp but it uses non-standard arch-suffixed installation directory while we want our driver to work with standard installation paths. Differential Revision: https://reviews.llvm.org/D57303 Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=40331 [Bug 40331] [meta] 8.0.0 Release Blockers -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37698] [llvm-exegesis] Throughput calculations
https://bugs.llvm.org/show_bug.cgi?id=37698 Clement Courbet changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassignedb...@nondot.org |clement.cour...@gmail.com -- 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 40531] New: TEST 'libomp :: ompt/synchronization/lock.c' FAILED on 32-bit x86
https://bugs.llvm.org/show_bug.cgi?id=40531
Bug ID: 40531
Summary: TEST 'libomp :: ompt/synchronization/lock.c' FAILED on
32-bit x86
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: mgo...@gentoo.org
CC: llvm-bugs@lists.llvm.org
Blocks: 40331
Created attachment 21408
--> https://bugs.llvm.org/attachment.cgi?id=21408&action=edit
sys-libs:libomp-8.0.:20190130-161231.log
TEST 'libomp :: ompt/synchronization/lock.c' FAILED
Script:
--
: 'RUN: at line 1'; /usr/lib64/ccache/bin/i686-pc-linux-gnu-clang
-fno-experimental-isel -fopenmp -I
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test -I
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0.-abi_x86_32.x86/runtime/src
-L
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0.-abi_x86_32.x86/runtime/src
-I
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test/ompt
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test/ompt/synchronization/lock.c
-o
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0.-abi_x86_32.x86/runtime/test/ompt/synchronization/Output/lock.c.tmp
-lm -latomic &&
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0.-abi_x86_32.x86/runtime/test/ompt/synchronization/Output/lock.c.tmp
| tee
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test/ompt/synchronization/lock.c.out
| /usr/lib/llvm/8/bin/FileCheck
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test/ompt/synchronization/lock.c
--
Exit Code: 1
Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ "/usr/lib64/ccache/bin/i686-pc-linux-gnu-clang" "-fno-experimental-isel"
"-fopenmp" "-I"
"/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test"
"-I"
"/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0.-abi_x86_32.x86/runtime/src"
"-L"
"/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0.-abi_x86_32.x86/runtime/src"
"-I"
"/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test/ompt"
"/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test/ompt/synchronization/lock.c"
"-o"
"/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0.-abi_x86_32.x86/runtime/test/ompt/synchronization/Output/lock.c.tmp"
"-lm" "-latomic"
$
"/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0.-abi_x86_32.x86/runtime/test/ompt/synchronization/Output/lock.c.tmp"
$ "tee"
"/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test/ompt/synchronization/lock.c.out"
$ "/usr/lib/llvm/8/bin/FileCheck"
"/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test/ompt/synchronization/lock.c"
# command stderr:
/var/tmp/portage/sys-libs/libomp-8.0./work/libomp-8.0./runtime/test/ompt/synchronization/lock.c:33:12:
error: CHECK: expected string not found in input
// CHECK: {{^}}[[MASTER_ID]]: ompt_event_init_lock: wait_id=[[WAIT_ID]],
hint={{[0-9]+}}, impl={{[0-9]+}},
codeptr_ra=[[RETURN_ADDRESS:0x[0-f]+]]{{[0-f][0-f]}}
^
:10:1: note: scanning from here
281474976710657: ompt_event_init_lock: wait_id=18446744073706479000, hint=0,
impl=2, codeptr_ra=0x804b1c6
^
:10:1: note: with variable "MASTER_ID" equal to "281474976710657"
281474976710657: ompt_event_init_lock: wait_id=18446744073706479000, hint=0,
impl=2, codeptr_ra=0x804b1c6
^
:10:1: note: with variable "WAIT_ID" equal to "4291894680"
281474976710657: ompt_event_init_lock: wait_id=18446744073706479000, hint=0,
impl=2, codeptr_ra=0x804b1c6
^
error: command failed with exit status: 1
--
I've discovered it while testing for 8.0 release but I can also reproduce it
with trunk and 7.0.1. I don't really recall if I haven't tested 7.0 on x86; it
might be also caused by glibc upgrade.
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=40331
[Bug 40331] [meta] 8.0.0 Release Blockers
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40532] New: Corrupt DWARF created when linking with ld.lld
https://bugs.llvm.org/show_bug.cgi?id=40532 Bug ID: 40532 Summary: Corrupt DWARF created when linking with ld.lld Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: jonasschiev...@gmail.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org Linking two object files together (created by rustc and gcc) results in an output with corrupt debug info. Running `objdump --dwarf-check -g ` on the linker output reports this warning a few times: objdump: Warning: Corrupt unit length (0x0) found in section .debug_info When run on the object files before linking, no warning is issued. The dwarf-validate tool of the gimli library agrees with this (https://github.com/gimli-rs/gimli). I've attached the output of LLD with --reproduce. For more info, refer to https://github.com/jonas-schievink/lldbug/releases/tag/lldrepro-min (but lldrepro-min should already contain everything if I understood it correctly). LLD version: LLD 7.0.1 -- 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 40533] New: std::minmax_element is 3 times slower than hand written loop
https://bugs.llvm.org/show_bug.cgi?id=40533 Bug ID: 40533 Summary: std::minmax_element is 3 times slower than hand written loop Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: antosh...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Moreover, std::minmax_element is slower than calling std::min_element+std::max_element if there's a lot of data and it does not fit into the CPU cache: http://quick-bench.com/tlgxCx9CUMZgOfYbwhFaEI0WNOg -- 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 40534] New: Failure to leverage existing memory location when spilling
https://bugs.llvm.org/show_bug.cgi?id=40534
Bug ID: 40534
Summary: Failure to leverage existing memory location when
spilling
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Register Allocator
Assignee: unassignedb...@nondot.org
Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org, quentin.colom...@gmail.com
Filing this under register allocator, but really not sure that's the
appropriate place to fix it. The basic problem - illustrated by the test below
- is that we can have a value live in a loop which changes on every iteration,
but already has a memory location available w/said contents. Instead of
inserting new spill slots, it would be ideal to reuse the existing locations.
This particular example was motivated by our statepoint lowering - which
unfortunately, appears to create such idioms - but the problem is visible in
arbitrary IR as well. For statepoints, doing this at the MI layer would be
preferred, but I see a lot of argument for this being a missed IR level
PRE-like store transform as well.
declare void @clobber()
declare void @use(...)
define void @test(i64* %p, i64 %cnt) {
entry:
%p1 = getelementptr i64, i64* %p, i64 1
%p2 = getelementptr i64, i64* %p, i64 2
%p3 = getelementptr i64, i64* %p, i64 3
%p4 = getelementptr i64, i64* %p, i64 4
%p5 = getelementptr i64, i64* %p, i64 5
%p6 = getelementptr i64, i64* %p, i64 6
%p7 = getelementptr i64, i64* %p, i64 7
%p8 = getelementptr i64, i64* %p, i64 8
%p9 = getelementptr i64, i64* %p, i64 9
%p10 = getelementptr i64, i64* %p, i64 10
%p11 = getelementptr i64, i64* %p, i64 11
%p12 = getelementptr i64, i64* %p, i64 12
%p13 = getelementptr i64, i64* %p, i64 13
%p14 = getelementptr i64, i64* %p, i64 14
store i64 0, i64* %p
store i64 0, i64* %p1
store i64 0, i64* %p2
store i64 0, i64* %p3
store i64 0, i64* %p4
store i64 0, i64* %p5
store i64 0, i64* %p6
store i64 0, i64* %p7
store i64 0, i64* %p8
store i64 0, i64* %p9
store i64 0, i64* %p10
store i64 0, i64* %p11
store i64 0, i64* %p12
store i64 0, i64* %p13
store i64 0, i64* %p14
br label %loop
loop:
%iv = phi i64 [0, %entry], [%iv.next, %loop]
%v1 = phi i64 [0, %entry], [%v2, %loop]
%v1p1 = phi i64 [0, %entry], [%v2p1, %loop]
%v1p2 = phi i64 [0, %entry], [%v2p2, %loop]
%v1p3 = phi i64 [0, %entry], [%v2p3, %loop]
%v1p4 = phi i64 [0, %entry], [%v2p4, %loop]
%v1p5 = phi i64 [0, %entry], [%v2p5, %loop]
%v1p6 = phi i64 [0, %entry], [%v2p6, %loop]
%v1p7 = phi i64 [0, %entry], [%v2p7, %loop]
%v1p8 = phi i64 [0, %entry], [%v2p8, %loop]
%v1p9 = phi i64 [0, %entry], [%v2p9, %loop]
%v1p10 = phi i64 [0, %entry], [%v2p10, %loop]
%v1p11 = phi i64 [0, %entry], [%v2p11, %loop]
%v1p12 = phi i64 [0, %entry], [%v2p12, %loop]
%v1p13 = phi i64 [0, %entry], [%v2p13, %loop]
%v1p14 = phi i64 [0, %entry], [%v2p14, %loop]
store i64 %v1, i64* %p
store i64 %v1p1, i64* %p1
store i64 %v1p2, i64* %p2
store i64 %v1p3, i64* %p3
store i64 %v1p4, i64* %p4
store i64 %v1p5, i64* %p5
store i64 %v1p6, i64* %p6
store i64 %v1p7, i64* %p7
store i64 %v1p8, i64* %p8
store i64 %v1p9, i64* %p9
store i64 %v1p9, i64* %p10
store i64 %v1p10, i64* %p11
store i64 %v1p12, i64* %p12
store i64 %v1p13, i64* %p13
store i64 %v1p14, i64* %p14
call void @clobber()
%v2 = load i64, i64* %p
%v2p1 = load i64, i64* %p1
%v2p2 = load i64, i64* %p2
%v2p3 = load i64, i64* %p3
%v2p4 = load i64, i64* %p4
%v2p5 = load i64, i64* %p5
%v2p6 = load i64, i64* %p6
%v2p7 = load i64, i64* %p7
%v2p8 = load i64, i64* %p8
%v2p9 = load i64, i64* %p9
%v2p10 = load i64, i64* %p10
%v2p11 = load i64, i64* %p11
%v2p12 = load i64, i64* %p12
%v2p13 = load i64, i64* %p13
%v2p14 = load i64, i64* %p14
%iv.next = add i64 %iv, 1
%exit.cmp = icmp sgt i64 %iv, 200
br i1 %exit.cmp, label %exit, label %loop
exit:
call void (...) @use(i64 %v2)
ret void
}
$ ../build/bin/opt -O1 -S loop-stld.ll | ../build/bin/llc -O3
.text
.file "loop-stld.ll"
.globl test# -- Begin function test
.p2align4, 0x90
.type test,@function
test: # @test
.cfi_startproc
# %bb.0:# %entry
pushq %rbp
.cfi_def_cfa_offset 16
pushq %r15
.cfi_def_cfa_offset 24
pushq %r14
.cfi_def_cfa_offset 32
pushq %r13
.cfi_def_cfa_offset 40
pushq %r12
.cfi_def_cfa_offset 48
pushq %rbx
.cfi_def_cfa_offset 56
subq$24, %rsp
.cfi_def_cfa_offset 80
.cfi_offset %rbx, -56
.cfi_offset %r12, -48
.cfi_offset %r13, -40
.cfi_offset %r14, -32
[llvm-bugs] [Bug 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40530, which changed state. Bug 40530 Summary: Please backport r352610 to 8.0 ([clang] [Driver] [NetBSD] Append -rpath for shared compiler-rt runtimes) https://bugs.llvm.org/show_bug.cgi?id=40530 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 40530] Please backport r352610 to 8.0 ([clang] [Driver] [NetBSD] Append -rpath for shared compiler-rt runtimes)
https://bugs.llvm.org/show_bug.cgi?id=40530 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED CC||h...@chromium.org Resolution|--- |FIXED --- Comment #1 from Hans Wennborg --- Merged in r352650. Thanks! -- 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 36160] Support --discard-locals in llvm-objcopy
https://bugs.llvm.org/show_bug.cgi?id=36160 Jordan Rupprecht changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||https://reviews.llvm.org/rL ||352626 Status|CONFIRMED |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 40535] New: Error message for incorrectly specified constructor method is unhelpful
https://bugs.llvm.org/show_bug.cgi?id=40535
Bug ID: 40535
Summary: Error message for incorrectly specified constructor
method is unhelpful
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: rgovos...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
class Foo {
Foo(int x);
};
Foo(int x) {
// nothing
}
Compiling this code gives the following error messages:
foo.cpp:5:5: error: expected unqualified-id
Foo(int x) {
^
foo.cpp:5:5: error: expected ')'
foo.cpp:5:4: note: to match this '('
Foo(int x) {
^
2 errors generated.
The actual problem is that I should have written:
Foo::Foo(int x) {
// nothing
}
This mistake was easy because I moved the implementation of Foo::Foo from
inside the class, where it doesn't need to be qualified with the class name, to
outside the class, where it does.
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
--
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 40204] [WebAssembly] SDL2_mixer crash on linking with --relocatable
https://bugs.llvm.org/show_bug.cgi?id=40204 Sam Clegg changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |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 40537] New: [lld] Merge r352407, r352435, r352482 and r352606 into the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=40537
Bug ID: 40537
Summary: [lld] Merge r352407, r352435, r352482 and r352606 into
the 8.0 branch
Product: lld
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: release blocker
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org
This revision: https://reviews.llvm.org/rL352606 ("Recognize FreeBSD specific
BFD names in OUTPUT_FORMAT") adds FreeBSD specific BFD target names to
OUTPUT_FORMAT linker script commands.
It has a few prerequisites, all of which are due to some refactoring in that
area:
https://reviews.llvm.org/rL352407 ("Refactoring. NFC")
https://reviews.llvm.org/rL352435 ("Attempt to fix build failure with GCC 5.4")
https://reviews.llvm.org/rL352482 ("[ELF] - Remove dead `readBfdName`
declaration. NFC")
--
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 40536] New: undefined reference to __kmpc_push_target_tripcount
https://bugs.llvm.org/show_bug.cgi?id=40536
Bug ID: 40536
Summary: undefined reference to __kmpc_push_target_tripcount
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: a.bat...@hotmail.com
Reporter: jdenny.o...@gmail.com
CC: llvm-bugs@lists.llvm.org
At r352640 and since r350571, some directives cause an undefined reference to
__kmpc_push_target_tripcount. For example:
```
$ cat test.c
int main() {
#pragma omp target teams
#pragma omp distribute
for (int i = 0; i < 8; ++i)
;
return 0;
}
$ clang -fopenmp test.c
/tmp/test-b61bc4.o: In function `main':
test.c:(.text+0x1c): undefined reference to `__kmpc_push_target_tripcount'
clang-8: error: linker command failed with exit code 1 (use -v to see
invocation)
$ clang -fopenmp -lomptarget test.c
$ ./a.out
Libomptarget fatal error 1: default offloading policy must switched to
mandatory or disabled
$ clang -fopenmp -fopenmp-targets=nvptx64 test.c
$ ./a.out
$ echo $?
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 40519] clang++ fails to compile SFINAE member function overloaded with using-imported fallback function from base class
https://bugs.llvm.org/show_bug.cgi?id=40519 Richard Smith changed: What|Removed |Added Resolution|--- |LATER Status|NEW |RESOLVED --- Comment #2 from Richard Smith --- See http://eel.is/c++draft/namespace.udecl#15: "When a using-declarator brings declarations from a base class into a derived class, member functions and member function templates in the derived class override and/or hide member functions and member function templates with the same name, parameter-type-list, cv-qualification, and ref-qualifier (if any) in a base class (rather than conflicting). Such hidden or overridden declarations are excluded from the set of declarations introduced by the using-declarator." The base class function template is hidden by the derived class one despite having a different return type and despite the use of a using declaration. GCC doesn't implement that rule as-written; there's a chance the language will be changed to do something more like what GCC does, but for now this is a GCC bug and the other compilers are correct. -- 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 40528] [DTU] DomTreeUpdater's Eager strategy fails to update DomTree, Lazy strategy works OK
https://bugs.llvm.org/show_bug.cgi?id=40528 Jakub Kuderski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 40538] New: DebugInfo: Should Clang cc1as be calling setMCLineTableRootFile
https://bugs.llvm.org/show_bug.cgi?id=40538 Bug ID: 40538 Summary: DebugInfo: Should Clang cc1as be calling setMCLineTableRootFile Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: paul.robin...@am.sony.com Reporter: dblai...@gmail.com CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com (Relevant context on the review thread of r328805, and related commit r352541) There seems to be an unexplained difference between assembling code with llvm-mc and with Clang's cc1as using DWARFv5 - llvm-mc calls setMCLineTableRootFile and cc1as does not. At least in my data, this was related to/lead to llvm-mc successfully assembling an empty asm file, and cc1as crashing on it (until the fix in r352541), though Paul Robinson observed a crash in llvm-mc as well. Looks like setMCLineTableRootFile does useful things like including the source and md5sum of the file, if desired, for the DWARFv5 output. So it'd be good to resolve this one way or the other - remove the function, or add a call to it from cc1as, so the two uses are symmetric (or explain why they shouldn't be symmetric here). -- 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 40539] New: [X86] PostRAScheduler can reorder inline assembly containing x87 instructions with other x87 instructions used to get the results from the inline assembly.
https://bugs.llvm.org/show_bug.cgi?id=40539
Bug ID: 40539
Summary: [X86] PostRAScheduler can reorder inline assembly
containing x87 instructions with other x87
instructions used to get the results from the inline
assembly.
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: craig.top...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
This test case when compiled with -mtriple=i686 -mcpu=pentium4
@f1 = global float 1.00e+00, align 4
define zeroext i1 @_Z9test_log2v() {
entry:
%0 = load float, float* @f1, align 4
%1 = fpext float %0 to x86_fp80
%2 = tail call x86_fp80 asm "fld1; fxch; fyl2x",
"={st},0,~{st(1)},~{dirflag},~{fpsr},~{flags}"(x86_fp80 %1)
%conv = fptrunc x86_fp80 %2 to float
%3 = fcmp oeq float %conv, 0.00e+00
ret i1 %3
}
Will generate this assembly
pushl %eax
.cfi_def_cfa_offset 8
fldsf1
fstps (%esp)
xorps %xmm0, %xmm0
#APP
fld1
fxch%st(1)
fyl2x
#NO_APP
cmpeqss (%esp), %xmm0
movd%xmm0, %eax
andl$1, %eax
# kill: def $al killed $al killed $eax
popl%ecx
.cfi_def_cfa_offset 4
retl
The fstps instruction needs to be below the inline assembly block. It's
supposed to store the results from the inline assembly.
--
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 40536] undefined reference to __kmpc_push_target_tripcount
https://bugs.llvm.org/show_bug.cgi?id=40536 Alexey Bataev changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||r352669 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 40540] New: Rename COMDATs when renaming COMDAT leader for CFI
https://bugs.llvm.org/show_bug.cgi?id=40540 Bug ID: 40540 Summary: Rename COMDATs when renaming COMDAT leader for CFI Product: new-bugs Version: 8.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dma...@mozilla.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, pe...@pcc.me.uk, tejohn...@google.com In bug 40414 comment #15, Teresa Johnson writes: > This turns out to be a separate instance of renaming provoking this issue. > In this case, the module was split due to CFI, and no renaming/promotion was > required since the comdat and the leader are in the same module. > > However, in LowerTypeTests.cpp a ".cfi" suffix is added to the function > definition which is the comdat leader, provoking the same error. This is an > existing issue unrelated to the one provoked by changing the splitting > default. Probably needs a separate bug to track. You could cc > pe...@pcc.me.uk and myself. -- 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 39685] Inserting an element to an undef vector
https://bugs.llvm.org/show_bug.cgi?id=39685 Heejin Ahn changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Heejin Ahn --- Fixed by r352592. -- 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 40524] INVOKEing pointer to const&-qualified member function with rvalue results in an error
https://bugs.llvm.org/show_bug.cgi?id=40524 Eric Fiselier changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||e...@efcs.ca --- Comment #1 from Eric Fiselier --- Invoking a pointer to a 'const &' member function on an rvalue is a C++2a extension. Prior to C++2a GCC and Clang accept it as conforming extension. But in order for the extension to be conforming, it has to be disabled in SFINAE contexts -- otherwise it could change the meaning of well-defined code. If you compile your example with -std=c++17 -pedantic-errors then both invocations are rejected. (https://godbolt.org/z/ofS4AB) Both libc++ and libstdc++ reject this prior to C++2a but accept it after. This is the correct behavior. There is nothing to do here. -- 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 40524] INVOKEing pointer to const&-qualified member function with rvalue results in an error
https://bugs.llvm.org/show_bug.cgi?id=40524 Eric Fiselier changed: What|Removed |Added Resolution|FIXED |INVALID -- 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 40541] New: LLVM 8 stopped optimizing pow(2., x) to exp2(x)
https://bugs.llvm.org/show_bug.cgi?id=40541
Bug ID: 40541
Summary: LLVM 8 stopped optimizing pow(2., x) to exp2(x)
Product: clang
Version: 8.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: dma...@mozilla.com
CC: e.mene...@samsung.com, htmldevelo...@gmail.com,
llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
We noticed this on 32-bit clang-cl builds.
#include
float foo(double d) { return pow(2., d / 1200.); }
> d:\clang7.0.1\bin\clang-cl -m32 -O2 -c exp2.cpp
> dumpbin /all exp2.obj | findstr REL32
0017 REL32 F _exp2
> d:\clang8rc1\bin\clang-cl -m32 -O2 -c exp2.cpp
> dumpbin /all exp2.obj | findstr REL32
002C REL32 11 _pow
At first glance I'm suspecting a bug in
https://github.com/llvm/llvm-project/commit/2123ea7d5c722e98ce0f047c8baa3fb3db23e6b3.
--
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 40267] SplitVecOp_EXTRACT_VECTOR_ELT - Invalid vector index!
https://bugs.llvm.org/show_bug.cgi?id=40267 Thomas Lively changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Lively --- This is fixed in rL352702. -- 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 12437 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: IdxVal < VecVT.getVectorNumElements() && "Invalid vector index!"
Comment #2 on issue 12437 by tliv...@google.com: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: IdxVal < VecVT.getVectorNumElements() && "Invalid vector index!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12437#c2 This is fixed in LLVM commit rL352702. In the future, would it be possible to have WebAssembly LLVM backend bugs reported directly to the WebAssembly tools team? -- 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 40542] New: unsupported flag -n
https://bugs.llvm.org/show_bug.cgi?id=40542 Bug ID: 40542 Summary: unsupported flag -n Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: ndesaulni...@google.com CC: gri...@accesssoftek.com, llvm-bugs@lists.llvm.org, peter.sm...@linaro.org, r...@google.com, srhi...@google.com The arm64 linux kernel vdso Makefile makes use of `$(CC) -Wl,-n` when linking. This produces an error when trying to link with ld.lld. I can link without it, but I'm unsure of the implications of turning it off. The man page for bfd suggests that sections will be page aligned, so I'm guessing that's going to create a larger object than needed? -- 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 40543] New: double floating point suffixes D and d not accepted
https://bugs.llvm.org/show_bug.cgi?id=40543 Bug ID: 40543 Summary: double floating point suffixes D and d not accepted Product: clang Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: b...@lindev.ch CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk The line double d = 0.4D; causes clang to barf with test.c:2:14: error: invalid suffix 'D' on floating constant gcc accepts that code, and this seems to be the correct behavior at least for C99+. (see this gcc bug report from 10 years ago: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027) -- 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 40528] [DTU] DomTreeUpdater's Eager strategy fails to update DomTree, Lazy strategy works OK
https://bugs.llvm.org/show_bug.cgi?id=40528 Max Kazantsev changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from Max Kazantsev --- Let's keep it open then. If you think it's not a bug, feel free to close as invalid and update the doc. Otherwise, please close it when it is 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 40543] double floating point suffixes D and d not accepted
https://bugs.llvm.org/show_bug.cgi?id=40543 Richard Smith changed: What|Removed |Added Resolution|--- |LATER Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- This is part of the decimal floating point extensions to C, not part of C99 or any C or C++ standard. Clang does not implement the decimal floating point extensions to C. Closing this, because a bug here is not going to cause us to implement this set of language extensions. If someone motivated wants to implement it, that should be discussed on our mailing lists. -- 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 35611] [meta] Missed fast-math optimizations
https://bugs.llvm.org/show_bug.cgi?id=35611 Bug 35611 depends on bug 35594, which changed state. Bug 35594 Summary: Missed optimization in math expression: simplify calls std::exp functions https://bugs.llvm.org/show_bug.cgi?id=35594 What|Removed |Added Status|CONFIRMED |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 35594] Missed optimization in math expression: simplify calls std::exp functions
https://bugs.llvm.org/show_bug.cgi?id=35594 Dmitry Venikov changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dmitry Venikov --- Commits: rL352613, rL352730 -- 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
