Hans Wennborg via llvm-dev
2016-Jul-29 22:57 UTC
[llvm-dev] [3.9 Release] Release Candidate 1 has been tagged
Dear testers, 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. This took a little longer than I'd hoped, but I think the branch is in a decent state now. There are still open merge requests and bugs, but I'd like to get the real testing started to see where we're at. Please build, test, and upload binaries to the sftp. Let me know how it goes. I'll upload source, docs, and your binaries to the pre-release page once they're ready. Thanks, Hans
Ed Schouten via llvm-dev
2016-Jul-31 10:01 UTC
[llvm-dev] [3.9 Release] Release Candidate 1 has been tagged
Hi Hans, 2016-07-30 0:57 GMT+02:00 Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org>:> There are still open merge requests and bugs, but I'd like to get the > real testing started to see where we're at.Just to double-check, is this bug also on people's radar? It causes Clang to crash when trying to build a fair number of Open Source packages/libraries. In my opinion it's a blocker for 3.9. https://llvm.org/bugs/show_bug.cgi?id=28617 -- Ed Schouten <ed at nuxi.nl> Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717
Renato Golin via llvm-dev
2016-Jul-31 19:38 UTC
[llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On 29 July 2016 at 23:57, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote:> There are still open merge requests and bugs, but I'd like to get the > real testing started to see where we're at.First wave of testing pass on ARM. Uploaded to the FTP server. Is it time to do the back-ports planned? I only have a very minor bug fix. cheers, --renato
Dimitry Andric via llvm-dev
2016-Jul-31 20:35 UTC
[llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On 31 Jul 2016, at 12:01, Ed Schouten via Release-testers <release-testers at lists.llvm.org> wrote:> > 2016-07-30 0:57 GMT+02:00 Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org>: >> There are still open merge requests and bugs, but I'd like to get the >> real testing started to see where we're at. > > Just to double-check, is this bug also on people's radar? It causes > Clang to crash when trying to build a fair number of Open Source > packages/libraries. In my opinion it's a blocker for 3.9. > > https://llvm.org/bugs/show_bug.cgi?id=28617Added as a dependency of http://llvm.org/PR28600, the release blockers metabug. -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160731/8eadf81d/attachment.sig>
Bernhard Rosenkränzer via llvm-dev
2016-Jul-31 22:50 UTC
[llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
Hi, On the OpenMandriva side, x86_64 passes all checks. We're having some problems with other architectures though (see below): x86_64 succeeded, packages are here: https://abf.openmandriva.org/build_lists/76792 i586 fails to build, but this seems to be an issue with 3.8.1 (which we're using to build 3.9): /usr/bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support -Iinclude -I../include -Os -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++1y -fcolor-diagnostics -ffunction-sections -fdata-sections -Os -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -MD -MT lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -MF lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -o lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -c ../lib/Support/PrettyStackTrace.cpp clang-3.8: ../include/llvm/CodeGen/MachineOperand.h:411: int64_t llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong MachineOperand accessor"' failed. #0 0xfffffffff4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/libLLVMSupport.so.3.8+0x95075) #1 0xfffffffff4abd2c7 (/usr/lib/libLLVMSupport.so.3.8+0x952c7) #2 0xfffffffff4abbbf1 llvm::sys::RunSignalHandlers() (/usr/lib/libLLVMSupport.so.3.8+0x93bf1) #3 0xfffffffff4abbf49 (/usr/lib/libLLVMSupport.so.3.8+0x93f49) #4 0xfffffffff7714d20 0xd20 __GI_raise #5 0xfffffffff7714d20 #6 0xfffffffff7714d20 __GI_abort (+0xd20) #7 0xfffffffff4650ef0 __GI___assert_fail (/lib/libc.so.6+0x26ef0) #8 0xfffffffff46520e5 __GI___assert_perror_fail (/lib/libc.so.6+0x280e5) #9 0xfffffffff464b126 (/lib/libc.so.6+0x21126) #10 0xfffffffff464b162 llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr const*) const (/lib/libc.so.6+0x21162) #11 0xfffffffff65a0db6 (/usr/lib/libLLVMX86CodeGen.so.3.8+0x30db6) #12 0xfffffffff667640d (/usr/lib/libLLVMX86CodeGen.so.3.8+0x10640d) #13 0xfffffffff61029dc llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/lib/libLLVMCodeGen.so.3.8+0x1739dc) #14 0xfffffffff6105002 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/lib/libLLVMCodeGen.so.3.8+0x176002) #15 0xfffffffff60ab337 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/lib/libLLVMCodeGen.so.3.8+0x11c337) #16 0xfffffffff50d7e6f llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/libLLVMCore.so.3.8+0x19de6f) #17 0xfffffffff50d816b llvm::legacy::PassManager::run(llvm::Module&) (/usr/lib/libLLVMCore.so.3.8+0x19e16b) #18 0xfffffffff50d857f clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) (/usr/lib/libLLVMCore.so.3.8+0x19e57f) #19 0xfffffffff50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734) #20 0xfffffffff59fc72c clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/libclangCodeGen.so.3.8+0x6972c) #21 0xfffffffff5b2cd85 clang::ASTFrontendAction::ExecuteAction() (/usr/lib/libclangCodeGen.so.3.8+0x199d85) #22 0xfffffffff3b2b294 clang::CodeGenAction::ExecuteAction() (/usr/lib/libclangParse.so.3.8+0x24294) #23 0xfffffffff582583e clang::FrontendAction::Execute() (/usr/lib/libclangFrontend.so.3.8+0x8783e) #24 0xfffffffff5b2d3e1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/libclangCodeGen.so.3.8+0x19a3e1) #25 0xfffffffff5826660 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/libclangFrontend.so.3.8+0x88660) #26 0xfffffffff58029e1 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/lib/libclangFrontend.so.3.8+0x649e1) #27 0xfffffffff579aead main (/usr/lib/libclangFrontendTool.so.3.8+0x2ead) #28 0x08057178 __libc_start_main (/usr/bin/clang-3.8+0x8057178) #29 0x08052a9b _start (/usr/bin/clang-3.8+0x8052a9b) 0 libLLVMSupport.so.3.8 0xf4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 libLLVMSupport.so.3.8 0xf4abd2c7 2 libLLVMSupport.so.3.8 0xf4abbbf1 llvm::sys::RunSignalHandlers() + 60 3 libLLVMSupport.so.3.8 0xf4abbf49 4 0xf7714d20 __kernel_sigreturn + 0 5 libc.so.6 0xf4650ef0 gsignal + 73 6 libc.so.6 0xf46520e5 abort + 278 7 libc.so.6 0xf464b126 __assert_fail + 0 8 libc.so.6 0xf464b162 __assert_perror_fail + 0 9 libLLVMX86CodeGen.so.3.8 0xf65a0db6 10 libLLVMX86CodeGen.so.3.8 0xf667640d llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr const*) const + 365 11 libLLVMCodeGen.so.3.8 0xf61029dc 12 libLLVMCodeGen.so.3.8 0xf6105002 13 libLLVMCodeGen.so.3.8 0xf60ab337 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 169 14 libLLVMCore.so.3.8 0xf50d7e6f llvm::FPPassManager::runOnFunction(llvm::Function&) + 243 15 libLLVMCore.so.3.8 0xf50d816b llvm::FPPassManager::runOnModule(llvm::Module&) + 47 16 libLLVMCore.so.3.8 0xf50d857f llvm::legacy::PassManagerImpl::run(llvm::Module&) + 445 17 libLLVMCore.so.3.8 0xf50d8734 llvm::legacy::PassManager::run(llvm::Module&) + 32 18 libclangCodeGen.so.3.8 0xf59fc72c clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) + 8185 19 libclangCodeGen.so.3.8 0xf5b2cd85 20 libclangParse.so.3.8 0xf3b2b294 clang::ParseAST(clang::Sema&, bool, bool) + 624 21 libclangFrontend.so.3.8 0xf582583e clang::ASTFrontendAction::ExecuteAction() + 182 22 libclangCodeGen.so.3.8 0xf5b2d3e1 clang::CodeGenAction::ExecuteAction() + 161 23 libclangFrontend.so.3.8 0xf5826660 clang::FrontendAction::Execute() + 88 24 libclangFrontend.so.3.8 0xf58029e1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 771 25 libclangFrontendTool.so.3.8 0xf579aead clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2953 26 clang-3.8 0x08057178 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 1178 27 clang-3.8 0x08052a9b main + 1723 28 libc.so.6 0xf46424e7 __libc_start_main + 361 29 clang-3.8 0x08054f80 Stack dump: 0. Program arguments: /usr/bin/clang-3.8 -cc1 -triple i686-pc-linux-gnu -emit-obj -disable-free -main-file-name PrettyStackTrace.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu i686 -momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb -ffunction-sections -fdata-sections -coverage-file /builddir/build/BUILD/llvm-3.9.0.src/build/lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -resource-dir /usr/bin/../lib/clang/3.8.1 -dependency-file lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -sys-header-deps -MT lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I lib/Support -I ../lib/Support -I include -I ../include -D _FORTIFY_SOURCE=2 -D _LARGEFILE_SOURCE=1 -D _LARGEFILE64_SOURCE=1 -D _FILE_OFFSET_BITS=64 -D _FORTIFY_SOURCE=2 -D _LARGEFILE_SOURCE=1 -D _LARGEFILE64_SOURCE=1 -D _FILE_OFFSET_BITS=64 -internal-isystem /usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1 -internal-isystem /usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1/i586-mandriva-linux-gnu -internal-isystem /usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.8.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -Os -Wformat -Werror=format-security -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -Wformat -Werror=format-security -pedantic -std=c++1y -fdeprecated-macro -fdebug-compilation-dir /builddir/build/BUILD/llvm-3.9.0.src/build -ferror-limit 19 -fmessage-length 0 -fvisibility-inlines-hidden -stack-protector 1 -stack-protector-buffer-size 4 -stack-protector-buffer-size 4 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -x c++ ../lib/Support/PrettyStackTrace.cpp 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '../lib/Support/PrettyStackTrace.cpp'. 4. Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@_ZN4llvm21PrettyStackTraceEntryD0Ev' clang-3.8: error: unable to execute command: Aborted (core dumped) clang-3.8: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.8.1 (tags/RELEASE_381/rc1) Target: i686-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin clang-3.8: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.8: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.8: note: diagnostic msg: /tmp/PrettyStackTrace-74cffb.cpp clang-3.8: note: diagnostic msg: /tmp/PrettyStackTrace-74cffb.sh clang-3.8: note: diagnostic msg: ******************** armv7hnl fails to build libunwind, but this is likely a configuration issue: CMake Error at projects/libunwind/src/CMakeLists.txt:76 (message): Compiler doesn't support generation of unwind tables if exception support is disabled. Building libunwind DSO with runtime dependency on C++ ABI library is not supported. aarch64 is currently untested because of problems with our only aarch64 build box, but that should be fixed soon. We don't currently have access to sftp. ttyl bero On 30 July 2016 at 00:57, Hans Wennborg via Release-testers < release-testers at lists.llvm.org> wrote:> Dear testers, > > 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. > > This took a little longer than I'd hoped, but I think the branch is in > a decent state now. > > There are still open merge requests and bugs, but I'd like to get the > real testing started to see where we're at. > > Please build, test, and upload binaries to the sftp. Let me know how > it goes. I'll upload source, docs, and your binaries to the > pre-release page once they're ready. > > Thanks, > Hans > _______________________________________________ > Release-testers mailing list > Release-testers at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160801/53e28252/attachment.html>
Michael Kuperstein via llvm-dev
2016-Aug-01 07:18 UTC
[llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
The crash dump looks like it's probably PR27071. The bug was introduced in r261387 (which was merged into 3.8) and fixed in r264465 (which apparently wasn't). On Sun, Jul 31, 2016 at 3:50 PM, Bernhard Rosenkränzer < llvm-dev at lists.llvm.org> wrote:> Hi, > On the OpenMandriva side, x86_64 passes all checks. We're having some > problems with other architectures though (see below): > > x86_64 succeeded, packages are here: > https://abf.openmandriva.org/build_lists/76792 > > i586 fails to build, but this seems to be an issue with 3.8.1 (which we're > using to build 3.9): > > /usr/bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support -Iinclude -I../include -Os -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++1y -fcolor-diagnostics -ffunction-sections -fdata-sections -Os -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -MD -MT lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -MF lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -o lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -c ../lib/Support/PrettyStackTrace.cpp > clang-3.8: ../include/llvm/CodeGen/MachineOperand.h:411: int64_t llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong MachineOperand accessor"' failed. > #0 0xfffffffff4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/libLLVMSupport.so.3.8+0x95075) > #1 0xfffffffff4abd2c7 (/usr/lib/libLLVMSupport.so.3.8+0x952c7) > #2 0xfffffffff4abbbf1 llvm::sys::RunSignalHandlers() (/usr/lib/libLLVMSupport.so.3.8+0x93bf1) > #3 0xfffffffff4abbf49 (/usr/lib/libLLVMSupport.so.3.8+0x93f49) > #4 0xfffffffff7714d20 0xd20 __GI_raise > #5 0xfffffffff7714d20 > #6 0xfffffffff7714d20 __GI_abort (+0xd20) > #7 0xfffffffff4650ef0 __GI___assert_fail (/lib/libc.so.6+0x26ef0) > #8 0xfffffffff46520e5 __GI___assert_perror_fail (/lib/libc.so.6+0x280e5) > #9 0xfffffffff464b126 (/lib/libc.so.6+0x21126) > #10 0xfffffffff464b162 llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr const*) const (/lib/libc.so.6+0x21162) > #11 0xfffffffff65a0db6 (/usr/lib/libLLVMX86CodeGen.so.3.8+0x30db6) > #12 0xfffffffff667640d (/usr/lib/libLLVMX86CodeGen.so.3.8+0x10640d) > #13 0xfffffffff61029dc llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/lib/libLLVMCodeGen.so.3.8+0x1739dc) > #14 0xfffffffff6105002 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/lib/libLLVMCodeGen.so.3.8+0x176002) > #15 0xfffffffff60ab337 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/lib/libLLVMCodeGen.so.3.8+0x11c337) > #16 0xfffffffff50d7e6f llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/libLLVMCore.so.3.8+0x19de6f) > #17 0xfffffffff50d816b llvm::legacy::PassManager::run(llvm::Module&) (/usr/lib/libLLVMCore.so.3.8+0x19e16b) > #18 0xfffffffff50d857f clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) (/usr/lib/libLLVMCore.so.3.8+0x19e57f) > #19 0xfffffffff50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734) > #20 0xfffffffff59fc72c clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/libclangCodeGen.so.3.8+0x6972c) > #21 0xfffffffff5b2cd85 clang::ASTFrontendAction::ExecuteAction() (/usr/lib/libclangCodeGen.so.3.8+0x199d85) > #22 0xfffffffff3b2b294 clang::CodeGenAction::ExecuteAction() (/usr/lib/libclangParse.so.3.8+0x24294) > #23 0xfffffffff582583e clang::FrontendAction::Execute() (/usr/lib/libclangFrontend.so.3.8+0x8783e) > #24 0xfffffffff5b2d3e1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/libclangCodeGen.so.3.8+0x19a3e1) > #25 0xfffffffff5826660 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/libclangFrontend.so.3.8+0x88660) > #26 0xfffffffff58029e1 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/lib/libclangFrontend.so.3.8+0x649e1) > #27 0xfffffffff579aead main (/usr/lib/libclangFrontendTool.so.3.8+0x2ead) > #28 0x08057178 __libc_start_main (/usr/bin/clang-3.8+0x8057178) > #29 0x08052a9b _start (/usr/bin/clang-3.8+0x8052a9b) > 0 libLLVMSupport.so.3.8 0xf4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 > 1 libLLVMSupport.so.3.8 0xf4abd2c7 > 2 libLLVMSupport.so.3.8 0xf4abbbf1 llvm::sys::RunSignalHandlers() + 60 > 3 libLLVMSupport.so.3.8 0xf4abbf49 > 4 0xf7714d20 __kernel_sigreturn + 0 > 5 libc.so.6 0xf4650ef0 gsignal + 73 > 6 libc.so.6 0xf46520e5 abort + 278 > 7 libc.so.6 0xf464b126 __assert_fail + 0 > 8 libc.so.6 0xf464b162 __assert_perror_fail + 0 > 9 libLLVMX86CodeGen.so.3.8 0xf65a0db6 > 10 libLLVMX86CodeGen.so.3.8 0xf667640d llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr const*) const + 365 > 11 libLLVMCodeGen.so.3.8 0xf61029dc > 12 libLLVMCodeGen.so.3.8 0xf6105002 > 13 libLLVMCodeGen.so.3.8 0xf60ab337 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 169 > 14 libLLVMCore.so.3.8 0xf50d7e6f llvm::FPPassManager::runOnFunction(llvm::Function&) + 243 > 15 libLLVMCore.so.3.8 0xf50d816b llvm::FPPassManager::runOnModule(llvm::Module&) + 47 > 16 libLLVMCore.so.3.8 0xf50d857f llvm::legacy::PassManagerImpl::run(llvm::Module&) + 445 > 17 libLLVMCore.so.3.8 0xf50d8734 llvm::legacy::PassManager::run(llvm::Module&) + 32 > 18 libclangCodeGen.so.3.8 0xf59fc72c clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) + 8185 > 19 libclangCodeGen.so.3.8 0xf5b2cd85 > 20 libclangParse.so.3.8 0xf3b2b294 clang::ParseAST(clang::Sema&, bool, bool) + 624 > 21 libclangFrontend.so.3.8 0xf582583e clang::ASTFrontendAction::ExecuteAction() + 182 > 22 libclangCodeGen.so.3.8 0xf5b2d3e1 clang::CodeGenAction::ExecuteAction() + 161 > 23 libclangFrontend.so.3.8 0xf5826660 clang::FrontendAction::Execute() + 88 > 24 libclangFrontend.so.3.8 0xf58029e1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 771 > 25 libclangFrontendTool.so.3.8 0xf579aead clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2953 > 26 clang-3.8 0x08057178 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 1178 > 27 clang-3.8 0x08052a9b main + 1723 > 28 libc.so.6 0xf46424e7 __libc_start_main + 361 > 29 clang-3.8 0x08054f80 > Stack dump: > 0. Program arguments: /usr/bin/clang-3.8 -cc1 -triple i686-pc-linux-gnu -emit-obj -disable-free -main-file-name PrettyStackTrace.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu i686 -momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb -ffunction-sections -fdata-sections -coverage-file /builddir/build/BUILD/llvm-3.9.0.src/build/lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -resource-dir /usr/bin/../lib/clang/3.8.1 -dependency-file lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -sys-header-deps -MT lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I lib/Support -I ../lib/Support -I include -I ../include -D _FORTIFY_SOURCE=2 -D _LARGEFILE_SOURCE=1 -D _LARGEFILE64_SOURCE=1 -D _FILE_OFFSET_BITS=64 -D _FORTIFY_SOURCE=2 -D _LARGEFILE_SOURCE=1 -D _LARGEFILE64_SOURCE=1 -D _FILE_OFFSET_BITS=64 -internal-isystem /usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1 -internal-isystem /usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1/i586-mandriva-linux-gnu -internal-isystem /usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.8.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -Os -Wformat -Werror=format-security -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -Wformat -Werror=format-security -pedantic -std=c++1y -fdeprecated-macro -fdebug-compilation-dir /builddir/build/BUILD/llvm-3.9.0.src/build -ferror-limit 19 -fmessage-length 0 -fvisibility-inlines-hidden -stack-protector 1 -stack-protector-buffer-size 4 -stack-protector-buffer-size 4 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -x c++ ../lib/Support/PrettyStackTrace.cpp > 1. <eof> parser at end of file > 2. Code generation > 3. Running pass 'Function Pass Manager' on module '../lib/Support/PrettyStackTrace.cpp'. > 4. Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@_ZN4llvm21PrettyStackTraceEntryD0Ev' > clang-3.8: error: unable to execute command: Aborted (core dumped) > clang-3.8: error: clang frontend command failed due to signal (use -v to see invocation) > clang version 3.8.1 (tags/RELEASE_381/rc1) > Target: i686-pc-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > clang-3.8: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. > clang-3.8: note: diagnostic msg: > ******************** > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > clang-3.8: note: diagnostic msg: /tmp/PrettyStackTrace-74cffb.cpp > clang-3.8: note: diagnostic msg: /tmp/PrettyStackTrace-74cffb.sh > clang-3.8: note: diagnostic msg: > ******************** > > armv7hnl fails to build libunwind, but this is likely a configuration > issue: > > CMake Error at projects/libunwind/src/CMakeLists.txt:76 (message): > Compiler doesn't support generation of unwind tables if exception support > is disabled. Building libunwind DSO with runtime dependency on C++ ABI > library is not supported. > > aarch64 is currently untested because of problems with our only aarch64 > build box, but that should be fixed soon. > > We don't currently have access to sftp. > > ttyl > bero > > On 30 July 2016 at 00:57, Hans Wennborg via Release-testers < > release-testers at lists.llvm.org> wrote: > >> Dear testers, >> >> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. >> >> This took a little longer than I'd hoped, but I think the branch is in >> a decent state now. >> >> There are still open merge requests and bugs, but I'd like to get the >> real testing started to see where we're at. >> >> Please build, test, and upload binaries to the sftp. Let me know how >> it goes. I'll upload source, docs, and your binaries to the >> pre-release page once they're ready. >> >> Thanks, >> Hans >> _______________________________________________ >> Release-testers mailing list >> Release-testers at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers >> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160801/95f09974/attachment.html>
Hans Wennborg via llvm-dev
2016-Aug-01 16:37 UTC
[llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On Sun, Jul 31, 2016 at 12:38 PM, Renato Golin <renato.golin at linaro.org> wrote:> On 29 July 2016 at 23:57, Hans Wennborg via Release-testers > <release-testers at lists.llvm.org> wrote: >> There are still open merge requests and bugs, but I'd like to get the >> real testing started to see where we're at. > > First wave of testing pass on ARM. Uploaded to the FTP server. > > Is it time to do the back-ports planned? I only have a very minor bug fix.Sure! Cheers, Hans
Hans Wennborg via llvm-dev
2016-Aug-01 18:49 UTC
[llvm-dev] [3.9 Release] Release Candidate 1 has been tagged
On Fri, Jul 29, 2016 at 3:57 PM, Hans Wennborg <hans at chromium.org> wrote:> Dear testers, > > 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. > > This took a little longer than I'd hoped, but I think the branch is in > a decent state now. > > There are still open merge requests and bugs, but I'd like to get the > real testing started to see where we're at. > > Please build, test, and upload binaries to the sftp. Let me know how > it goes. I'll upload source, docs, and your binaries to the > pre-release page once they're ready.Windows looked good. Binaries (sha1): 7f350f8a4903965ea9f3800f6d30a782ce86b0df LLVM-3.9.0-rc1-win32.exe 0b40f11a8d6c1f1fb69dcf213916cf439bb326c0 LLVM-3.9.0-rc1-win64.exe
Ben Pope via llvm-dev
2016-Aug-02 22:19 UTC
[llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On 07/29/2016 11:57 PM, Hans Wennborg via Release-testers wrote:> Please build, test, and upload binaries to the sftp. Let me know how > it goes. I'll upload source, docs, and your binaries to the > pre-release page once they're ready.Uploaded clang+llvm-3.9.0-rc1-x86_64-linux-gnu-ubuntu-16.04.tar.xz I had this error: Using configuration variant: libcxxabi -- Testing: 35960 tests, 8 threads -- Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. *** stack smashing detected ***: /home/ben/development/llvm/3.9.0/rc1/Phase3/Release/llvmCore-3.9.0-rc1.obj/projects/compiler-rt/test/safestack/Output/canary.c.tmp.ssp terminated 80.. 90.. Testing Time: 1695.83s Expected Passes : 34915 Expected Failures : 212 Unsupported Tests : 833 [100%] Built target check-all LNT was fine. Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160802/37224822/attachment.html>
Dimitry Andric via llvm-dev
2016-Aug-03 18:24 UTC
[llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On 30 Jul 2016, at 00:57, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote:> > 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.After fixing two compiler-rt test failures (see r277297 and r277300) and one openmp test link failure (see https://reviews.llvm.org/D23084), I'm left with only two failing tests: Failing Tests (2): ThreadSanitizer-x86_64 :: inlined_memcpy_race2.cc ThreadSanitizer-x86_64 :: signal_reset.cc Expected Passes : 28511 Expected Failures : 155 Unsupported Tests : 1080 Unexpected Failures: 2 These both fail because they hang indefinitely, and have to be killed for check-all to continue. Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and higher, due to a conflict of initialization order with our jemalloc. So I am not extremely keen on fixing this before the release. I uploaded the following: SHA256 (clang+llvm-3.9.0-rc1-amd64-unknown-freebsd10.tar.xz) = 8d3b1d50c00901d235c110a84afa5c16f0e80683928a47e31f8c189a41268698 SHA256 (clang+llvm-3.9.0-rc1-i386-unknown-freebsd10.tar.xz) = 602373772b4ff2fc70c97f5483db33e3ecfd24122aed96d6fe083bae3ea0e6f6 For i386 and amd64, this contains llvm, clang, compiler-rt and lldb, while on amd64 there is also openmp. We cannot yet build libc++, libcxxabi and libunwind, due to some missing functionality in our system unwinder. Maybe if test-release.sh supported building libc++ separately, I could add it for the next RC. -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160803/73508c37/attachment.sig>
Renato Golin via llvm-dev
2016-Aug-03 18:44 UTC
[llvm-dev] [cfe-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On 3 August 2016 at 19:24, Dimitry Andric via cfe-dev <cfe-dev at lists.llvm.org> wrote:> Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and higher, due to a conflict of initialization order with our jemalloc. So I am not extremely keen on fixing this before the release.This sounds really serious. Do we have a bug for that? --renato
Nikola Smiljanic via llvm-dev
2016-Aug-05 23:14 UTC
[llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
Testsuite is green on both Fedora and openSUSE. Both x86 distros are failing to find i686.so of compiler_rt. There's one check-all failure on Fedora x64: FAIL: libc++ :: std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp (31305 of 35085) In hard_link_count_for_directory():54 Assertion TEST_CHECK(hard_link_count(StaticEnv::Dir) == DirExpect) failed. in file: /home/nikola/rc1/llvm.src/projects/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp In hard_link_count_for_directory():55 Assertion TEST_CHECK(hard_link_count(StaticEnv::Dir3) == Dir3Expect) failed. in file: /home/nikola/rc1/llvm.src/projects/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp In hard_link_count_for_directory():58 Assertion TEST_CHECK(hard_link_count(StaticEnv::Dir, ec) == DirExpect) failed. in file: /home/nikola/rc1/llvm.src/projects/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp In hard_link_count_for_directory():59 Assertion TEST_CHECK(hard_link_count(StaticEnv::Dir3, ec) == Dir3Expect) failed. in file: /home/nikola/rc1/llvm.src/projects/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp I've uploaded the binaries without LLDB because I was using the old version of test-release, I'll fix this before rc2. On Sat, Jul 30, 2016 at 8:57 AM, Hans Wennborg via Release-testers < release-testers at lists.llvm.org> wrote:> Dear testers, > > 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. > > This took a little longer than I'd hoped, but I think the branch is in > a decent state now. > > There are still open merge requests and bugs, but I'd like to get the > real testing started to see where we're at. > > Please build, test, and upload binaries to the sftp. Let me know how > it goes. I'll upload source, docs, and your binaries to the > pre-release page once they're ready. > > Thanks, > Hans > _______________________________________________ > Release-testers mailing list > Release-testers at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160806/4c35d1e9/attachment.html>
Brian Cain via llvm-dev
2016-Aug-10 18:36 UTC
[llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
[earlier I had accidentally sent this message to only Hans, re-sending as reply-all now] When I tried rc1 on sles11.3 x86_64, msan's getrlimit test fails to build for lack of prlimit(). SLES11.3 has glibc 2.11.3. Is there a minimum required glibc? I think this test implementation previously used getrlimit(), which is present on glibc2.11.3. On Fri, Jul 29, 2016 at 5:57 PM, Hans Wennborg via Release-testers < release-testers at lists.llvm.org> wrote:> Dear testers, > > 3.9.0-rc1 was just tagged from the 3.9 branch at r277207. > > This took a little longer than I'd hoped, but I think the branch is in > a decent state now. > > There are still open merge requests and bugs, but I'd like to get the > real testing started to see where we're at. > > Please build, test, and upload binaries to the sftp. Let me know how > it goes. I'll upload source, docs, and your binaries to the > pre-release page once they're ready. > > Thanks, > Hans > _______________________________________________ > Release-testers mailing list > Release-testers at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers >-- -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160810/5c2ec963/attachment.html>