Hans Wennborg
2015-Jul-16 22:31 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
Dear testers, 3.7.0-rc1 was just tagged; please start your testing engines :-) Upload binaries to the sftp and report your results to this thread. I'm sorry for the delay between branching and tagging. The changes to the release script took a little longer than I hoped. Thanks for helping with the release, and do let me know of any issues, questions, etc. The tracking bug for release blockers is PR24126. Cheers, Hans
Dimitry Andric
2015-Jul-16 22:47 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On 17 Jul 2015, at 00:31, Hans Wennborg <hans at chromium.org> wrote:> > Dear testers, > > 3.7.0-rc1 was just tagged; please start your testing engines :-) > > Upload binaries to the sftp and report your results to this thread. > > I'm sorry for the delay between branching and tagging. The changes to > the release script took a little longer than I hoped. > > Thanks for helping with the release, and do let me know of any issues, > questions, etc. > > The tracking bug for release blockers is PR24126.Is it OK to do an autoconf build? The CMake build tries to build various components which do not yet work on FreeBSD, e.g. libcxxabi does not compile at all, libcompiler-rt has a bunch of test failures, etc. Alternatively, can I disable these components in the CMake build locally? -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/20150717/6366af45/attachment.sig>
Jack Howarth
2015-Jul-16 23:03 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
Hans, Do we intend to leave -fopenmp defaulted to the no-op libgomp support for 3.7.0 or do the sensible thing by applying... Index: CMakeLists.txt ==================================================================--- CMakeLists.txt (revision 242425) +++ CMakeLists.txt (working copy) @@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di set(DEFAULT_SYSROOT "" CACHE PATH "Default <path> to all compiler invocations for --sysroot=<path>." ) -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING "Default OpenMP runtime used by -fopenmp.") set(CLANG_VENDOR "" CACHE STRING so that the new llvm openmp library (which passes a three stage bootstrap as part of an in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on x86_64-apple-darwin). Jack On Thu, Jul 16, 2015 at 6:31 PM, Hans Wennborg <hans at chromium.org> wrote:> Dear testers, > > 3.7.0-rc1 was just tagged; please start your testing engines :-) > > Upload binaries to the sftp and report your results to this thread. > > I'm sorry for the delay between branching and tagging. The changes to > the release script took a little longer than I hoped. > > Thanks for helping with the release, and do let me know of any issues, > questions, etc. > > The tracking bug for release blockers is PR24126. > > Cheers, > Hans > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hans Wennborg
2015-Jul-16 23:09 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <dimitry at andric.com> wrote:> On 17 Jul 2015, at 00:31, Hans Wennborg <hans at chromium.org> wrote: >> >> Dear testers, >> >> 3.7.0-rc1 was just tagged; please start your testing engines :-) >> >> Upload binaries to the sftp and report your results to this thread. >> >> I'm sorry for the delay between branching and tagging. The changes to >> the release script took a little longer than I hoped. >> >> Thanks for helping with the release, and do let me know of any issues, >> questions, etc. >> >> The tracking bug for release blockers is PR24126. > > Is it OK to do an autoconf build? The CMake build tries to build various components which do not yet work on FreeBSD, e.g. libcxxabi does not compile at all, libcompiler-rt has a bunch of test failures, etc. Alternatively, can I disable these components in the CMake build locally?Yes, go ahead and use the autoconf build. Can you send a patch to test-release.sh that makes this default for FreeBSD? It's already the default for Darwin. Thanks, Hans
Hans Wennborg
2015-Jul-16 23:14 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
Hi Jack, On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:> Hans, > Do we intend to leave -fopenmp defaulted to the no-op libgomp > support for 3.7.0 or do the sensible thing by applying... > > Index: CMakeLists.txt > ==================================================================> --- CMakeLists.txt (revision 242425) > +++ CMakeLists.txt (working copy) > @@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di > set(DEFAULT_SYSROOT "" CACHE PATH > "Default <path> to all compiler invocations for --sysroot=<path>." ) > > -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING > +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING > "Default OpenMP runtime used by -fopenmp.") > > set(CLANG_VENDOR "" CACHE STRING > > so that the new llvm openmp library (which passes a three stage > bootstrap as part of an > in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on > x86_64-apple-darwin).I'm not fully aware of the implications of this, but if we do want to change it, it needs to be done on trunk first. If you get it through review and committed to trunk, I'm open to merging it. I assume utils/release/test-release.sh would also need an update so the library gets built? Thanks, Hans
Renato Golin
2015-Jul-17 13:42 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
Hi Hans, We're missing libunwind from the list of projects in 3.7. The current way libcxxabi builds depends on libunwin (looking for libunwind.h), so we need to tag libunwind, check it out in the script and build it together. For now, I'll disable libcxx from my build, but it would be good to have it on later, so we can test it with the rest, too. cheers, --renato On 16 July 2015 at 23:31, Hans Wennborg <hans at chromium.org> wrote:> Dear testers, > > 3.7.0-rc1 was just tagged; please start your testing engines :-) > > Upload binaries to the sftp and report your results to this thread. > > I'm sorry for the delay between branching and tagging. The changes to > the release script took a little longer than I hoped. > > Thanks for helping with the release, and do let me know of any issues, > questions, etc. > > The tracking bug for release blockers is PR24126. > > Cheers, > Hans
Hans Wennborg
2015-Jul-17 16:53 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
Hi Renato, On Fri, Jul 17, 2015 at 6:42 AM, Renato Golin <renato.golin at linaro.org> wrote:> We're missing libunwind from the list of projects in 3.7. > > The current way libcxxabi builds depends on libunwin (looking for > libunwind.h), so we need to tag libunwind, check it out in the script > and build it together. > > For now, I'll disable libcxx from my build, but it would be good to > have it on later, so we can test it with the rest, too.I've created the branch and rc1 tag for libunwind, and included it in the scripts in r242543. Let me know how it works out. Thanks, Hans> On 16 July 2015 at 23:31, Hans Wennborg <hans at chromium.org> wrote: >> Dear testers, >> >> 3.7.0-rc1 was just tagged; please start your testing engines :-) >> >> Upload binaries to the sftp and report your results to this thread. >> >> I'm sorry for the delay between branching and tagging. The changes to >> the release script took a little longer than I hoped. >> >> Thanks for helping with the release, and do let me know of any issues, >> questions, etc. >> >> The tracking bug for release blockers is PR24126. >> >> Cheers, >> Hans
Renato Golin
2015-Jul-18 14:05 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On 16 July 2015 at 23:31, Hans Wennborg <hans at chromium.org> wrote:> 3.7.0-rc1 was just tagged; please start your testing engines :-) > > Upload binaries to the sftp and report your results to this thread.ARMv7 with Compiler-RT up. There were unexpected passes on the sanitizer, but that's ok. I'm running tests and benchmarks now, but people can already try it out if they want. AArch64 will come early next week. cheers, --renato
Kun Ling
2015-Jul-19 05:19 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
Hi Hans, Test Result Report: Ubuntu 15.04 AMD64 3.7.0-RC1 release . Everything works fine without any problem. SFTP Upload: Not done yet. Since do not have the SFTP access information. Kun Ling ------------------ Original ------------------ From: "Hans Wennborg"<hans at chromium.org>; Date: Thu, Jul 16, 2015 02:31 PM To: "llvmdev"<llvmdev at cs.uiuc.edu>; "cfe-dev"<cfe-dev at cs.uiuc.edu>; "lldb-dev"<lldb-dev at cs.uiuc.edu>; Cc: "Ben Pope"<benpope81 at gmail.com>; "Pavel Labath"<labath at google.com>; "Nikola Smiljanić"<popizdeh at gmail.com>; Subject: [LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins Dear testers, 3.7.0-rc1 was just tagged; please start your testing engines :-) Upload binaries to the sftp and report your results to this thread. I'm sorry for the delay between branching and tagging. The changes to the release script took a little longer than I hoped. Thanks for helping with the release, and do let me know of any issues, questions, etc. The tracking bug for release blockers is PR24126. Cheers, Hans _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150719/004905c7/attachment.html>
Ben Pope
2015-Jul-19 08:36 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Friday, July 17, 2015 06:31 AM, Hans Wennborg wrote:> Dear testers, > > 3.7.0-rc1 was just tagged; please start your testing engines :-) > > Upload binaries to the sftp and report your results to this thread. > > I'm sorry for the delay between branching and tagging. The changes to > the release script took a little longer than I hoped. > > Thanks for helping with the release, and do let me know of any issues, > questions, etc.On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and no tarball: Failing Tests (18): AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc MemorySanitizer :: Linux/tcgetattr.cc MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.gethostent MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r SanitizerCommon-asan :: Linux/getpass.cc SanitizerCommon-asan :: Posix/decorate_proc_maps.cc SanitizerCommon-lsan :: Linux/getpass.cc SanitizerCommon-msan :: Linux/getpass.cc SanitizerCommon-msan :: Linux/signal_segv_handler.cc SanitizerCommon-msan :: Posix/decorate_proc_maps.cc SanitizerCommon-tsan :: Linux/getpass.cc SanitizerCommon-tsan :: Posix/decorate_proc_maps.cc Expected Passes : 24006 Expected Failures : 131 Unsupported Tests : 377 Unexpected Failures: 18 Ben
Renato Golin
2015-Jul-19 11:43 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On 19 July 2015 at 09:36, Ben Pope <benpope81 at gmail.com> wrote:> On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and no > tarball:The tarball is an issue Hans is aware of. We're fixing it.> Failing Tests (18): > AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.ccDid you use to build compiler-rt on the previous (autoconf) releases? If not, this might explain why you're only seeing these errors now. cheers, --renato
sebastian.dressler at gmail.com
2015-Jul-19 18:20 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
Hi Hans, I uploaded c55199c92877ed068b2f7d1ece6b0bb4f121a63a clang+llvm-3.7.0-rc1-x86_64-apple-darwin.tar.xz to SFTP. Testing was OK except for differences between phase 2 and 3 which I consider being not harmful (or even: usual). No problem with the build script here, but OS X also does not use RPATH. Cheers, Sebastian> On 17.07.2015, at 00:31, Hans Wennborg <hans at chromium.org> wrote: > > Dear testers, > > 3.7.0-rc1 was just tagged; please start your testing engines :-) > > Upload binaries to the sftp and report your results to this thread. > > I'm sorry for the delay between branching and tagging. The changes to > the release script took a little longer than I hoped. > > Thanks for helping with the release, and do let me know of any issues, > questions, etc. > > The tracking bug for release blockers is PR24126. > > Cheers, > Hans
Daniel Sanders
2015-Jul-20 09:26 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
Here's the current status for the Mips packages. With the following source changes to the tag: * Applied r242331 - Switch the release script to build with CMake by default (PR21561) * Applied r242422 - Fixed an error in cuda-options.cu test -target option must be used without '='. * Reverted r241599 - Fix bug in test-release.sh where the script would not exit if any of the build stages that are sent through a pipe (e.g. tee) failed. And the following change to the resulting packages: * Move/symlink $package/usr/local/* to $package/* (Note the packages uploaded are as built by the script and do not have this change) clang+llvm-3.7.0-rc1-mips-linux-gnu.tar.xz Failing Tests (6): AddressSanitizer-mips-linux :: TestCases/Linux/kernel-area.cc AddressSanitizer-mips-linux :: TestCases/Posix/coverage-direct-large.cc UBSan-ASan-mips :: TestCases/Float/cast-overflow.cpp UBSan-Standalone-mips :: TestCases/Float/cast-overflow.cpp libc++abi :: backtrace_test.pass.cpp libc++abi :: test_demangle.pass.cpp Test-suite: Just started this morning. clang+llvm-3.7.0-rc1-mipsel-linux-gnu.tar.xz Failing Tests (4): AddressSanitizer-mipsel-linux :: TestCases/Linux/kernel-area.cc Clang :: Modules/prune.m <- expected since this system uses an NFS mount with noatime. libc++abi :: backtrace_test.pass.cpp libc++abi :: test_demangle.pass.cpp Test-suite: Still running but ok so far. clang+llvm-3.7.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to Mips): Not started since packages not uploaded yet. Presumably due to the packaging problems discussed elsewhere in this thread. With the exception of prune.m (which is expected on that machine) the 'make check-all' failures are all related to projects that weren't built in the 3.6 releases. It will take a day or two for the test-suite results to finish since these machines lack an FPU and have to trap-and-emulate. I have a little endian with an FPU that I can try the test-suite on which should be much faster.> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Hans Wennborg > Sent: 16 July 2015 23:31 > To: llvmdev; cfe-dev; lldb-dev at cs.uiuc.edu > Cc: Ben Pope; Pavel Labath; Nikola Smiljanić > Subject: [LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I > begins > > Dear testers, > > 3.7.0-rc1 was just tagged; please start your testing engines :-) > > Upload binaries to the sftp and report your results to this thread. > > I'm sorry for the delay between branching and tagging. The changes to > the release script took a little longer than I hoped. > > Thanks for helping with the release, and do let me know of any issues, > questions, etc. > > The tracking bug for release blockers is PR24126. > > Cheers, > Hans > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Renato Golin
2015-Jul-20 15:34 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On 18 July 2015 at 15:05, Renato Golin <renato.golin at linaro.org> wrote:> ARMv7 with Compiler-RT up. There were unexpected passes on the > sanitizer, but that's ok.AArch64 with Compiler-RT up. Both tested with the test-suite, all pass. cheers, --renato
Hans Wennborg
2015-Jul-20 20:43 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Sat, Jul 18, 2015 at 7:05 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 16 July 2015 at 23:31, Hans Wennborg <hans at chromium.org> wrote: >> 3.7.0-rc1 was just tagged; please start your testing engines :-) >> >> Upload binaries to the sftp and report your results to this thread. > > ARMv7 with Compiler-RT up.Thanks! The file doesn't seem to have -rc1 in the name like the others, but it does seem to have been built at the rc1 tag. Do you think we can just rename it? Thanks, Hans
Hans Wennborg
2015-Jul-20 21:22 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
Hi Kun, On Sat, Jul 18, 2015 at 10:19 PM, Kun Ling <kunling at lingcc.com> wrote:> Hi Hans, > Test Result Report: Ubuntu 15.04 AMD64 3.7.0-RC1 release . Everything > works fine without any problem.Nice!> SFTP Upload: Not done yet. Since do not have the SFTP access > information.Anton, can you help Kun get access to the sftp? Thanks, Hans
Hans Wennborg
2015-Jul-20 21:37 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Sun, Jul 19, 2015 at 11:20 AM, <sebastian.dressler at gmail.com> wrote:> Hi Hans, > > I uploaded > > c55199c92877ed068b2f7d1ece6b0bb4f121a63a clang+llvm-3.7.0-rc1-x86_64-apple-darwin.tar.xz > > to SFTP.Thanks!> Testing was OK except for differences between phase 2 and 3 which I consider being not harmful (or even: usual). No problem with the build script here, but OS X also does not use RPATH.Do you have any idea what the diff is though? The script tries hard to build and compare in a way that should make the builds compare equal. Thanks, Hans>> On 17.07.2015, at 00:31, Hans Wennborg <hans at chromium.org> wrote: >> >> Dear testers, >> >> 3.7.0-rc1 was just tagged; please start your testing engines :-) >> >> Upload binaries to the sftp and report your results to this thread. >> >> I'm sorry for the delay between branching and tagging. The changes to >> the release script took a little longer than I hoped. >> >> Thanks for helping with the release, and do let me know of any issues, >> questions, etc. >> >> The tracking bug for release blockers is PR24126. >> >> Cheers, >> Hans >
Hans Wennborg
2015-Jul-20 21:51 UTC
[LLVMdev] [lldb-dev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Mon, Jul 20, 2015 at 5:01 AM, Ben Pope <benpope81 at gmail.com> wrote:> On Sunday, July 19, 2015 07:43 PM, Renato Golin wrote: >> >> On 19 July 2015 at 09:36, Ben Pope <benpope81 at gmail.com> wrote: >>> >>> On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and no >>> tarball: >> >> >> The tarball is an issue Hans is aware of. We're fixing it. >> >>> Failing Tests (18): >>> AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc >> >> >> Did you use to build compiler-rt on the previous (autoconf) releases? > > > I don't know. I didn't specifically enable it. > >> If not, this might explain why you're only seeing these errors now.I think it was built by default before, but that the autoconf build didn't run as many tests. Having these tests run is one of the benefits of using the cmake build, but it of course has the downside that we have to make them pass :-)> 1) Use the autoconf build and upload if I get a tarball? > 2) Disable compiler-rt (how?)? > 3) Disable the -o pipefail and upload if I get a tarball? > 4) Something else?I don't think the test failures are correlated to not getting a tarball. It's probably the "rpath problem" that Dimitry mentioned further up in the thread. Try using his patch for it, or disabling -o pipefail. And please see if you can dig out some more details about the failing tests and get bugs filed. Thanks, Hans
Hans Wennborg
2015-Jul-20 23:55 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Thu, Jul 16, 2015 at 3:31 PM, Hans Wennborg <hans at chromium.org> wrote:> 3.7.0-rc1 was just tagged; please start your testing engines :-) > > Upload binaries to the sftp and report your results to this thread. > > I'm sorry for the delay between branching and tagging. The changes to > the release script took a little longer than I hoped. > > Thanks for helping with the release, and do let me know of any issues, > questions, etc. > > The tracking bug for release blockers is PR24126.Windows binaries uploaded. sha1sums: b0f5bced4003fe9c55e049392603c68276679e53 LLVM-3.7.0-rc1-win32.exe 7373bdbc5c62a7d4d3cf28458896ba2854ea715d LLVM-3.7.0-rc1-win64.exe They were built with the attached batch file, in case anyone wishes to reproduce. I applied r242527, which was merged after the rc1 tag, locally to make Object/archive-extract.test pass. Cheers, Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: build_llvm_370._bat_ Type: application/octet-stream Size: 2614 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150720/8c7db472/attachment.obj>
Hans Wennborg
2015-Jul-21 20:44 UTC
[LLVMdev] [cfe-dev] [lldb-dev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Tue, Jul 21, 2015 at 7:39 AM, Ben Pope <benpope81 at gmail.com> wrote:> On Tuesday, July 21, 2015 05:51 AM, Hans Wennborg wrote: >> >> I don't think the test failures are correlated to not getting a >> tarball. It's probably the "rpath problem" that Dimitry mentioned >> further up in the thread. Try using his patch for it > > > It still failed, I used test-release.sh r242767 which appears to have the > rpath change.Weird. Did you get any output suggesting what the error was?>> or disabling -o pipefail. > > > That sort of worked. Again, the paths in the install directory are > ./usr/local/ but in the tarball they seem as before.Having /usr/local in the install directory during the build is expected. As long as they don't up in the tarball (and I fixed that), it's fine.> Also, cxxabi.h is in > ./include/c++/v1 which is nice, but no unwind.h, I haven't checked if that's > a problem yet.I'm not that familiar with libunwind. Clang should have installed an unwind.h in lib/clang/3.7.0/include/unwind.h. I don't know if libunwind is expected to install another one.> Failing Tests (9): > MemorySanitizer :: Linux/tcgetattr.cc > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.getmntent > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r > SanitizerCommon-asan :: Linux/getpass.cc > SanitizerCommon-lsan :: Linux/getpass.cc > SanitizerCommon-msan :: Linux/getpass.cc > SanitizerCommon-tsan :: Linux/getpass.cc > > Expected Passes : 24015 > Expected Failures : 131 > Unsupported Tests : 377 > Unexpected Failures: 9 > > Full output below. > > lnt seems fine, I've uploaded this file: > clang+llvm-3.7.0-rc1-x86_64-linux-gnu-ubuntu-15.04.tar.xz > >> And please see if you can dig out some more details about the failing >> tests and get bugs filed. > > > I don't really know what I'm looking for, if you need more info I'm happy to > provide it.The output below is great. I'll try to get these investigated. Thanks, Hans
Hans Wennborg
2015-Jul-22 00:52 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Thu, Jul 16, 2015 at 3:31 PM, Hans Wennborg <hans at chromium.org> wrote:> Dear testers, > > 3.7.0-rc1 was just tagged; please start your testing engines :-)This has been a bumpier ride than 3.6 so far, mainly due to the cmake switch. We're testing stuff that didn't get tested before, which I think is good. Thank you very much for your efforts so far. This is an attempt to summarize this rather long thread. TL;DR: There have been a bunch of issues, many addressed, some still out-standing. Most binaries are ready, so I plan to push RC1 to the web site soon. Binaries on the sftp: ====================clang+llvm-3.7.0-armv7a-linux-gnueabihf.tar.xz clang+llvm-3.7.0-rc1-aarch64-linux-gnu.tar.xz clang+llvm-3.7.0-rc1-amd64-unknown-freebsd10.tar.xz clang+llvm-3.7.0-rc1-i386-unknown-freebsd10.tar.xz clang+llvm-3.7.0-rc1-mipsel-linux-gnu.tar.xz clang+llvm-3.7.0-rc1-mips-linux-gnu.tar.xz clang+llvm-3.7.0-rc1-x86_64-apple-darwin.tar.xz clang+llvm-3.7.0-rc1-x86_64-linux-gnu-ubuntu-15.04.tar.xz LLVM-3.7.0-rc1-win32.exe LLVM-3.7.0-rc1-win64.exe Some of these have the /usr/local prefix baked in (since fixed in r242706); I'll remove that manually before publishing the tarballs. The armv7a tarball doesn't have rc1 in the name. I'll rename that (and the dir within) before publishing. Fedora and OpenSUSE isn't ready yet, but those can be added later. I think we have enough binaries to put RC1 on the web page. Issues =====Various compiler-rt test failures, see below. (Linux/signal_segv_handler.cc might be fixed by r242848.) Dimitry says he'll use the autoconf build for FreeBSD due to errors. Has a patch out to do this in the script, but it hasn't landed yet. (Darwin currently also defaults to autoconf in the script) Jack Howarth asked about -fopenmp currently essentially being no-op. As far as I know (please correct me if I'm wrong here) this is still the case on trunk. If it's not enabled on trunk, there is nothing to merge. There is a discussion on openmp-dev about the CMake build being broken in Pathscale's build. The breakage does not seem to be well understood yet. Nikola reports that compiler-rt fails to cmake on x86 openSUSE because it targets i686, but the system is i586. Same failure happens on the phase 2 build on x86 Fedora 22, but probably with a different cause. Renato reported libunwind was missing from the projects list, preventing libcxxabi and libcxx to build. It was added in r242543, but there are still problems and Renato said he'll exclude them for this release. Files in the tarball were prefixed with /usr/local; fixed in r242706. The clean_rpath function was failing when no rpath was present in the binary; fixed in r242722 The file comparison step was broken as cmp(1) doesn't support --ignore-initial on all platforms; fixed in r242721. Object/archive-extract.test failed on windows; fixed in r242527 Ben reports that he didn't get a tarball even after the rpath fix and had to disable -o pipefail to get one. Still not sure what caused this. Thanks, Hans Appendix: compiler-rt test failures ==================================>From Ben on Ubuntu 14.04 x64: AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc MemorySanitizer :: Linux/tcgetattr.cc MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.gethostent MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r SanitizerCommon-asan :: Linux/getpass.cc SanitizerCommon-asan :: Posix/decorate_proc_maps.cc SanitizerCommon-lsan :: Linux/getpass.cc SanitizerCommon-msan :: Linux/getpass.cc SanitizerCommon-msan :: Linux/signal_segv_handler.cc SanitizerCommon-msan :: Posix/decorate_proc_maps.cc SanitizerCommon-tsan :: Linux/getpass.cc SanitizerCommon-tsan :: Posix/decorate_proc_maps.cc>From Nikola on Fedora 22 x64:LeakSanitizer-AddressSanitizer :: TestCases/cleanup_in_tsd_destructor.cc LeakSanitizer-AddressSanitizer :: TestCases/disabler.cc LeakSanitizer-AddressSanitizer :: TestCases/disabler_in_tsd_destructor.cc LeakSanitizer-AddressSanitizer :: TestCases/ignore_object.cc LeakSanitizer-Standalone :: TestCases/cleanup_in_tsd_destructor.cc LeakSanitizer-Standalone :: TestCases/disabler.cc LeakSanitizer-Standalone :: TestCases/disabler_in_tsd_destructor.cc LeakSanitizer-Standalone :: TestCases/ignore_object.cc>From Ben on x86_64-linux-gnu-ubuntu-15.04:MemorySanitizer :: Linux/tcgetattr.cc MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r SanitizerCommon-asan :: Linux/getpass.cc SanitizerCommon-lsan :: Linux/getpass.cc SanitizerCommon-msan :: Linux/getpass.cc SanitizerCommon-tsan :: Linux/getpass.cc
Ben Pope
2015-Jul-22 11:48 UTC
[LLVMdev] [cfe-dev] [lldb-dev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Wednesday, July 22, 2015 04:44 AM, Hans Wennborg wrote:> On Tue, Jul 21, 2015 at 7:39 AM, Ben Pope <benpope81 at gmail.com> wrote: >> On Tuesday, July 21, 2015 05:51 AM, Hans Wennborg wrote: >>> >>> I don't think the test failures are correlated to not getting a >>> tarball. It's probably the "rpath problem" that Dimitry mentioned >>> further up in the thread. Try using his patch for it >> >> >> It still failed, I used test-release.sh r242767 which appears to have the >> rpath change. > > Weird. Did you get any output suggesting what the error was?My normal (using cmake) builds on linux usually put the rpath on, although I thought the cmake install step then strips them - I just checked and that's not true for my latest build from trunk which both have RUNPATH, not RPATH like the rc1. Weirder and weirder. The rpath step in test-release may have been added or changed back around release 3.3; it looks like that discussion didn't hit the mailing list, nor did it include you. I can forward it to you if you like. Anyway, cmake supports customisation of the rpath handling, so we should probably just use that and remove it from the test-release script. The only errors I can see are: CMakeFiles/check-all.dir/build.make:49: recipe for target 'CMakeFiles/check-all' failed make[3]: *** [CMakeFiles/check-all] Error 1 make[3]: Target 'CMakeFiles/check-all.dir/build' not remade because of errors. CMakeFiles/Makefile2:129: recipe for target 'CMakeFiles/check-all.dir/all' failed make[2]: *** [CMakeFiles/check-all.dir/all] Error 2 CMakeFiles/Makefile2:137: recipe for target 'CMakeFiles/check-all.dir/rule' failed make[1]: *** [CMakeFiles/check-all.dir/rule] Error 2 make[1]: Target 'check-all' not remade because of errors. Makefile:171: recipe for target 'check-all' failed make: *** [check-all] Error 2 So it appears to be -o pipefail picking up the sanitizer failures. Ben
Daniel Sanders
2015-Jul-22 14:03 UTC
[LLVMdev] [cfe-dev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
> Ben reports that he didn't get a tarball even after the rpath fix and > had to disable -o pipefail to get one. Still not sure what caused > this.'make check' failures can cause this. I had to revert r241599 to get a package.> Appendix: compiler-rt test failures > ==================================>Just to add Mips to this: On big-endian Mips32r2: AddressSanitizer-mips-linux :: TestCases/Linux/kernel-area.cc AddressSanitizer-mips-linux :: TestCases/Posix/coverage-direct-large.cc UBSan-ASan-mips :: TestCases/Float/cast-overflow.cpp UBSan-Standalone-mips :: TestCases/Float/cast-overflow.cpp libc++abi :: backtrace_test.pass.cpp libc++abi :: test_demangle.pass.cpp On little-endian Mips32r2: AddressSanitizer-mips-linux :: TestCases/Linux/kernel-area.cc libc++abi :: backtrace_test.pass.cpp libc++abi :: test_demangle.pass.cpp Jaydeep Patil and Nitesh Jain have shown me a patch for 'libc++abi :: test_demangle.pass.cpp' which works for me. It should be appearing for review shortly.> -----Original Message----- > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] > On Behalf Of Hans Wennborg > Sent: 22 July 2015 01:53 > To: llvmdev; cfe-dev; lldb-dev at cs.uiuc.edu > Cc: Ben Pope; Ed Maste; Sebastian Dreßler > Subject: Re: [cfe-dev] [3.7 Release] RC1 has been tagged, Testing Phase I > begins > > On Thu, Jul 16, 2015 at 3:31 PM, Hans Wennborg <hans at chromium.org> > wrote: > > Dear testers, > > > > 3.7.0-rc1 was just tagged; please start your testing engines :-) > > This has been a bumpier ride than 3.6 so far, mainly due to the cmake > switch. We're testing stuff that didn't get tested before, which I > think is good. Thank you very much for your efforts so far. > > This is an attempt to summarize this rather long thread. TL;DR: There > have been a bunch of issues, many addressed, some still out-standing. > Most binaries are ready, so I plan to push RC1 to the web site soon. > > Binaries on the sftp: > ====================> clang+llvm-3.7.0-armv7a-linux-gnueabihf.tar.xz > clang+llvm-3.7.0-rc1-aarch64-linux-gnu.tar.xz > clang+llvm-3.7.0-rc1-amd64-unknown-freebsd10.tar.xz > clang+llvm-3.7.0-rc1-i386-unknown-freebsd10.tar.xz > clang+llvm-3.7.0-rc1-mipsel-linux-gnu.tar.xz > clang+llvm-3.7.0-rc1-mips-linux-gnu.tar.xz > clang+llvm-3.7.0-rc1-x86_64-apple-darwin.tar.xz > clang+llvm-3.7.0-rc1-x86_64-linux-gnu-ubuntu-15.04.tar.xz > LLVM-3.7.0-rc1-win32.exe > LLVM-3.7.0-rc1-win64.exe > > Some of these have the /usr/local prefix baked in (since fixed in > r242706); I'll remove that manually before publishing the tarballs. > > The armv7a tarball doesn't have rc1 in the name. I'll rename that (and > the dir within) before publishing. > > Fedora and OpenSUSE isn't ready yet, but those can be added later. I > think we have enough binaries to put RC1 on the web page. > > Issues > =====> Various compiler-rt test failures, see below. > (Linux/signal_segv_handler.cc might be fixed by r242848.) > > Dimitry says he'll use the autoconf build for FreeBSD due to errors. > Has a patch out to do this in the script, but it hasn't landed yet. > (Darwin currently also defaults to autoconf in the script) > > Jack Howarth asked about -fopenmp currently essentially being no-op. > As far as I know (please correct me if I'm wrong here) this is still > the case on trunk. If it's not enabled on trunk, there is nothing to > merge. > > There is a discussion on openmp-dev about the CMake build being broken > in Pathscale's build. The breakage does not seem to be well understood > yet. > > Nikola reports that compiler-rt fails to cmake on x86 openSUSE because > it targets i686, but the system is i586. Same failure happens on the > phase 2 build on x86 Fedora 22, but probably with a different cause. > > Renato reported libunwind was missing from the projects list, > preventing libcxxabi and libcxx to build. It was added in r242543, but > there are still problems and Renato said he'll exclude them for this > release. > > Files in the tarball were prefixed with /usr/local; fixed in r242706. > > The clean_rpath function was failing when no rpath was present in the > binary; fixed in r242722 > > The file comparison step was broken as cmp(1) doesn't support > --ignore-initial on all platforms; fixed in r242721. > > Object/archive-extract.test failed on windows; fixed in r242527 > > Ben reports that he didn't get a tarball even after the rpath fix and > had to disable -o pipefail to get one. Still not sure what caused > this. > > > > Thanks, > Hans > > > Appendix: compiler-rt test failures > ==================================> From Ben on Ubuntu 14.04 x64: > > AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc > MemorySanitizer :: Linux/tcgetattr.cc > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent > MemorySanitizer-Unit :: Msan-x86_64- > Test/MemorySanitizer.gethostent_r > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.gethostent > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r > MemorySanitizer-Unit :: Msan-x86_64-with-call- > Test/MemorySanitizer.getmntent > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r > SanitizerCommon-asan :: Linux/getpass.cc > SanitizerCommon-asan :: Posix/decorate_proc_maps.cc > SanitizerCommon-lsan :: Linux/getpass.cc > SanitizerCommon-msan :: Linux/getpass.cc > SanitizerCommon-msan :: Linux/signal_segv_handler.cc > SanitizerCommon-msan :: Posix/decorate_proc_maps.cc > SanitizerCommon-tsan :: Linux/getpass.cc > SanitizerCommon-tsan :: Posix/decorate_proc_maps.cc > > From Nikola on Fedora 22 x64: > > LeakSanitizer-AddressSanitizer :: TestCases/cleanup_in_tsd_destructor.cc > LeakSanitizer-AddressSanitizer :: TestCases/disabler.cc > LeakSanitizer-AddressSanitizer :: TestCases/disabler_in_tsd_destructor.cc > LeakSanitizer-AddressSanitizer :: TestCases/ignore_object.cc > LeakSanitizer-Standalone :: TestCases/cleanup_in_tsd_destructor.cc > LeakSanitizer-Standalone :: TestCases/disabler.cc > LeakSanitizer-Standalone :: TestCases/disabler_in_tsd_destructor.cc > LeakSanitizer-Standalone :: TestCases/ignore_object.cc > > From Ben on x86_64-linux-gnu-ubuntu-15.04: > > MemorySanitizer :: Linux/tcgetattr.cc > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r > MemorySanitizer-Unit :: Msan-x86_64-with-call- > Test/MemorySanitizer.getmntent > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r > SanitizerCommon-asan :: Linux/getpass.cc > SanitizerCommon-lsan :: Linux/getpass.cc > SanitizerCommon-msan :: Linux/getpass.cc > SanitizerCommon-tsan :: Linux/getpass.cc > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Hans Wennborg
2015-Jul-23 00:42 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Mon, Jul 20, 2015 at 2:26 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:> Here's the current status for the Mips packages.[..]> clang+llvm-3.7.0-rc1-mips-linux-gnu.tar.xzThe root directory in this file is "clang+llvm-3.7.0-rc1-mipsel-linux-gnu". Is it just the name that's wrong, or does it actually have files for the wrong target?
Apparently Analagous Threads
- [LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
- [LLVMdev] [cfe-dev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
- [LLVMdev] [3.6 Release] RC4 has been tagged
- [LLVMdev] [cfe-dev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
- [LLVMdev] [3.6 Release] RC4 has been tagged