[llvm-bugs] [Bug 46616] New: ARMDisassembler.cpp: DecodeThumbTableBranch improperly marks "tbb/w [pc, rx]" as SoftFailure
https://bugs.llvm.org/show_bug.cgi?id=46616 Bug ID: 46616 Summary: ARMDisassembler.cpp: DecodeThumbTableBranch improperly marks "tbb/w [pc, rx]" as SoftFailure Product: libraries Version: 10.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: getcho.getc...@gmail.com CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com, ties.st...@arm.com Symptom: In DecodeThumbTableBranch there is an improper check: if (Rn == ARM::SP) S = MCDisassembler::SoftFail; Since ARM::SP is an internal representation of the registers, it is not related in any way with the instruction encoding. Thus, when we have "tbb [pc, rx]" instruction, the value of Rn is 15, the value of ARM::SP is also 15 and the instruction is improperly marked as SoftFail. Solution: Since the SP in ARM is R13, and according to the encoding of the tbb instruction, the above line should be: if (Rn == 13) S = MCDisassembler::SoftFail; -- 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 46617] New: libcxx compile failed occasionally
https://bugs.llvm.org/show_bug.cgi?id=46617
Bug ID: 46617
Summary: libcxx compile failed occasionally
Product: libc++
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: changqing...@windriver.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Created attachment 23694
--> https://bugs.llvm.org/attachment.cgi?id=23694&action=edit
compile failed log
Hi,
With the same configure, it can always build successfully, only met one time
that libcxx compile failed. please see the log.
here is some configure option:
-DCMAKE_CROSSCOMPILING=ON
-DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
-DLIBUNWIND_ENABLE_SHARED=OFF
-DLIBUNWIND_ENABLE_THREADS=OFF
-DLIBUNWIND_WEAK_PTHREAD_LIB=ON
-DLIBUNWIND_ENABLE_CROSS_UNWINDING=ON
-DLIBCXXABI_INCLUDE_TESTS=OFF
-DLIBCXXABI_ENABLE_SHARED=ON
-DLIBCXXABI_USE_COMPILER_RT=ON
-DLIBCXXABI_LIBCXX_INCLUDES=${S}/libcxx/include
-DLIBCXX_CXX_ABI=libcxxabi
-DLIBCXX_USE_COMPILER_RT=ON
-DLIBCXX_CXX_ABI_INCLUDE_PATHS=${S}/libcxxabi/include
-DLIBCXX_CXX_ABI_LIBRARY_PATH=${B}/lib${LLVM_LIBDIR_SUFFIX}
-DCMAKE_AR=${STAGING_BINDIR_TOOLCHAIN}/${AR}
-DCMAKE_NM=${STAGING_BINDIR_TOOLCHAIN}/${NM}
-DCMAKE_RANLIB=${STAGING_BINDIR_TOOLCHAIN}/${RANLIB}
-DLLVM_ENABLE_PROJECTS='libcxx;libcxxabi;libunwind'
-DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
>From the log, build lib/libc++.so.1.0 failed when linking libc++abi.a,
According to the libcxx/src/CMakelist.txt,
LIBCXX_ENABLE_SHARED is ON,
LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY is OFF
so target_link_libraries(cxx_shared PUBLIC "${LIBCXX_CXX_SHARED_ABI_LIBRARY}")
LIBCXX_CXX_SHARED_ABI_LIBRARY is cxxabi
and both libcxxabi.so and libcxxabi.a will be generated under
LIBCXX_CXX_ABI_LIBRARY_PATH.
I guess the failure happened when libcxxabi.a is generated, and libcxxabi.so is
not generated. maybe we need add dependency to .so explicitly? I suspect that
target_link_libraries don't handle dependency 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46618] New: libcxx compile failed occasionally
https://bugs.llvm.org/show_bug.cgi?id=46618
Bug ID: 46618
Summary: libcxx compile failed occasionally
Product: libc++
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: changqing...@windriver.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Created attachment 23695
--> https://bugs.llvm.org/attachment.cgi?id=23695&action=edit
compile failed log
Hi,
With the same configure, it can always build successfully, only met one time
that libcxx compile failed. please see the log.
here is some configure option:
-DCMAKE_CROSSCOMPILING=ON
-DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
-DLIBUNWIND_ENABLE_SHARED=OFF
-DLIBUNWIND_ENABLE_THREADS=OFF
-DLIBUNWIND_WEAK_PTHREAD_LIB=ON
-DLIBUNWIND_ENABLE_CROSS_UNWINDING=ON
-DLIBCXXABI_INCLUDE_TESTS=OFF
-DLIBCXXABI_ENABLE_SHARED=ON
-DLIBCXXABI_USE_COMPILER_RT=ON
-DLIBCXXABI_LIBCXX_INCLUDES=${S}/libcxx/include
-DLIBCXX_CXX_ABI=libcxxabi
-DLIBCXX_USE_COMPILER_RT=ON
-DLIBCXX_CXX_ABI_INCLUDE_PATHS=${S}/libcxxabi/include
-DLIBCXX_CXX_ABI_LIBRARY_PATH=${B}/lib${LLVM_LIBDIR_SUFFIX}
-DCMAKE_AR=${STAGING_BINDIR_TOOLCHAIN}/${AR}
-DCMAKE_NM=${STAGING_BINDIR_TOOLCHAIN}/${NM}
-DCMAKE_RANLIB=${STAGING_BINDIR_TOOLCHAIN}/${RANLIB}
-DLLVM_ENABLE_PROJECTS='libcxx;libcxxabi;libunwind'
-DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
>From the log, build lib/libc++.so.1.0 failed when linking libc++abi.a,
According to the libcxx/src/CMakelist.txt,
LIBCXX_ENABLE_SHARED is ON,
LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY is OFF
so target_link_libraries(cxx_shared PUBLIC "${LIBCXX_CXX_SHARED_ABI_LIBRARY}")
LIBCXX_CXX_SHARED_ABI_LIBRARY is cxxabi
and both libcxxabi.so and libcxxabi.a will be generated under
LIBCXX_CXX_ABI_LIBRARY_PATH.
I guess the failure happened when libcxxabi.a is generated, and libcxxabi.so is
not generated. maybe we need add dependency to .so explicitly? I suspect that
target_link_libraries don't handle dependency 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46618] libcxx compile failed occasionally
https://bugs.llvm.org/show_bug.cgi?id=46618 Changqing Li changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Changqing Li --- *** This bug has been marked as a duplicate of bug 46617 *** -- 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 46619] New: Clang 10 (trunk) crashed (Godbolt link inside)
https://bugs.llvm.org/show_bug.cgi?id=46619 Bug ID: 46619 Summary: Clang 10 (trunk) crashed (Godbolt link inside) Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: C++17 Assignee: unassignedclangb...@nondot.org Reporter: llvm-bugzi...@renemeusel.de CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Godbolt shows a clang 10 stacktrace for the following code: https://godbolt.org/z/8az9zC I wanted to build a template helper to transform a std::variant of the form std::variant, type_tag, ...> into: std::variant . -- 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 46406] [X86] rsqrt and div generated for 1/sqrt(x * x * x) with -Ofast
https://bugs.llvm.org/show_bug.cgi?id=46406 Sanjay Patel changed: What|Removed |Added Fixed By Commit(s)||ea71ba11ab11 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sanjay Patel --- https://reviews.llvm.org/D82716 --- Comment #4 from Sanjay Patel --- https://reviews.llvm.org/rGea71ba11ab1187af03a790dc20967ddd62f68bfe -- 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 46524] [Scalarizer] Handling of variable insert/extracts?
https://bugs.llvm.org/show_bug.cgi?id=46524 Roman Lebedev changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||f62c8dbc99e 28b7816b782 ||6e504745813 51f9310ff2e ||5d7afe2d2e3 db05f2e34a5 Assignee|unassignedb...@nondot.org |lebedev...@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 46620] New: undefined reference to dumpToStream with LLVM_ENABLE_MODULES
https://bugs.llvm.org/show_bug.cgi?id=46620 Bug ID: 46620 Summary: undefined reference to dumpToStream with LLVM_ENABLE_MODULES Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: tras...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Ubuntu 20.04 $ CC=clang CXX=clang++ cmake -DLLVM_ENABLE_PROJECTS="clang;compiler-rt;lld;clang-tools-extra" -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_DUMP=ON -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_BENCHMARKS=OFF -DLLVM_INCLUDE_DOCS=OFF -DLLVM_INCLUDE_TESTS=OFF -DCLANG_INCLUDE_TESTS=OFF -DCLANG_INCLUDE_DOCS=OFF -DCLANG_ENABLE_ARCMT=OFF -DLLVM_ENABLE_MODULES=ON -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/opt/clang -DCMAKE_CXX_FLAGS=-march=native -ftime-trace -Og -DLLVM_BINUTILS_INCDIR=/usr/include -DLLVM_USE_SPLIT_DWARF=ON -DLLVM_ENABLE_LLD=ON -DBUILD_SHARED_LIBS=ON -GNinja ../llvm tools/clang/lib/Frontend/CMakeFiles/obj.clangFrontend.dir/ASTConsumers.cpp.o: in function `clang::ento::CheckerInfo::dump() const': clang/include/clang/StaticAnalyzer/Core/CheckerRegistryData.h:138: undefined reference to `clang::ento::CheckerInfo::dumpToStream(llvm::raw_ostream&) const' tools/clang/lib/Frontend/CMakeFiles/obj.clangFrontend.dir/ASTConsumers.cpp.o: in function `clang::ento::CmdLineOption::dump() const': clang/include/clang/StaticAnalyzer/Core/CheckerRegistryData.h:79: undefined reference to `clang::ento::CmdLineOption::dumpToStream(llvm::raw_ostream&) const' tools/clang/lib/Frontend/CMakeFiles/obj.clangFrontend.dir/ASTConsumers.cpp.o: in function `clang::ento::PackageInfo::dump() const': clang/include/clang/StaticAnalyzer/Core/CheckerRegistryData.h:158: undefined reference to `clang::ento::PackageInfo::dumpToStream(llvm::raw_ostream&) const' https://github.com/Trass3r/llvm-project/runs/842487895 works without modules: https://github.com/Trass3r/llvm-project/runs/845192334 -- 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 23797 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::FormTokenWithChars
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 23797 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::FormTokenWithChars https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23797#c1 ClusterFuzz testcase 6503755125358592 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202007060156:202007070159 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 46621] New: [X86][AVX] Avoid vpsrlq $32, %xmm, %xmm split in v4u64 uint2fp v4f64
https://bugs.llvm.org/show_bug.cgi?id=46621
Bug ID: 46621
Summary: [X86][AVX] Avoid vpsrlq $32, %xmm, %xmm split in v4u64
uint2fp v4f64
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: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Codegen: https://godbolt.org/z/Kz72eo
For AVX1 only targets, the v4u64 -> v4f64 uint2fp conversion:
define <4 x double> @cvt_v4u64_v4f64(4 x i64> %0) {
%2 = uitofp <4 x i64> %0 to <4 x double>
ret <4 x double> %2
}
cvt_v4u64_v4f64:
vxorps %xmm1, %xmm1, %xmm1
vblendps $170, %ymm1, %ymm0, %ymm1 # ymm1 =
ymm0[0],ymm1[1],ymm0[2],ymm1[3],ymm0[4],ymm1[5],ymm0[6],ymm1[7]
vpsrlq $32, %xmm0, %xmm2
vextractf128 $1, %ymm0, %xmm0
vorps .LCPI0_0(%rip), %ymm1, %ymm1
vpsrlq $32, %xmm0, %xmm0
vinsertf128 $1, %xmm0, %ymm2, %ymm0
vorpd .LCPI0_1(%rip), %ymm0, %ymm0
vsubpd .LCPI0_2(%rip), %ymm0, %ymm0
vaddpd %ymm0, %ymm1, %ymm0
retq
we should be able to avoid the extractf128+2*vpsrlq and perform this as 256-bit
vshufps*2 instead, reducing register pressure.
I'm not sure yet whether this is better to handle in shuffle combining, in
TargetLowering::expandUINT_TO_FP or shift lowering.
--
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 46622] New: [X86] Support -mstack-protector-guard=global
https://bugs.llvm.org/show_bug.cgi?id=46622 Bug ID: 46622 Summary: [X86] Support -mstack-protector-guard=global Product: libraries Version: trunk Hardware: PC OS: Linux 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 By default the stack protector on X86 on LInux uses a canary from Thread Local Storage. But this isn't suitable for all environments. gcc supports -mstack-protector-guard=global to use __stack_chk_guard variable instead. -- 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 46623] New: Format options for attributes, ability to specify custom attributes.
https://bugs.llvm.org/show_bug.cgi?id=46623 Bug ID: 46623 Summary: Format options for attributes, ability to specify custom attributes. Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: alliepipe...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Clang-format currently does not have options to control attribute formatting. Some projects prefer to put prefix attributes on a separate line, eg: [[nodiscard]] int foo(); instead of: [[nodiscard]] int foo(); Additionally, it would be useful to be able to provide a list of regexes that identify custom attributes. Maintaining an exhaustive list of attributes in clang-format proper would be daunting, as many projects hide them behind macros for backward compatibility, or rely on platform-specific attributes. Allowing projects to extend the list of recognized attributes would be quite useful. My personal interest in this stems from using clang-format on CUDA projects, where `__host__ __device__` annotations are frequently used and commonly placed on the line above a function definition. Being able to achieve this common formatting style would ease adoption of clang-format by CUDA projects. -- 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 46586] [x86] Clang produces wrong code with -O1
https://bugs.llvm.org/show_bug.cgi?id=46586 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Sanjay Patel --- (In reply to Vsevolod Livinskiy from comment #10) > Now it works. > > Thank you very much! Thanks for finding the bug. I've updated the title/component for help in future searches. -- 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 46624] New: Clang crashes when trying to use variadic arguments from std::apply to fold over lambda in template method.
https://bugs.llvm.org/show_bug.cgi?id=46624
Bug ID: 46624
Summary: Clang crashes when trying to use variadic arguments
from std::apply to fold over lambda in template
method.
Product: clang
Version: 10.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: rob.klein.ik...@student.nhlstenden.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Created attachment 23696
--> https://bugs.llvm.org/attachment.cgi?id=23696&action=edit
The attached ZIP contains 4 files: source.cpp is the source code used to
trigger the crash. output.txt is Clangs console output. source-5aa368.(cpp/sh)
are the files requested in the error message.
Clang crashes when trying to use the values produced by std::apply to fold over
a lambda, using the produced values as captures.
The following code will trigger the crash if called:
template void f(const std::tuple& tpl) {
std::apply([&](const auto&... values){
([x = values](){ /* Use X */ }(), ...);
}, tpl);
}
An example of the crash can be seen at: https://godbolt.org/z/AaGSKJ
This code compiles correctly with GCC and MSVC.
The crash only occurs if the method is a template, but the type of tpl does not
have to depend on the template parameters to trigger the crash.
Passing the parameters to the lambda as function arguments does not trigger the
crash.
Clang produces the following error message:
Stack dump:
0. Program arguments: C:\Program Files\LLVM\bin\clang++.exe -cc1 -triple
x86_64-pc-windows-msvc19.26.28806 -emit-obj -mrelax-all
-mincremental-linker-compatible -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name source.cpp -mrelocation-model pic
-pic-level 2 -mthread-model posix -mframe-pointer=none -fmath-errno
-fno-rounding-math -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -dwarf-column-info -resource-dir C:\Program
Files\LLVM\lib\clang\10.0.0 -internal-isystem C:\Program
Files\LLVM\lib\clang\10.0.0\include -internal-isystem C:\Program Files
(x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include
-internal-isystem C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\atlmfc\include
-internal-isystem C:\Program Files (x86)\Windows
Kits\10\Include\10.0.18362.0\ucrt -internal-isystem C:\Program Files
(x86)\Windows Kits\10\include\10.0.18362.0\shared -internal-isystem C:\Program
Files (x86)\Windows Kits\10\include\10.0.18362.0\um -internal-isystem
C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt -std=c++2a
-fdeprecated-macro -fdebug-compilation-dir
C:\Users\Rob\source\repos\clang-crasher -ferror-limit 19 -fmessage-length 0
-fno-use-cxa-atexit -fms-extensions -fms-compatibility
-fms-compatibility-version=19.26.28806 -fdelayed-template-parsing
-fno-implicit-modules -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -faddrsig -o
C:\Users\Rob\AppData\Local\Temp\source-058b35.o -x c++ source.cpp
1. parser at end of file
2. source.cpp:6:32: instantiating function definition 'f'
3. C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\tuple:949:26:
instantiating function definition 'std::apply<(lambda at source.cpp:7:16),
const std::tuple &>'
4. C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\tuple:942:26:
instantiating function definition 'std::_Apply_impl<(lambda at
source.cpp:7:16), const std::tuple &, 0, 1, 2, 3>'
5. source.cpp:7:16: instantiating function definition 'f(const
std::tuple &)::(anonymous class)::operator()'
#0 0x000142f93a1f C:\Program Files\LLVM\bin\clang++.exe 0x3293a1f
C:\Program Files\LLVM\bin\clang++.exe 0x2da23d1
#1 0x000142f93a1f C:\Program Files\LLVM\bin\clang++.exe 0x2eb30ff
C:\Program Files\LLVM\bin\clang++.exe 0x2eae533
#2 0x000142f93a1f C:\Program Files\LLVM\bin\clang++.exe 0x2eac293
C:\Program Files\LLVM\bin\clang++.exe 0x2ec4fec
#3 0x000142f93a1f C:\Program Files\LLVM\bin\clang++.exe 0x2ec9660
C:\Program Files\LLVM\bin\clang++.exe 0x2eac37b
#4 0x000142f93a1f C:\Program Files\LLVM\bin\clang++.exe 0x2eac217
C:\Program Files\LLVM\bin\clang++.exe 0x2f5c4cf
#5 0x000142f93a1f C:\Program Files\LLVM\bin\clang++.exe 0x2feb829
C:\Program Files\LLVM\bin\clang++.exe 0x2953a9d
#6 0x000142f93a1f C:\Program Files\LLVM\bin\clang++.exe 0x2fab363
C:\Program Files\LLVM\bin\clang++.exe 0x2caef07
#7 0x000142f93a1f C:\Program Files\LLVM\bin\clang++.exe 0x2f8a9c5
C:\Program Files\LLVM\bin\clang++.exe 0x2f925dd
#8 0x000142f93a1f C:\Program Files\LLVM\bin\clang++.exe 0x2cb638b
C:\Program Files\LLVM\bin\clan
[llvm-bugs] [Bug 28432] load-store ordering for top-down list latency scheduler mis-schedules store for x86_64
https://bugs.llvm.org/show_bug.cgi?id=28432 Shoaib Meenai changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Shoaib Meenai --- https://reviews.llvm.org/D45022 fixed this 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46625] New: segv in string move-constructor with _LIBCPP_DEBUG=1
https://bugs.llvm.org/show_bug.cgi?id=46625
Bug ID: 46625
Summary: segv in string move-constructor with _LIBCPP_DEBUG=1
Product: libc++
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: gray...@pobox.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
I believe this program winds up move-constructing over a non-small string in
LHS
of the + operator and something about this disagrees with the strings (or more
specifically the iterator-debugging machinery within the strings) produced by
std::to_string. I haven't been able to narrow it down further or determine
cause:
Example program:
#include
void use(std::string const& out) {}
int main() {
use("0123456789012345678901" + std::to_string(1));
}
Example compile command:
$ clang++-9 -stdlib=libc++ -D_LIBCPP_DEBUG=1 t.cpp
Example run:
$ ./a.out
Segmentation fault (core dumped)
With sanitizer:
$ clang++-9 -stdlib=libc++ -D_LIBCPP_DEBUG=1 -fsanitize=address t.cpp
$ ./a.out
AddressSanitizer:DEADLYSIGNAL
=
==42275==ERROR: AddressSanitizer: SEGV on unknown address 0x0008 (pc
0x7f2c525e7647 bp 0x7fff815df6f0 sp 0x7fff815df680 T0)
==42275==The signal is caused by a READ memory access.
==42275==Hint: address points to the zero page.
#0 0x7f2c525e7646 in std::__1::__libcpp_db::swap(void*, void*)
libcxx/build/src/./libcxx/src/debug.cpp:463:18
#1 0x4c6603 in std::__1::basic_string,
std::__1::allocator >::basic_string(std::__1::basic_string, std::__1::allocator >&&)
(/home/src/stellar-core/a.out+0x4c6603)
#2 0x4c5f55 in std::__1::basic_string,
std::__1::allocator > std::__1::operator+, std::__1::allocator >(char const*,
std::__1::basic_string,
std::__1::allocator >&&) (/home/src/stellar-core/a.out+0x4c5f55)
#3 0x4c5d50 in main (/home/src/stellar-core/a.out+0x4c5d50)
#4 0x7f2c513c0b96 in __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#5 0x41bcf9 in _start (/home/src/stellar-core/a.out+0x41bcf9)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV libcxx/build/src/./libcxx/src/debug.cpp:463:18
in std::__1::__libcpp_db::swap(void*, void*)
==42275==ABORTING
--
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 43388] __muldsi3 is compiled to call itself when targeting riscv64
https://bugs.llvm.org/show_bug.cgi?id=43388 Kamlesh Kumar changed: What|Removed |Added Assignee|unassignedb...@nondot.org |kamleshbha...@gmail.com CC||kamleshbha...@gmail.com Luís Marques changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Luís Marques --- Fixed by D80465 / rGe31ccee1b01a. -- 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 46626] New: Missed optimization: CorrelatedValuePropagationPass doesn't run by default after inlining
https://bugs.llvm.org/show_bug.cgi?id=46626
Bug ID: 46626
Summary: Missed optimization: CorrelatedValuePropagationPass
doesn't run by default after inlining
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: v...@tsyrklevich.net
CC: llvm-bugs@lists.llvm.org
The following reproducer:
$ cat ex.c
static int a;
static int *b(int *c) { return c; }
int foo() {
if (a == 0)
a = 2;
return *b(&a);
}
demonstrates a missed optimization due to not running the
CorrelatedValuePropagationPass after inlining. Compiled to IR, it looks like:
$ clang -S -emit-llvm ex.c -o ex.ll -O2
$ cat ex.ll
...
define i32 @foo() local_unnamed_addr #0 {
%1 = load i1, i1* @a, align 4
%2 = select i1 %1, i32 2, i32 0
br i1 %1, label %4, label %3
3:; preds = %0
store i1 true, i1* @a, align 4
br label %4
4:; preds = %0, %3
%5 = phi i32 [ 2, %3 ], [ %2, %0 ]
ret i32 %5
}
...
By running opt on this clang -O2 output, we get simpler IR:
$ cat ex.ll | opt -S -O2
...
define i32 @foo() local_unnamed_addr #0 {
%1 = load i1, i1* @a, align 4
br i1 %1, label %3, label %2
2:; preds = %0
store i1 true, i1* @a, align 4
br label %3
3:; preds = %2, %0
ret i32 2
}
...
The difference between the IR for these 2 functions results in the first being
12 bytes larger when compiled on AArch64. The following trivial change 'fixes'
the reproducer given above, but I'm not clear on where in the pipeline the
CorrelatedValuePropagationPass actually belongs. This diff merely shows the
earliest point that pass can be added which fixes the reproducer.
--- a/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
+++ b/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
@@ -668,6 +668,7 @@ void PassManagerBuilder::populateModulePassManager(
// faster.
if (RunInliner) {
MPM.add(createGlobalOptimizerPass());
+MPM.add(createCorrelatedValuePropagationPass());
MPM.add(createGlobalDCEPass());
}
--
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 45521] [c++17] can't implicitly cast lvalue to rvalue with this cast kind
https://bugs.llvm.org/show_bug.cgi?id=45521 Richard Smith changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Richard Smith --- Fixed in 065fc1eafe7c6f67f8029bcd38e6864b3c429e35. -- 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 46627] New: Invalid optimization with math library `fmax` and signed zeros
https://bugs.llvm.org/show_bug.cgi?id=46627
Bug ID: 46627
Summary: Invalid optimization with math library `fmax` and
signed zeros
Product: clang
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mped...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Created attachment 23697
--> https://bugs.llvm.org/attachment.cgi?id=23697&action=edit
Preprocessed source for the example program
My simple test program gives different results depending on whether I enable
optimizations with -O, in the presence of -fno-builtin-fmax. The program is as
follows (preprocessed source attached):
#include
#include
int main(int argc __attribute__((unused)), char **argv
__attribute__((unused))) {
const double a = fmax(0.0, -0.0);
const double b = 1.0 / a;
const int c = isinf(b);
printf("Is b (%a) infinite? isinf() says: %d\n", b, c);
return 0;
}
No matter whether fmax returns 0.0 or -0.0, I expect b to be infinite and
isinf(b) to return a nonzero value. If I compile this program without
optimizations, running it displays
Is b (-inf) infinite? isinf() says: -1
as expected. If I enable optimizations with -O and disable compile-time
evaluation with -fno-builtin-fmax, running it displays
Is b (-inf) infinite? isinf() says: 0
If I pass the arguments to fmax in the opposite order
const double a = fmax(-0.0, 0.0);
then isinf() returns 1 as expected. If I assign 0.0 or -0.0 to a some other
way than by calling fmax(), then isinf() returns nonzero as expected. The
example program in the similarly-titled
https://bugs.llvm.org/show_bug.cgi?id=37776 works correctly independent of
optimization settings.
The attached file test.i is the preprocessed source file. The test program
compiles without errors or warning and never triggers the undefined-behavior
sanitizer. The compiler invocation and complete output follows:
clang-10 -v -save-temps -O -fno-builtin-isinf -fno-builtin-fmax -std=c11 -o
test -fstack-protector-all -fstrict-overflow -D_FORTIFY_SOURCE=2 -fPIC
-fsanitize=undefined -fsanitize=address -Wall -Wextra -Werror -Wimplicit
-Wshadow -Wswitch-default test.c -lm
clang version 10.0.0-4
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
"/usr/lib/llvm-10/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -E
-save-temps=cwd -disable-free -disable-llvm-verifier -discard-value-names
-main-file-name test.c -mrelocation-model pic -pic-level 2 -mthread-model posix
-mframe-pointer=none -fmath-errno -fno-rounding-math -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info
-fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir
/usr/lib/llvm-10/lib/clang/10.0.0 -D _FORTIFY_SOURCE=2 -internal-isystem
/usr/local/include -internal-isystem /usr/lib/llvm-10/lib/clang/10.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2
-Wall -Wextra -Werror -Wimplicit -Wshadow -Wswitch-default -std=c11
-fdebug-compilation-dir /home/peddie -ferror-limit 19 -fmessage-length 0
-fsanitize=address,alignment,array-bounds,bool,builtin,enum,float-cast-overflow,function,in
[llvm-bugs] [Bug 46628] New: check-builtins fails on musl libc system
https://bugs.llvm.org/show_bug.cgi?id=46628 Bug ID: 46628 Summary: check-builtins fails on musl libc system Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: builtins Assignee: unassignedb...@nondot.org Reporter: p.way...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 23699 --> https://bugs.llvm.org/attachment.cgi?id=23699&action=edit Patch to disable glibc check when using musl I am cross-compiling the compiler-rt builtins for armv6m on an Alpine Linux docker image following the https://llvm.org/docs/HowToCrossCompileBuiltinsOnArm.html guide. The builtins compile and link successfully but running `ninja check-builtins` emits the following error: llvm-lit: /tmp/llvm-project/build-rt/bin/../../llvm/utils/lit/lit/TestingConfig.py:99: fatal: unable to parse config file '/tmp/llvm-project/compiler-rt/test/lit.common.cfg.py', traceback: Traceback (most recent call last): File "/tmp/llvm-project/build-rt/bin/../../llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path exec(compile(data, path, 'exec'), cfg_globals, None) File "/tmp/llvm-project/compiler-rt/test/lit.common.cfg.py", line 398, in ver_line = sout.splitlines()[0] IndexError: list index out of range I ran lines 394:397 from compiler-rt/test/lit.common.cfg.py by hand and found that `sout` is an empty string which explains the IndexError. I tried running `ldd --version` in the terminal, but this command does not exist for the musl ldd (ld-musl-x86_64.so.1) and output goes to stderr instead of stdout. I found a workaround to this problem by adding a guard before `ver_line = sout.splitlines()[0]` to check that the length of sout is greater than zero. Please see the attached patch. Cmake options are as follows: cmake -GNinja ../compiler-rt \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY \ -DCOMPILER_RT_OS_DIR="baremetal" \ -DCOMPILER_RT_BUILD_BUILTINS=ON \ -DCOMPILER_RT_BUILD_SANITIZERS=OFF \ -DCOMPILER_RT_BUILD_XRAY=OFF \ -DCOMPILER_RT_BUILD_LIBFUZZER=OFF \ -DCOMPILER_RT_BUILD_PROFILE=OFF \ -DCMAKE_C_COMPILER=/usr/bin/clang \ -DCMAKE_C_COMPILER_TARGET="armv6m-none-eabi" \ -DCMAKE_ASM_COMPILER_TARGET="armv6m-none-eabi" \ -DCMAKE_AR=/usr/bin/llvm-ar \ -DCMAKE_NM=/usr/bin/llvm-nm \ -DCMAKE_RANLIB=/usr/bin/llvm-ranlib \ -DCOMPILER_RT_BAREMETAL_BUILD=ON \ -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON \ -DCMAKE_C_FLAGS="-I/tmp/gcc-arm-none-eabi-9-2020-q2-update/arm-none-eabi/include --target=armv6-none-eabi" \ -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld" \ -DCMAKE_ASM_FLAGS="" \ -DLLVM_CONFIG_PATH=/usr/bin/llvm-config \ -DLLVM_MAIN_SRC_DIR="../llvm" \ -DCOMPILER_RT_EMULATOR="qemu-arm -L /tmp/gcc-arm-8.2-2019.01-x86_64-arm-linux-gnueabi/arm-linux-gnueabi/libc" \ -DCOMPILER_RT_INCLUDE_TESTS=ON \ -DCOMPILER_RT_TEST_COMPILER=/usr/bin/clang \ -DCOMPILER_RT_TEST_COMPILER_CFLAGS="--target=arm-linux-gnueabi -march=armv7a -mthumb -mfloat-abi=soft -mfpu=none -fuse-ld=lld \ --sysroot=/tmp/gcc-arm-8.2-2019.01-x86_64-arm-linux-gnueabi/arm-linux-gnueabi/libc \ --gcc-toolchain=/tmp/gcc-arm-8.2-2019.01-x86_64-arm-linux-gnueabi" -- 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 46629] New: Syntax warning in TableGen'd XXGenMCCodeEmitter.inc calling APInt LoadIntFromMemory utility function
https://bugs.llvm.org/show_bug.cgi?id=46629 Bug ID: 46629 Summary: Syntax warning in TableGen'd XXGenMCCodeEmitter.inc calling APInt LoadIntFromMemory utility function Product: tools Version: 10.0 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: TableGen Assignee: unassignedb...@nondot.org Reporter: chris.se...@gmail.com CC: llvm-bugs@lists.llvm.org TableGen supports large instructions, in my case, bits<128> Inst; This makes TableGen generate APInt Insts rather than uint64_t or smaller. This is rarely exercised code and so when I include the generated XXGenMCCodeEmitter.inc file, I get a warning: warning: cast from 'const unsigned long long *' to 'unsigned char *' drops const qualifier [-Wcast-qual] LoadIntFromMemory(Inst, (uint8_t*)&InstBits[opcode * 2], 16); It's complaining because InstBits is declared as static const uint64_t InstBits[] whereas LoadIntFromMemory()'s second argument is declared as uint8_t *Src Removing the const from InstBits does make the error message go away but it seems to me that adding const to the LoadIntFromMemory Src argument is the better solution. However, that may cause more warnings. -- 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 46630] New: call_apsr.S fails to build during builtins test
https://bugs.llvm.org/show_bug.cgi?id=46630
Bug ID: 46630
Summary: call_apsr.S fails to build during builtins test
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: builtins
Assignee: unassignedb...@nondot.org
Reporter: p.way...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 23700
--> https://bugs.llvm.org/attachment.cgi?id=23700&action=edit
cmake arguments
I successful built and linked the compiler-rt builtins for armv6m using an
Alpine Linux docker image. Most of the tests pass, but I still have four
failures.
Failed Tests (4):
Builtins-armv6m-linux :: arm/aeabi_cdcmpeq_test.c
Builtins-armv6m-linux :: arm/aeabi_cdcmple_test.c
Builtins-armv6m-linux :: arm/aeabi_cfcmpeq_test.c
Builtins-armv6m-linux :: arm/aeabi_cfcmple_test.c
Testing Time: 10.56s
Unsupported : 94
Passed : 104
Expectedly Failed: 1
Failed : 4
Looking at the fail logs, I can see that call_apsr.S could not be compiled
correctly.
: 'RUN: at line 2'; /usr/bin/clang -c -march=armv6m
/tmp/llvm-project/compiler-rt/test/builtins/Unit/arm/call_apsr.S -o
/tmp/llvm-project/build-rt/test/builtins/Unit/ARMV6MLinuxConfig/arm/Output/aeabi_cfcmple_test.c.tmp.aspr.o
Trying the above compilation command directly from the terminal gives the
following error:
error: unknown target CPU 'armv6m'
note: valid target CPU values are: nocona, core2, penryn, bonnell, atom,
silvermont, slm, goldmont, goldmont-plus,
tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge,
core-avx-i, haswell, core-avx2,
broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake,
cannonlake, icelake-client, icelake-server,
tigerlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3,
athlon64-sse3, opteron-sse3, amdfam10,
barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1,
znver2, x86-64
All these targets are x86 which indicates that clang is targeting the host
machine.
I found the relative code in compiler-rt/test/builtins/Unit/lit.cfg.py lines
84:90.
# FIXME: move the call_apsr.s into call_apsr.h as inline-asm.
# some ARM tests needs call_apsr.s
call_apsr_source = os.path.join(builtins_lit_source_dir, 'arm', 'call_apsr.S')
march_flag = '-march=' + target_arch
call_apsr_flags = ['-c', march_flag, call_apsr_source]
config.substitutions.append( ("%arm_call_apsr ", \
build_invocation(call_apsr_flags)) )
So lit.cfg.py is calling clang with an -march argument and no -target argument.
I can solve the issue and successfully build and run the tests by adding
--target=arm-none-eabi to the call_apsr_flags list, but this is not an
acceptable argument if compiling with gcc.
--
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
