[llvm-bugs] [Bug 38219] New: Clang consistently crashes on FreeBSD during code generation of a coroutine.
https://bugs.llvm.org/show_bug.cgi?id=38219 Bug ID: 38219 Summary: Clang consistently crashes on FreeBSD during code generation of a coroutine. Product: clang Version: trunk Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: alexe...@xiphos.de CC: llvm-bugs@lists.llvm.org Created attachment 20576 --> https://bugs.llvm.org/attachment.cgi?id=20576&action=edit command-line output, preprocessed source and associated run script Clang consistently crashes on FreeBSD during code generation of a coroutine while the same code works in WSL (Linux). FreeBSD 12.0-CURRENT r324496 amd64 LLVM from /usr/ports/devel/llvm-devel version 7.0.0 snapshot date 20180523 Attached is the command-line output, the "preprocessed sources" and the "associated run scripts". Here is the complete source code: https://github.com/qis/ice/tree/474b78fa170664f7578ef08e7955fd232ffbe25d Here is the core dump: http://xiphos.de/clang-7.core I'm happy to help debugging and answer any questions per mail or in #llvm on the cpplang slack. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38220] New: timespec should be in the std namespace
https://bugs.llvm.org/show_bug.cgi?id=38220 Bug ID: 38220 Summary: timespec should be in the std namespace Product: libc++ Version: 6.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: alexe...@xiphos.de CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com https://en.cppreference.com/w/cpp/chrono/c/timespec_get suggests that timespec should be in the std namespace when included with . As far as I can tell, this is currently not the case in libc++. Is this a conformance bug with C++17/C11 or is cppreference.com wrong? -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38197] Compiler producing suboptimal code for vector packed fp operation followed by a vector insert
https://bugs.llvm.org/show_bug.cgi?id=38197 Simon Pilgrim changed: What|Removed |Added Fixed By Commit(s)||337419 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Simon Pilgrim --- Fixed by rL337419 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 9397 in oss-fuzz: llvm: Build failure
Comment #2 on issue 9397 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9397#c2 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-bd4a6fa1-0aa0-4959-83c4-ae0880ad4704.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38221] New: error: unknown instruction for inline asm "cvt.s.pl %0, %4\n\t"
https://bugs.llvm.org/show_bug.cgi?id=38221
Bug ID: 38221
Summary: error: unknown instruction for inline asm "cvt.s.pl
%0, %4\n\t"
Product: clang
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: lesliez...@llvm.org.cn
CC: llvm-bugs@lists.llvm.org
Hi LLVM developers,
I am building OpenJDK8[1] with LLVM toolchain[2] for mips64el, it[3] failed
to build:
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:429:13:
error: unknown instruction
"cvt.s.pl %0, %4\n\t"
^
:1:2: note: instantiated into assembly here
cvt.s.pl $f0, $f0
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:429:31:
error: unknown instruction
"cvt.s.pl %0, %4\n\t"
^
:2:2: note: instantiated into assembly here
cvt.s.pu $f1, $f0
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:430:31:
error: unknown instruction
"cvt.s.pu %1, %4\n\t"
^
:3:2: note: instantiated into assembly here
cvt.s.pl $f2, $f1
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:431:31:
error: unknown instruction
"cvt.s.pl %2, %5\n\t"
^
:4:2: note: instantiated into assembly here
cvt.s.pu $f3, $f1
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:441:37:
error: unknown instruction
"add.s %2, %4, %6\n\t"
^
:3:2: note: instantiated into assembly here
pll.ps $f0, $f1, $f2
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:491:17:
error: unknown instruction
"cvt.s.pu %3, %9\n\t"
^
:1:2: note: instantiated into assembly here
cvt.s.pu $f3, $f0
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:491:35:
error: unknown instruction
"cvt.s.pu %3, %9\n\t"
^
:2:2: note: instantiated into assembly here
cvt.s.pl $f4, $f0
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:492:35:
error: unknown instruction
"cvt.s.pl %4, %9\n\t"
^
:3:2: note: instantiated into assembly here
cvt.s.pu $f5, $f1
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:493:36:
error: unknown instruction
"cvt.s.pu %5, %10\n\t"
^
:4:2: note: instantiated into assembly here
cvt.s.pl $f6, $f1
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:494:36:
error: unknown instruction
"cvt.s.pl %6, %10\n\t"
^
:5:2: note: instantiated into assembly here
cvt.s.pu $f7, $f2
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:495:36:
error: unknown instruction
"cvt.s.pu %7, %11\n\t"
^
:6:2: note: instantiated into assembly here
cvt.s.pl $f8, $f2
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:498:41:
error: unknown instruction
"madd.s %2, %4, %6, %8\n\t"
^
:9:2: note: instantiated into assembly here
pll.ps $f0, $f1, $f2
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:464:37:
error: unknown instruction
"mul.s %2, %4, %6\n\t"
^
:3:2: note: instantiated into assembly here
pll.ps $f0, $f1, $f2
^
/home/loongson/jdk8-mips/hotspot/src/os_cpu/linux_mips/vm/os_linux_mips.cpp:453:37:
error: unknown instruction
"sub.s %2, %4, %6\n\t"
^
:3:2: note: instantiated into assembly here
pll.ps $f0, $f1, $f2
But reduced testcase1 is able to work:
$ cat t.s
cvt.s.pl $f0, $f1
$ clang -c t.s -o t.o
$ file t.o
t.o: ELF 64-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), not
stripped
And reduced testcase2 is able to work too:
$ cat t.cpp
void t() {
float ft_upper = 6, ft_lower = 5, fs_upper = 4, fs_lower = 3;
double ft_value = 2, fs_value = 1;
__asm__ __volatile__ (
"cvt.s.pl %0, %4\n\t"
"cvt.s.pu %1, %4\n\t"
"cvt.s.pl %2, %5\n\t"
"cvt.s.pu %3, %5\n\t"
: "=f" (fs_lower), "=f" (fs_upper), "=f" (ft_lower), "=f" (ft_upper)
: "f" (fs_value), "f" (ft_value)
);
}
$ clang++ -c t.cpp -o t.o
$ file t.o
t.o: ELF 64-bit LSB relocatable, MIPS, MIPS64 rel2 versi
[llvm-bugs] [Bug 38222] New: LLDB creates a new console at process launch on Windows
https://bugs.llvm.org/show_bug.cgi?id=38222 Bug ID: 38222 Summary: LLDB creates a new console at process launch on Windows Product: lldb Version: 6.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: kenji.koyan...@gmail.com CC: llvm-bugs@lists.llvm.org I think that CREATE_NEW_CONSOLE is unnecessary. source/Host/windows/ProcessLauncherWindows.cpp: 75 - DWORD flags = CREATE_NEW_CONSOLE | CREATE_UNICODE_ENVIRONMENT; + DWORD flags = CREATE_UNICODE_ENVIRONMENT; -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38223] New: Closing braces have line hit counts where it shouldn't
https://bugs.llvm.org/show_bug.cgi?id=38223
Bug ID: 38223
Summary: Closing braces have line hit counts where it shouldn't
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: profile
Assignee: unassignedb...@nondot.org
Reporter: calixte.deni...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20577
--> https://bugs.llvm.org/attachment.cgi?id=20577&action=edit
Archive with GCNO, GCDA, source file and GCOV output
clang++-7 main.cpp --coverage -O0
./a.out
llvm-cov-7 gcov main.gcno
The result is:
-:0:Source:main.cpp
-:0:Graph:main.gcno
-:0:Data:main.gcda
-:0:Runs:1
-:0:Programs:1
-:1:struct A {
-:2:int x;
1:3:A(int _x): x(_x)
-:4:{
1:5:}
-:6:
1:7:~A() { }
-:8:
-:9:void get(int &r)
-: 10:{
22: 11:for (int i = 0; i < x; ++i)
-: 12:{
10: 13:r += i;
10: 14:}
1: 15:}
-: 16:
-: 17:int get() const
-: 18:{
1: 19:return x;
-: 20:}
-: 21:};
-: 22:
-: 23:int main()
-: 24:{
1: 25:A a(10);
-: 26:
1: 27:int r = 3;
1: 28:a.get(r);
-: 29:
2: 30:r += a.get();
-: 31:
1: 32:return r;
1: 33:}
Lines 14, 15, 33 are hit.
With gcc-8, I get:
-:0:Source:main.cpp
-:0:Graph:main.gcno
-:0:Data:main.gcda
-:0:Runs:1
-:0:Programs:1
-:1:struct A {
-:2:int x;
1:3:A(int _x): x(_x)
-:4:{
1:5:}
-:6:
1:7:~A() { }
-:8:
1:9:void get(int &r)
-: 10:{
11: 11:for (int i = 0; i < x; ++i)
-: 12:{
10: 13:r += i;
-: 14:}
1: 15:}
-: 16:
1: 17:int get() const
-: 18:{
1: 19:return x;
-: 20:}
-: 21:};
-: 22:
1: 23:int main()
-: 24:{
1: 25:A a(10);
-: 26:
1: 27:int r = 3;
1: 28:a.get(r);
-: 29:
1: 30:r += a.get();
-: 31:
1: 32:return r;
-: 33:}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38224] New: Remove register allocator bug workaround
https://bugs.llvm.org/show_bug.cgi?id=38224 Bug ID: 38224 Summary: Remove register allocator bug workaround Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AVR Assignee: unassignedb...@nondot.org Reporter: m...@dylanmckay.io CC: llvm-bugs@lists.llvm.org The register allocator does not handle certain functions that use the 'LDDWRdPtrQ' instructions which have high register pressure. The error message is: LLVM ERROR: ran out of registers during register allocation In order to work around this, we restricted the allowable registers of LDDWRdPtrQ to disallow Z. First noticed in https://github.com/avr-rust/rust/issues/37 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 8037 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #4 on issue 8037 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8037#c4 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38225] New: [X86] Improve pass FixupLEA, and enable it on btver2.
https://bugs.llvm.org/show_bug.cgi?id=38225 Bug ID: 38225 Summary: [X86] Improve pass FixupLEA, and enable it on btver2. Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: andrea.dibia...@gmail.com CC: llvm-bugs@lists.llvm.org Three-operands LEA instructions are slow on btver2 too. So we should enable FixupLEAPass for btver2. On Btver2, a LEA with a `Scale` != 1 is always slow. We should teach the FixupLEAPass how to process those slow instructions too. In particular - using the same notation in FixupLEAPass - we should `processInstructionsForBtver()`. Currently, we only `processInstructionsForSLM()`. The core logic in method `processInstrForSlow3OpLEA()` is good for btver2. The only Intel specific portion of that code is related to the call to helper function `hasInefficientLEABaseReg()`. We should slightly restructure that logic, so that it makes sense for AMD processors too. The bottom line is: we should try to slightly restructure the code in FixupLEAPass, so that the pass can be enable on more subtargets. It would definitely help improving the codegen for btver2. I think it would also be beneficial to other AMD processors which may suffer for the same problematic LEA. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38226] New: [X86][AVX] Improve vXi64 to vXf64 ISD::UINT_TO_FP lowering
https://bugs.llvm.org/show_bug.cgi?id=38226
Bug ID: 38226
Summary: [X86][AVX] Improve vXi64 to vXf64 ISD::UINT_TO_FP
lowering
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: andrea.dibia...@gmail.com, craig.top...@gmail.com,
lebedev...@gmail.com, llvm-bugs@lists.llvm.org,
spatel+l...@rotateright.com
We support i64 to f64 ISD::UINT_TO_FP lowering, which is performed using packed
SSE instructions (using both elements to convert lower/upper 32-bits):
define <2 x double> @uitofp_2i64_to_2f64(<2 x i64> %a) {
; SSE-LABEL: uitofp_2i64_to_2f64:
; SSE: # %bb.0:
; SSE-NEXT:movdqa {{.*#+}} xmm1 = [1127219200,1160773632,0,0]
; SSE-NEXT:pshufd {{.*#+}} xmm2 = xmm0[2,3,0,1]
; SSE-NEXT:punpckldq {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; SSE-NEXT:movapd {{.*#+}} xmm3 = [4.503600e+15,1.934281e+25]
; SSE-NEXT:subpd %xmm3, %xmm0
; SSE-NEXT:pshufd {{.*#+}} xmm4 = xmm0[2,3,0,1]
; SSE-NEXT:addpd %xmm4, %xmm0
; SSE-NEXT:punpckldq {{.*#+}} xmm2 = xmm2[0],xmm1[0],xmm2[1],xmm1[1]
; SSE-NEXT:subpd %xmm3, %xmm2
; SSE-NEXT:pshufd {{.*#+}} xmm1 = xmm2[2,3,0,1]
; SSE-NEXT:addpd %xmm2, %xmm1
; SSE-NEXT:unpcklpd {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE-NEXT:retq
;
; VEX-LABEL: uitofp_2i64_to_2f64:
; VEX: # %bb.0:
; VEX-NEXT:vmovapd {{.*#+}} xmm1 = [1127219200,1160773632,0,0]
; VEX-NEXT:vunpcklps {{.*#+}} xmm2 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; VEX-NEXT:vmovapd {{.*#+}} xmm3 = [4.503600e+15,1.934281e+25]
; VEX-NEXT:vsubpd %xmm3, %xmm2, %xmm2
; VEX-NEXT:vpermilps {{.*#+}} xmm0 = xmm0[2,3,0,1]
; VEX-NEXT:vunpcklps {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
; VEX-NEXT:vsubpd %xmm3, %xmm0, %xmm0
; VEX-NEXT:vhaddpd %xmm0, %xmm2, %xmm0
; VEX-NEXT:retq
%cvt = uitofp <2 x i64> %a to <2 x double>
ret <2 x double> %cvt
}
define <4 x double> @uitofp_4i64_to_4f64(<4 x i64> %a) {
; VEX-LABEL: uitofp_4i64_to_4f64:
; VEX: # %bb.0:
; VEX-NEXT:vextractf128 $1, %ymm0, %xmm1
; VEX-NEXT:vmovapd {{.*#+}} xmm2 = [1127219200,1160773632,0,0]
; VEX-NEXT:vunpcklps {{.*#+}} xmm3 = xmm1[0],xmm2[0],xmm1[1],xmm2[1]
; VEX-NEXT:vmovapd {{.*#+}} xmm4 = [4.503600e+15,1.934281e+25]
; VEX-NEXT:vsubpd %xmm4, %xmm3, %xmm3
; VEX-NEXT:vpermilps {{.*#+}} xmm1 = xmm1[2,3,0,1]
; VEX-NEXT:vunpcklps {{.*#+}} xmm1 = xmm1[0],xmm2[0],xmm1[1],xmm2[1]
; VEX-NEXT:vsubpd %xmm4, %xmm1, %xmm1
; VEX-NEXT:vhaddpd %xmm1, %xmm3, %xmm1
; VEX-NEXT:vunpcklps {{.*#+}} xmm3 = xmm0[0],xmm2[0],xmm0[1],xmm2[1]
; VEX-NEXT:vsubpd %xmm4, %xmm3, %xmm3
; VEX-NEXT:vpermilps {{.*#+}} xmm0 = xmm0[2,3,0,1]
; VEX-NEXT:vunpcklps {{.*#+}} xmm0 = xmm0[0],xmm2[0],xmm0[1],xmm2[1]
; VEX-NEXT:vsubpd %xmm4, %xmm0, %xmm0
; VEX-NEXT:vhaddpd %xmm0, %xmm3, %xmm0
; VEX-NEXT:vinsertf128 $1, %xmm1, %ymm0, %ymm0
; VEX-NEXT:retq
%cvt = uitofp <4 x i64> %a to <4 x double>
ret <4 x double> %cvt
}
We should be able to use YMM registers to perform v4i64-v4f64 more efficiently,
and possibly even perform v2i64-v2f64 using YMMs as well (one element per
lane).
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38227] New: constexpr function call is not noexcept
https://bugs.llvm.org/show_bug.cgi?id=38227
Bug ID: 38227
Summary: constexpr function call is not noexcept
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: andrey.vih...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Compiling the following code:
constexpr int f()
{
return 0;
}
static_assert(noexcept(f()), "f() should be noexcept");
with "clang++ -std=c++11 -c x.cpp" gives:
x.cpp:6:1: error: static_assert failed due to requirement 'noexcept(f())' "f()
should be noexcept"
static_assert(noexcept(f()), "f() should be noexcept");
^ ~
1 error generated.
According to https://en.cppreference.com/w/cpp/language/noexcept, it would
appear the assert should succeed, because "f()" is a constant expression. GCC
8.1 accepts the code.
clang --version:
clang version 6.0.1 (tags/RELEASE_601/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36242] memset(foo,sizeof(foo),0) should warn
https://bugs.llvm.org/show_bug.cgi?id=36242 Erik Pilkington changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Erik Pilkington --- Added in r337470, thanks for reporting this! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38228] New: Some GCNO/GCDA in test/tools/llvm-cov/Inputs/ are not up to date
https://bugs.llvm.org/show_bug.cgi?id=38228
Bug ID: 38228
Summary: Some GCNO/GCDA in test/tools/llvm-cov/Inputs/ are not
up to date
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: profile
Assignee: unassignedb...@nondot.org
Reporter: cdeni...@mozilla.com
CC: llvm-bugs@lists.llvm.org
For example with clang++-7 and llvm-cov-7 (debian) I get for
range_based_for.cpp:
File 'range_based_for.cpp'
Lines executed:100.00% of 3
range_based_for.cpp:creating 'range_based_for.cpp.gcov'
-:0:Source:range_based_for.cpp
-:0:Graph:range_based_for.gcno
-:0:Data:range_based_for.gcda
-:0:Runs:1
-:0:Programs:1
-:1:// Make sure that compiler-added local variables (whose line
number is zero)
-:2:// don't crash llvm-cov.
-:3:
-:4:// We need shell for cd
-:5:// REQUIRES: shell
-:6:
-:7:// RUN: rm -rf %t
-:8:// RUN: mkdir %t
-:9:// RUN: cd %t
-: 10:// RUN: cp %s %p/Inputs/range_based_for.gc* .
-: 11:
-: 12:// RUN: llvm-cov gcov range_based_for.cpp | FileCheck %s
--check-prefix=STDOUT
-: 13:// STDOUT: File 'range_based_for.cpp'
-: 14:// STDOUT: Lines executed:100.00% of 5
-: 15:// STDOUT: range_based_for.cpp:creating
'range_based_for.cpp.gcov'
-: 16:
-: 17:// RUN: FileCheck %s --check-prefix=GCOV <
%t/range_based_for.cpp.gcov
-: 18:// GCOV: -:0:Runs:1
-: 19:// GCOV: -:0:Programs:1
-: 20:
-: 21:int main(int argc, const char *argv[]) { // GCOV: 1:
[[@LINE]]:int main(
1: 22: int V[] = {1, 2}; // GCOV: 1:
[[@LINE]]: int V[]
8: 23: for (int &I : V) { // GCOV: 10:
[[@LINE]]: for (
-: 24: } // GCOV: 2:
[[@LINE]]: }
1: 25: return 0; // GCOV: 1:
[[@LINE]]: return
-: 26:}// GCOV: -:
[[@LINE]]:}
-: 27:
-: 28:// llvm-cov doesn't work on big endian yet
-: 29:// XFAIL: powerpc-, powerpc64-, s390x, mips-, mips64-, sparc
I think each test should compile itself to be sure to have correct gcno/gcda.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38229] New: preserve_all calling convention is broken on AArch64
https://bugs.llvm.org/show_bug.cgi?id=38229
Bug ID: 38229
Summary: preserve_all calling convention is broken on AArch64
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: manojgu...@google.com
CC: efrie...@codeaurora.org, jykni...@google.com,
llvm-bugs@lists.llvm.org, manojgu...@google.com,
ndesaulni...@google.com
$ cat test.c
void __attribute__((preserve_all)) foo(void *ptr) { }
$ clang -c test.c -> compiles for x86_64
$ clang -c -target aarch64-unknown-linux-gnu
fatal error: error in backend: Unsupported calling convention.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38227] constexpr function call is not noexcept
https://bugs.llvm.org/show_bug.cgi?id=38227 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- cppreference.com is out of date; this language rule was removed by a set of defect resolutions. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38230] New: std::integral_constant<...>::value compilation error when used in module
https://bugs.llvm.org/show_bug.cgi?id=38230 Bug ID: 38230 Summary: std::integral_constant<...>::value compilation error when used in module Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: as...@strong.ai CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Created attachment 20578 --> https://bugs.llvm.org/attachment.cgi?id=20578&action=edit Reproduce error Assigning the value from integral_constant to a static member in a module used by the current context as well as in the current context results in compilation error (Static data member 'value' already has an initializer). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38231] New: -w does not suppress warnings promoted to errors with -Werror=…
https://bugs.llvm.org/show_bug.cgi?id=38231 Bug ID: 38231 Summary: -w does not suppress warnings promoted to errors with -Werror=… Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: bba...@google.com CC: llvm-bugs@lists.llvm.org When run with -w, GCC disables all warnings, including those which have been explicitly promoted to errors with -Werror=warningname. Clang’s -w disables all warnings *except* those which have been so promoted. For example: $ catvoid f() { > int x; > if (x = 1) {} > } > EOF $ gcc -Werror=parentheses -w -c -o /dev/null c.c $ clang -Werror=parentheses -w -c -o /dev/null c.c c.c:3:9: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (x = 1) {} ~~^~~ c.c:3:9: note: place parentheses around the assignment to silence this warning if (x = 1) {} ^ () c.c:3:9: note: use '==' to turn this assignment into an equality comparison if (x = 1) {} ^ == 1 error generated. This is already a FIXME in DiagnosticIDs.cpp (https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/DiagnosticIDs.cpp?revision=331834&view=markup#l460). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38168] mingw-w64 GCC 8.1.0 after D43029: unexpected GlobalValue size growth
https://bugs.llvm.org/show_bug.cgi?id=38168 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||337495 Resolution|--- |FIXED --- Comment #2 from Reid Kleckner --- r337495 works around the 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38232] New: Method with a swifterror param and ssp causing llc crash during livevars pass
https://bugs.llvm.org/show_bug.cgi?id=38232 Bug ID: 38232 Summary: Method with a swifterror param and ssp causing llc crash during livevars pass Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: cperfe...@arxan.com CC: llvm-bugs@lists.llvm.org Created attachment 20579 --> https://bugs.llvm.org/attachment.cgi?id=20579&action=edit minimal input bitcode to repro the llc crash I get the following llc crash when attempting to lower the attached minrepro.ll bitcode. >$ ./llc -march=x86-64 minrepro.ll Assertion failed: (MBB != &MF->front() && "Can't find reaching def for virtreg"), function MarkVirtRegAliveInBlock, file /_/git/llvm/lib/CodeGen/LiveVariables.cpp, line 113. 0 llc 0x000105fa59ec llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60 1 llc 0x000105fa5f69 PrintStackTraceSignalHandler(void*) + 25 2 llc 0x000105fa299b llvm::sys::RunSignalHandlers() + 987 3 llc 0x000105fa6b5a SignalHandler(int) + 490 4 libsystem_platform.dylib 0x7fff6c13df5a _sigtramp + 26 5 libsystem_platform.dylib 0x7ff52bd15a20 _sigtramp + 3216866016 6 libsystem_c.dylib0x7fff6bedb1ae abort + 127 7 libsystem_c.dylib0x7fff6bea31ac basename_r + 0 8 llc 0x000104d4c08b llvm::LiveVariables::MarkVirtRegAliveInBlock(llvm::LiveVariables::VarInfo&, llvm::MachineBasicBlock*, llvm::MachineBasicBlock*, std::__1::vector >&) + 1739 9 llc 0x000104d4dad3 llvm::LiveVariables::MarkVirtRegAliveInBlock(llvm::LiveVariables::VarInfo&, llvm::MachineBasicBlock*, llvm::MachineBasicBlock*) + 675 10 llc 0x000104d511a8 llvm::LiveVariables::runOnBlock(llvm::MachineBasicBlock*, unsigned int) + 1304 11 llc 0x000104d519c4 llvm::LiveVariables::runOnMachineFunction(llvm::MachineFunction&) + 644 12 llc 0x000104e19f91 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 449 13 llc 0x0001053fe33f llvm::FPPassManager::runOnFunction(llvm::Function&) + 399 14 llc 0x0001053fe845 llvm::FPPassManager::runOnModule(llvm::Module&) + 117 15 llc 0x0001053ff52f (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) + 1967 16 llc 0x0001053feb06 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 342 17 llc 0x000105400181 llvm::legacy::PassManager::run(llvm::Module&) + 33 18 llc 0x000102e3948d compileModule(char**, llvm::LLVMContext&) + 18653 19 llc 0x000102e33e75 main + 4165 20 libdyld.dylib0x7fff6be2f015 start + 1 Stack dump: 0. Program arguments: ./llc -march=x86-64 minrepro.ll 1. Running pass 'Function Pass Manager' on module 'minrepro.ll'. 2. Running pass 'Live Variable Analysis' on function '@func1' Abort trap: 6 Repros for archs: arm64, x86-64 Does not repro for arch: x86 Does not repro if fast isel is enabled with -fast-isel Does not rerpo if the swifterror function parameter attribute is removed (see minrepro.ll attachment) Does not repro if ssp function attribute is removed (see minrepro.ll attachment) Does not repro if optnone / noinline are removed (see minrepro.ll attachment) Some initial investigation which may or may not be relevant: In an MIR dump right before the "livevars" pass (./llc -march=x86-64 minrepro.ll -stop-before=livevars -o minrepro_pre_livevars.mir) I noticed that a single PHI instruction in basic block "bb.4.BLK1" references vreg %5. I found this odd because vreg %5 is defined in the basic block "bb.3.BLK1", a leaf node that would not have been executed before reaching the PHI instruction. Further investigation found that the PHI node (along with another copy instruction) are generated in the propagateSwiftErrorVRegs() method in SelectionDAGISel.cpp, and only occurs if the swifterror parameter is present. My current theory is that the splitting of basic blocks in order to insert stack protector during instruction selection is causing the data in FunctionLoweringInfo::SwiftErrorVRegDefMap and FunctionLoweringInfo::SwiftErrorVRegUpwardsUse to become invalid (since the basic blocks here were added before being split), leading to the generation of an invalid PHI or Copy instruction in propagateSwiftErrorVRegs(). While I think the above theory may be the problem, I am not familiar enough with this area of LLVM to know what sort of solution would be best here. Any feedback, corrections, or additional insights would be greatly appreciated. -- You are receiving this
[llvm-bugs] [Bug 38233] New: LLDB build fails when done with GCC 8.1 against Python 3
https://bugs.llvm.org/show_bug.cgi?id=38233 Bug ID: 38233 Summary: LLDB build fails when done with GCC 8.1 against Python 3 Product: lldb Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: bneume...@gmail.com CC: llvm-bugs@lists.llvm.org I don't know whether the issue is triggered by doing the build with GCC 8.1, or by building on a system with only Python 3, or both, but the build of LLDB crashes with: -- [ 89%] Building CXX object tools/lldb/source/Plugins/ScriptInterpreter/Python/CMakeFiles/lldbPluginScriptInterpreterPython.dir/PythonDataObjects.cpp.o /usr/src/llvm/llvm-6.0.0/tools/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp: In member function 'llvm::StringRef lldb_private::PythonString::GetString() const': /usr/src/llvm/llvm-6.0.0/tools/lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp:410:30: error: invalid conversion from 'const char*' to 'char*' [-fpermissive] c = PyUnicode_AsUTF8AndSize(m_py_obj, &size); ~~~^ At global scope: cc1plus: warning: unrecognized command line option '-Wno-vla-extension' cc1plus: warning: unrecognized command line option '-Wno-deprecated-register' make[2]: *** [tools/lldb/source/Plugins/ScriptInterpreter/Python/CMakeFiles/lldbPluginScriptInterpreterPython.dir/build.make:63: tools/lldb/source/Plugins/ScriptInterpreter/Python/CMakeFiles/lldbPluginScriptInterpreterPython.dir/PythonDataObjects.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:80120: tools/lldb/source/Plugins/ScriptInterpreter/Python/CMakeFiles/lldbPluginScriptInterpreterPython.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 - I was able to work around the problem by removing the Python 2 part of the conditional and replacing: char *c; c = PyUnicode_AsUTF8AndSize(m_py_obj, &size); with: const char *c = PyUnicode_AsUTF8AndSize(m_py_obj, &size); That's obviously not ideal, but is a tolerable workaround for my purposes and I don't have ready access to Python 2 on this system so I'm not sure how to reconcile 2 and 3 properly. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38234] New: Partial specialization halfway accepted after instantiation
https://bugs.llvm.org/show_bug.cgi?id=38234
Bug ID: 38234
Summary: Partial specialization halfway accepted after
instantiation
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The following code produces predictable but odd output. The compiler should
either generate a warning for this case or throw away the instantiation of the
type upon encountering the better-matching partial specialization, somehow
keeping it for code above the given line.
template
struct A {
T o;
};
int sizeofa = sizeof(A);
template
struct A {
T o[5];
};
int newsizeofa = sizeof(A);
int main() {
printf("%d, %d, %d\n", sizeofa, sizeof(A), sizeof(A));
}
The given output is 8, 8, 40. It appears that the specialization is accepted
for any type not yet instantiated.
I tried g++. It produces an error message:
code1.cpp:12:8: error: partial specialization of 'struct A' after
instantiation of 'struct A' [-fpermissive]
struct A {
^~
A simpler testcase:
template struct A { };
A a;
template struct A { }; // { dg-error "A" }
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38235] New: attribute((constructor)) accepts enum class as integer constan
https://bugs.llvm.org/show_bug.cgi?id=38235
Bug ID: 38235
Summary: attribute((constructor)) accepts enum class as integer
constan
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The code is as follow:
enum class E : int { prio = 666 };
void f (int) __attribute__((constructor(E::prio)));
It is accepted by clang++ whereas the conversion should require an explicit
cast. default_conversion -> decay_conversion -> decl_constant_value_safe
returns:
constant 666>
and we then accept any integer_cst.
Instead, g++ rejects the code:
error: constructor priorities must be integers from 0 to 65535 inclusive
void f (int) __attribute__((constructor(E::prio)));
^
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38236] New: flexible array member in an otherwise empty struct
https://bugs.llvm.org/show_bug.cgi?id=38236
Bug ID: 38236
Summary: flexible array member in an otherwise empty struct
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The code is as follow:
struct ordered_tasks
{
int * pop ();
};
struct A
{
ordered_tasks * tasks[];
int * pop ();
};
int pop_first_bucket;
int * A::pop ()
{
int * out;
int cur_bucket = 0;
do {
if (tasks[0]) {
out = tasks[cur_bucket]->pop();
if (out)
return out;
}
} while (pop_first_bucket);
return 0;
}
clang++ accepts the code, but g++ rejects it:
code0.cpp:8:24: error: flexible array member 'A::tasks' in an otherwise empty
'struct A'
ordered_tasks * tasks[];
^
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38237] New: Default argument checking not performed after overload resolution with C linkage
https://bugs.llvm.org/show_bug.cgi?id=38237
Bug ID: 38237
Summary: Default argument checking not performed after overload
resolution with C linkage
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
he following code is ill-formed according to the standard, but accepted by
clang++:
namespace A {
extern "C" void f(int = 5);
}
namespace B {
extern "C" void f(int = 4);
}
using A::f;
using B::f;
int main() {
f(3);//OK
f(); //ERROR
}
When a default argument is used as in the second call, it needs to be looked up
to make sure it isn't declared twice. If it is, then it's an error. clang++
will also accept the code whether the default arguments to f() are given the
same or different values.
Instead, g++ rejects the code:
code0.cpp:12:4: error: default argument mismatch in overload resolution
[-fpermissive]
f(); //ERROR
^
code0.cpp:2:18: note: candidate 1: 'void A::f(int = 5)'
extern "C" void f(int = 5);
^
code0.cpp:5:18: note: candidate 2: 'void B::f(int = 4)'
extern "C" void f(int = 4);
^
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38238] New: left operand of shift expression ‘(-1 << 4)’ is negative
https://bugs.llvm.org/show_bug.cgi?id=38238
Bug ID: 38238
Summary: left operand of shift expression ‘(-1 << 4)’ is
negative
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
The code is as follow:
enum A { bit_mask = ~(-1 << 4) };
clang++ accepts it, but g++ rejects it:
code0.cpp:1:26: error: left operand of shift expression '(-1 << 4)' is negative
[-fpermissive]
enum A { bit_mask = ~(-1 << 4) };
^
code0.cpp:1:30: error: enumerator value for 'bit_mask' is not an integer
constant
enum A { bit_mask = ~(-1 << 4) };
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38237] Default argument checking not performed after overload resolution with C linkage
https://bugs.llvm.org/show_bug.cgi?id=38237 Richard Smith changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk --- Comment #1 from Richard Smith --- This is C++ DR 1, and we track its status here: http://clang.llvm.org/cxx_dr_status.html#1 We don't need a separate bug on it, particularly not one that's not motivated by any actual user code. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38236] flexible array member in an otherwise empty struct
https://bugs.llvm.org/show_bug.cgi?id=38236 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |INVALID --- Comment #1 from Richard Smith --- > clang++ accepts the code, but g++ rejects it: > > code0.cpp:8:24: error: flexible array member 'A::tasks' in an otherwise > empty 'struct A' > ordered_tasks * tasks[]; > ^ This is intentional. C has a rule that structs can't be empty, C++ does not, so it makes sense that this restriction would not exist in C++. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38239] New: Missed simplication of division
https://bugs.llvm.org/show_bug.cgi?id=38239
Bug ID: 38239
Summary: Missed simplication of division
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
Hello,
int f1(int x, int y, int z) {
return (z * x) / (z * y);
}
f1(int, int, int):
imul edi, edx
imul esi, edx
mov eax, edi
cdq
idiv esi
ret
Possibly, this can be transformed to "return x / y" ? z = 0 leads to "division
by zero is undefined".
f2(int, int):
mov eax, edi
cdq
idiv esi
ret
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
