[llvm-bugs] [Bug 39557] New: AsmParser cannot recognize function types without definitions
https://bugs.llvm.org/show_bug.cgi?id=39557 Bug ID: 39557 Summary: AsmParser cannot recognize function types without definitions Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: ahee...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 21082 --> https://bugs.llvm.org/attachment.cgi?id=21082&action=edit Test case .ll file When there is a function call to a function that does not have a definition, if we generate .s file using `llc` and generate .o file from it using `llvm-mc`, the function symbol is recognized as not a function but a data. Commands that reproduce the bug: ``` llc -filetype=asm -asm-verbose=false test.ll -o test.s llvm-mc -triple=wasm32-unknown-unknown -filetype=obj test.s -o test_from_s.o obj2yaml test_from_s.o > test_from_s.yaml llc -filetype=obj test.ll -o test.o obj2yaml test.o > test.yaml ``` test.yaml and test_from_s.yaml are supposed to be the same, but they are not. In test_from_s.yaml, foo, which is defined, is listed as a function symbol, but bar, which is not defined, is listed as data. ``` SymbolTable: - Index: 0 Kind:FUNCTION Name:foo Flags: [ BINDING_LOCAL ] Function:0 - Index: 1 Kind:DATA Name:bar Flags: [ UNDEFINED ] ``` And consequentially, it has no function import entry in the 'Import' section, and no type signature entry in 'Type' section as well. -- 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 39558] New: obj2yaml crashes on object files created by llvm-mc
https://bugs.llvm.org/show_bug.cgi?id=39558 Bug ID: 39558 Summary: obj2yaml crashes on object files created by llvm-mc Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: ahee...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 21089 --> https://bugs.llvm.org/attachment.cgi?id=21089&action=edit Test case .ll file This bug was accidentally discovered while filing https://bugs.llvm.org/show_bug.cgi?id=39557. The test case is the same with PR39557 except now function 'foo' does not take an argument. I don't know why, but now obj2yaml crashes on reading the object file created from .s file using llvm-mc. llvm-objdump crashes too. Commands that reproduce the bug: ``` llc -filetype=asm -asm-verbose=false test.ll -o test.s llvm-mc -triple=wasm32-unknown-unknown -filetype=obj test.s -o test_from_s.o obj2yaml test_from_s.o > test_from_s.yaml <-- crashes! llvm-objdump -disassemble test_from_s.o<-- crashes too! ``` -- 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 33628] Implement a new dllexport/dllimport variant that doesn't apply to class inline functions
https://bugs.llvm.org/show_bug.cgi?id=33628 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Hans Wennborg --- This was committed in r346069 -- 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 11064 in oss-fuzz: llvm: Build failure
Comment #4 on issue 11064 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11064#c4 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-fe6354ec-1333-4eaf-a038-d1c61daebcdb.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 39559] New: Segmentation fault when running check-clang-python with UBSan
https://bugs.llvm.org/show_bug.cgi?id=39559
Bug ID: 39559
Summary: Segmentation fault when running check-clang-python
with UBSan
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: david.stenb...@ericsson.com
CC: llvm-bugs@lists.llvm.org
When running check-clang-python on trunk (r346128) with a
LLVM_USE_SANITIZER=Undefined build, I see a segmentation fault.
$ env CLANG_LIBRARY_PATH=../../../../build-sanu/lib /usr/bin/python2.7 -m
unittest discover -v
testConstantArray (tests.cindex.test_type.TestType) ... ERROR
test_a_struct (tests.cindex.test_type.TestType) ... Segmentation fault (core
dumped)
LLVM was built, and the test was run, using:
export LLVM_ROOT=/path/to/llvm-7.0/build/
mkdir build-sanu
pushd build-sanu
cmake -G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_ASSERTIONS=ON \
-DCMAKE_C_COMPILER=$LLVM_ROOT/bin/clang \
-DCMAKE_CXX_COMPILER=$LLVM_ROOT/bin/clang++ \
-DLLVM_USE_SANITIZER=Undefined \
../.
popd
ninja -C build-sanu check-clang-python
The crash seems to occur in the following call to getenv() in
clang_createIndex():
3247 // We use crash recovery to make some of our APIs more reliable,
implicitly
3248 // enable it.
> 3249 if (!getenv("LIBCLANG_DISABLE_CRASH_RECOVERY"))
3250llvm::CrashRecoveryContext::Enable();
Backtrace (before stepi that results in segmentation fault):
(gdb) bt
#0 0x7fffee590d80 in getenv@plt () from /llvm/build-sanu/lib/libclang.so
#1 0x7fffee5f9491 in clang_createIndex () at
../tools/clang/tools/libclang/CIndex.cpp:3249
#2 0x765dfc7c in ffi_call_unix64 () from
/usr/lib/x86_64-linux-gnu/libffi.so.6
#3 0x765df5ac in ffi_call () from
/usr/lib/x86_64-linux-gnu/libffi.so.6
#4 0x767f65fe in _ctypes_callproc () from
/usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
#5 0x767f7f9e in ?? () from
/usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
#6 0x004c84a5 in PyEval_EvalFrameEx ()
The segmentation fault seems to be due to the PLT entry for getenv() being
broken (?):
(gdb) disas $pc
Dump of assembler code for function getenv@plt:
=> 0x7fffee590d80 <+0>: jmpq *0x62e2292(%rip)#
0x74873018 <_GLOBAL_OFFSET_TABLE_+48>
0x7fffee590d86 <+6>: pushq $0x3
0x7fffee590d8b <+11>:jmpq 0x7fffee590d40
End of assembler dump.
(gdb) x (void *) 0x74873018
0x74873018 <_GLOBAL_OFFSET_TABLE_+48>: 0x026a7d86
(gdb) x 0x026a7d86
0x26a7d86: Cannot access memory at address 0x26a7d86
This was seen when running on a Ubuntu 14.04.5 LTS installation. I have
unfortunately not been able to reproduce this on another machine yet.
I have tried building LLVM with a Clang 5.0 and a Clang 7.0 installation, with
the same results.
--
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 9880 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t"
Updates: Labels: Deadline-Approaching Comment #2 on issue 9880 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9880#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33811] clang www pages not updating
https://bugs.llvm.org/show_bug.cgi?id=33811 Mike Edwards changed: What|Removed |Added Resolution|--- |FIXED CC||m...@sqlby.me Status|NEW |RESOLVED --- Comment #2 from Mike Edwards --- I think we actually got this resolved a month or so ago. The problem was rooted in a permissions issue and a missing symbolic link on the server. -- 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 5565] clang website left menu doesn't show completely
https://bugs.llvm.org/show_bug.cgi?id=5565 Mike Edwards changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Mike Edwards --- I'm sure at some point we actually did "fix" this. I'm sorry I don't have details as to how we addressed the issue. Most likely Tanya just figured out what the problem was and resolved it. Please reopen if the problem can be reproduced some other way. -- 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 39560] New: address of label preventing inlining of __attribute__((always_inline)) static functions
https://bugs.llvm.org/show_bug.cgi?id=39560 Bug ID: 39560 Summary: address of label preventing inlining of __attribute__((always_inline)) static functions Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: ndesaulni...@google.com CC: echri...@gmail.com, isanb...@gmail.com, lloz...@chromium.org, llvm-bugs@lists.llvm.org, srhi...@google.com Example from the Linux kernel: https://godbolt.org/z/S8FRRs The kernel uses a GNU statement expression that returns the address of a label in many many places throughout the code bases. With Clang, it seems that taking the address of a block prevents a __attribute__((always_inline)) function from being inlined. -- 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 34278] ms-pdb: segfault if linking .obj compiled with precompiled header and /Z7
https://bugs.llvm.org/show_bug.cgi?id=34278 Alexandre Ganea changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Alexandre Ganea --- Fixed by https://reviews.llvm.org/rL346154 -- 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 39561] New: Super confusing diag when overload prevents template argument inference
https://bugs.llvm.org/show_bug.cgi?id=39561
Bug ID: 39561
Summary: Super confusing diag when overload prevents template
argument inference
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Someone asked me why this doesn't build:
$ cat parallel_merge_sort.cpp
#include
void mergesort(void *records, int start, int end, int threads) {
std::thread lthread(mergesort, records, start, end, threads);
};
$ clang++ -std=c++11 -c parallel_merge_sort.cpp
parallel_merge_sort.cpp:3:15: error: no matching constructor for initialization
of 'std::thread'
std::thread lthread(mergesort, records, start, end, threads);
^ ~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:353:9:
note: candidate template ignored: couldn't infer template argument '_Fp'
thread::thread(_Fp&& __f, _Args&&... __args)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:286:5:
note: candidate constructor not viable: requires 1 argument, but 5 were
provided
thread(const thread&);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:309:5:
note: candidate constructor not viable: requires single argument '__t', but 5
arguments were provided
thread(thread&& __t) _NOEXCEPT : __t_(__t.__t_) {__t.__t_ = 0;}
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/thread:293:5:
note: candidate constructor not viable: requires 0 arguments, but 5 were
provided
thread() _NOEXCEPT : __t_(0) {}
^
1 error generated.
It builds fine on Windows, on Linux with libc++ and libstd++, but doesn't build
on macOS or on the BSDs.
The reason is that BSD has a function named "mergesort" in its C standard
library, which makes inference of the first thread ctor candidate fail. Our
diagnostic here could be much better.
--
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 39562] New: LowerEmscriptenEHSjLj pass fails w/ emcc WASM_OBJECT_FILES=1 when there's only longjmp
https://bugs.llvm.org/show_bug.cgi?id=39562
Bug ID: 39562
Summary: LowerEmscriptenEHSjLj pass fails w/ emcc
WASM_OBJECT_FILES=1 when there's only longjmp
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: WebAssembly
Assignee: unassignedb...@nondot.org
Reporter: ahee...@gmail.com
CC: llvm-bugs@lists.llvm.org
When there is not setjmp call but only longjmp call in a module, such as
```
#include
struct Foo {
jmp_buf buffer;
};
__attribute__((used, visibility("default")))
void test_breakage(struct Foo *foo) {
volatile jmp_buf* jump_buffer = &foo->buffer;
longjmp(*jump_buffer, 1);
}
```
`emcc src/sjljehfail.c -O2 --profiling-funcs -o a.out.js -s
WASM_OBJECT_FILES=1` crashes with a segmentation fault.
--
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 39563] New: Evaluate stripping dead types from PDBs
https://bugs.llvm.org/show_bug.cgi?id=39563 Bug ID: 39563 Summary: Evaluate stripping dead types from PDBs Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org, ztur...@google.com When LLD makes a PDB, it includes all types from all objects and type server PDBs. When MSVC link.exe makes a PDB, it brings in types one at a time as they are referenced from symbol records, in our observations. This means LLD PDBs may include extra type information. This is less of a problem when compiling with clang, because clang only emits debug info for types that were required to be complete by default (-fstandalone-debug vs -flimit-debug-info). However, there can still be dead type info, especially when /OPT:REF is enabled, because that will cause the code and corresponding symbol records to be discarded at link time. Those symbol records may reference otherwise dead type information (lambda types especially). We should add a tool to llvm-pdbutil to calculate what percentage of type records and type record bytes are actually referenced by symbol records, and decide if it's worth spending time in the linker to strip this extra unreferenced info. I suspect that it won't be worth doing, but it'd be nice to build a tool to collect this data. -- 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 39564] New: Assert in Hot/cold splitting
https://bugs.llvm.org/show_bug.cgi?id=39564
Bug ID: 39564
Summary: Assert in Hot/cold splitting
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: ju...@samsung.com
CC: llvm-bugs@lists.llvm.org
Noticed that the IR below assert in the hot/cold split pass.
; opt -passes=hotcoldsplit -S assert.ll
define void @foo(i32 %cond) {
entry:
%tobool = icmp eq i32 %cond, 0
br i1 %tobool, label %if.end, label %coldbb
coldbb:
call void (...) @sink()
br i1 undef, label %if.end, label %coldbb2
coldbb2:
br label %if.end
if.end:
%p = phi i32 [0, %entry], [1, %coldbb], [3, %coldbb2]
ret void
}
declare void @sink(...) cold
--
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 39565] New: Foundation website SSL connections are not working.
https://bugs.llvm.org/show_bug.cgi?id=39565 Bug ID: 39565 Summary: Foundation website SSL connections are not working. Product: Website Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: General Website Assignee: unassignedb...@nondot.org Reporter: m...@sqlby.me CC: greg.bedw...@sony.com, llvm-bugs@lists.llvm.org, m...@sqlby.me, to...@nondot.org Depends on: 39309 If a user navigates to https://foundation.llvm.org thee user is redirected to the Bugzilla main page. If a user attempts to navigate manually to https://foundation.llvm.org/documents/ the user receives a 404 error. These are related issues and both appear to be caused by an apache misconfiguration. +++ This bug was initially created as a clone of Bug #39309 +++ This results in a number of links being incorrect. Steps to reproduce: 1) Navigate to "http://llvm.org/"; 2) Click link "Site Map > LLVM Foundation" 2a) Current URL is "http://llvm.org/foundation/"; 3) Click link "Site Map > Public Documents" 3a) Current URL is "http://foundation.llvm.org/documents/"; 4) Click link "Site Map > Main" 4a) Current URL is "http://foundation.llvm.org/index.html"; 5) Observe the "Useful Links" section in the sidebar. 5a) "Useful Links > LLVM.org" links to "http://foundation.llvm.org/"; 5b) "Useful Links > LLVM Foundation Home" links to "http://foundation.llvm.org/foundation/"; (404 error) 5c) "Useful Links > Relicensing Effort" links to "http://foundation.llvm.org/foundation/relicensing/"; (404 error) Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=39309 [Bug 39309] foundation page link goes to "http://foundation.llvm.org/documents/"; rather than "http://llvm.org/foundation/documents/"; -- 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 38857] [codeview] Incorrect variable locations with stack realignment and call-frame optimization
https://bugs.llvm.org/show_bug.cgi?id=38857 Reid Kleckner changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Reid Kleckner --- I confirmed that the offsets changed in r346062, here's the symbol records before and after: 0 | S_LOCAL [size = 26] `remaining_bytes` type=0x0023 (unsigned __int64), flags = none 0 | S_DEFRANGE_FRAMEPOINTER_REL [size = 16] offset = -12, range = [:0029,+343) gaps = 2 0 | S_LOCAL [size = 32] `remaining_bytes_again` type=0x0023 (unsigned __int64), flags = none 0 | S_DEFRANGE_FRAMEPOINTER_REL [size = 16] offset = -20, range = [:0029,+343) gaps = 2 after: 0 | S_LOCAL [size = 26] `remaining_bytes` type=0x0023 (unsigned __int64), flags = none 0 | S_DEFRANGE_FRAMEPOINTER_REL [size = 16] offset = -16, range = [:0029,+343) gaps = 2 0 | S_LOCAL [size = 32] `remaining_bytes_again` type=0x0023 (unsigned __int64), flags = none 0 | S_DEFRANGE_FRAMEPOINTER_REL [size = 16] offset = -24, range = [:0029,+343) gaps = 2 I had some trouble getting windbg to stop at the same point again, but eventually I succeeded and now I see this: 0:029> dv this = 0x11a43950 remaining_bytes = 0x15aa48 remaining_bytes_again = 0x0012`346678ab items = That looks right, so I'd say this is fixed. It should be in the next clang roll which is tracked at https://crbug.com/894363 -- 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 39567] New: Invalid getReturnTypeSourceRange for function with trailing return type
https://bugs.llvm.org/show_bug.cgi?id=39567
Bug ID: 39567
Summary: Invalid getReturnTypeSourceRange for function with
trailing return type
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Tooling
Assignee: unassignedclangb...@nondot.org
Reporter: steve...@gmail.com
CC: llvm-bugs@lists.llvm.org
Given this source file:
int foo();
auto bar() -> int;
and this clang-tidy check:
void FuncReturnRangeCheck::registerMatchers(MatchFinder *Finder) {
// FIXME: Add matchers.
Finder->addMatcher(functionDecl().bind("x"), this);
}
void FuncReturnRangeCheck::check(const MatchFinder::MatchResult &Result) {
// FIXME: Add callback implementation.
const auto *MatchedDecl = Result.Nodes.getNodeAs("x");
MatchedDecl->dump();
auto SR = MatchedDecl->getReturnTypeSourceRange();
SR.dump(*Result.SourceManager);
}
we get this output:
FunctionDecl 0x55dc893341f0 col:5 foo 'int (void)'
FunctionDecl 0x55dc89334350 col:6 bar 'auto
(void) -> int'
<>
The second source range should not be invalid.
FunctionDecl::getReturnTypeSourceRange returns an invalid range when the return
type is after the name info.
--
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
