Eric Fiselier via llvm-dev
2016-Jan-22 02:31 UTC
[llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged
On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < cfe-dev at lists.llvm.org> wrote:> SuSE Linux Enterprise Server 11SP3 x86_64 > > Looks like I see several failures that weren't in 3.7.1. Is there any way > to tell whether these are regressions vs new-to-3.8.0-but-failing? The > MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were > not in 3.7.1. > >All of the libc++ failures seem like non-issues and should be in 3.7.1. Did you change or upgrade your platform or libc version? I'm not sure about the libc++abi error though.> ~~~~~~~~~~~~~~~~ > Failing Tests (27): > LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async > LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier > LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs > LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture > LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction > MemorySanitizer :: Linux/obstack.cc > MemorySanitizer :: Linux/process_vm_readv.cc > MemorySanitizer :: fork.cc > MemorySanitizer :: iconv.cc > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent > MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.getgrent > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.getpwent > MemorySanitizer-Unit :: > Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r > SanitizerCommon-Unit :: > Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize > ThreadSanitizer :: Linux/mutex_robust.cc > ThreadSanitizer :: Linux/mutex_robust2.cc > ThreadSanitizer :: thread_name2.cc > libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp >This is caused because the system does not provide a uchar.h header.> libc++ :: > std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp > libc++ :: > std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp >These are marked XFAIL on open-suse, They should probably be marked as XFAIL on your platform as well. Can you send me the output of Python's "platform.linux_distribution()"?> libc++abi :: cxa_thread_atexit_test.pass.cpp >Not sure about this failure. Can you send me the output?> > Expected Passes : 31153 > Expected Failures : 203 > Unsupported Tests : 518 > Unexpected Failures: 27 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Uploads: > 7b837b2c4b7884a4277b947b795948ecd983b0f3 > clang+llvm-3.8.0-rc1-linux-x86_64-sles11.3.tar.xz > > > On Tue, Jan 19, 2016 at 5:55 PM, Hans Wennborg <hans at chromium.org> wrote: > >> (cc'ing non-legacy llvm-dev this time; apologies if you get this >> twice. Please don't reply-all to the first one.) >> >> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at chromium.org> wrote: >> > Dear testers, >> > >> > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at >> > r258223. (It took a little longer than I'd planned, sorry about that.) >> > >> > There are still a bunch of open merge requests and bug reports, but I >> > wanted to get the tag in so we can see what the build and test status >> > are on the various platforms. >> > >> > I verified that it currently builds and tests cleanly for me on x86_64 >> > Linux, Mac OS X* and Windows. >> > >> > Please build, test, and upload binaries to the sftp. Let me know if how >> it goes. >> > >> > Thanks, >> > Hans >> > >> > >> > [*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`" >> > CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work, >> > otherwise stage-2 Clang couldn't find the SDK. I don't remember if I >> > had to do this last time; maybe some upgrade changed something. >> > > > > -- > -Brian > > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/8dcd10bd/attachment.html>
Brian Cain via llvm-dev
2016-Jan-22 03:52 UTC
[llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged
On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier <eric at efcs.ca> wrote:> > On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> SuSE Linux Enterprise Server 11SP3 x86_64 >> >> Looks like I see several failures that weren't in 3.7.1. Is there any >> way to tell whether these are regressions vs new-to-3.8.0-but-failing? The >> MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were >> not in 3.7.1. >> >> > All of the libc++ failures seem like non-issues and should be in 3.7.1. > Did you change or upgrade your platform or libc version? I'm not sure > about the libc++abi error though. >I don't recall any changes to libc. Attached is the testing log from 3.7.1 rc2 (I don't have logs from -final handy). I can repeat a 3.7.1 release build on this system now. I don't think the results will change, though.> ~~~~~~~~~~~~~~~~ >> Failing Tests (27): >> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async >> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier >> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs >> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture >> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction >> MemorySanitizer :: Linux/obstack.cc >> MemorySanitizer :: Linux/process_vm_readv.cc >> MemorySanitizer :: fork.cc >> MemorySanitizer :: iconv.cc >> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r >> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent >> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r >> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent >> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r >> MemorySanitizer-Unit :: >> Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r >> MemorySanitizer-Unit :: >> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent >> MemorySanitizer-Unit :: >> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r >> MemorySanitizer-Unit :: >> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent >> MemorySanitizer-Unit :: >> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r >> SanitizerCommon-Unit :: >> Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize >> ThreadSanitizer :: Linux/mutex_robust.cc >> ThreadSanitizer :: Linux/mutex_robust2.cc >> ThreadSanitizer :: thread_name2.cc >> libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp >> > > This is caused because the system does not provide a uchar.h header. > > >> libc++ :: >> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp >> libc++ :: >> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp >> > > > These are marked XFAIL on open-suse, They should probably be marked as > XFAIL on your platform as well. > Can you send me the output of Python's "platform.linux_distribution()"? > >Ok, I'll be able to get this tomorrow. But I suspect it will be "('SUSE Linux Enterprise Server ', '11', 'x86_64')"> libc++abi :: cxa_thread_atexit_test.pass.cpp >> > > Not sure about this failure. Can you send me the output? > >That one failed in 3.7.1 also. IIRC this libstdc++ doesn't have cxa_thread_atexit. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/d7d9413d/attachment-0001.html> -------------- next part -------------- Compilation failed unexpectedly! ******************** Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. Testing Time: 272.89s ******************** Failing Tests (18): MemorySanitizer :: Linux/obstack.cc MemorySanitizer :: fork.cc MemorySanitizer :: iconv.cc MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getgrent MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getpwent MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r SanitizerCommon-Unit :: Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize ThreadSanitizer :: Linux/mutex_robust.cc ThreadSanitizer :: Linux/mutex_robust2.cc ThreadSanitizer :: thread_name2.cc libc++abi :: cxa_thread_atexit_test.pass.cpp Expected Passes : 24070 Expected Failures : 132 Unsupported Tests : 374 Unexpected Failures: 18 make[3]: *** [CMakeFiles/check-all] Error 1 make[3]: Target `CMakeFiles/check-all.dir/build' not remade because of errors. make[2]: *** [CMakeFiles/check-all.dir/all] Error 2 make[1]: *** [CMakeFiles/check-all.dir/rule] Error 2 make[1]: Target `check-all' not remade because of errors. make: *** [check-all] Error 2 [Release Phase3] check-all failed
Nikola Smiljanic via llvm-dev
2016-Jan-22 11:09 UTC
[llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged
Something is failing on 32bit Fedora 23 (compiler-rt?), test suite looks good. On Fri, Jan 22, 2016 at 2:52 PM, Brian Cain via cfe-dev < cfe-dev at lists.llvm.org> wrote:> On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier <eric at efcs.ca> wrote: > >> >> On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> SuSE Linux Enterprise Server 11SP3 x86_64 >>> >>> Looks like I see several failures that weren't in 3.7.1. Is there any >>> way to tell whether these are regressions vs new-to-3.8.0-but-failing? The >>> MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were >>> not in 3.7.1. >>> >>> >> All of the libc++ failures seem like non-issues and should be in 3.7.1. >> Did you change or upgrade your platform or libc version? I'm not sure >> about the libc++abi error though. >> > > I don't recall any changes to libc. Attached is the testing log from > 3.7.1 rc2 (I don't have logs from -final handy). > > I can repeat a 3.7.1 release build on this system now. I don't think the > results will change, though. > > > >> ~~~~~~~~~~~~~~~~ >>> Failing Tests (27): >>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async >>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier >>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs >>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture >>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction >>> MemorySanitizer :: Linux/obstack.cc >>> MemorySanitizer :: Linux/process_vm_readv.cc >>> MemorySanitizer :: fork.cc >>> MemorySanitizer :: iconv.cc >>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r >>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent >>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r >>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent >>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r >>> MemorySanitizer-Unit :: >>> Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r >>> MemorySanitizer-Unit :: >>> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent >>> MemorySanitizer-Unit :: >>> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r >>> MemorySanitizer-Unit :: >>> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent >>> MemorySanitizer-Unit :: >>> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r >>> SanitizerCommon-Unit :: >>> Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize >>> ThreadSanitizer :: Linux/mutex_robust.cc >>> ThreadSanitizer :: Linux/mutex_robust2.cc >>> ThreadSanitizer :: thread_name2.cc >>> libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp >>> >> >> This is caused because the system does not provide a uchar.h header. >> >> >>> libc++ :: >>> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp >>> libc++ :: >>> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp >>> >> >> >> These are marked XFAIL on open-suse, They should probably be marked as >> XFAIL on your platform as well. >> Can you send me the output of Python's "platform.linux_distribution()"? >> >> > > Ok, I'll be able to get this tomorrow. But I suspect it will be "('SUSE > Linux Enterprise Server ', '11', 'x86_64')" > > >> libc++abi :: cxa_thread_atexit_test.pass.cpp >>> >> >> Not sure about this failure. Can you send me the output? >> >> > That one failed in 3.7.1 also. IIRC this libstdc++ doesn't have > cxa_thread_atexit. > > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/75a1afce/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.check-Phase3-Release.log Type: text/x-log Size: 41123 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/75a1afce/attachment.bin>
Brian Cain via llvm-dev
2016-Jan-24 22:48 UTC
[llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged
On Thu, Jan 21, 2016 at 9:52 PM, Brian Cain <brian.cain at gmail.com> wrote:> On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier <eric at efcs.ca> wrote: > >> >> On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> SuSE Linux Enterprise Server 11SP3 x86_64 >>> >>> Looks like I see several failures that weren't in 3.7.1. Is there any >>> way to tell whether these are regressions vs new-to-3.8.0-but-failing? The >>> MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were >>> not in 3.7.1. >>> >>> >> All of the libc++ failures seem like non-issues and should be in 3.7.1. >> Did you change or upgrade your platform or libc version? I'm not sure >> about the libc++abi error though. >> > > I don't recall any changes to libc. Attached is the testing log from > 3.7.1 rc2 (I don't have logs from -final handy). > > I can repeat a 3.7.1 release build on this system now. I don't think the > results will change, though. > >I discussed this more with Eric off-list and I think we've come to the conclusion that this was not a regression, it was my error. It's a bit tricky -- what should I expect for a new platform? All failing tests are likely failing because they can't be/aren't yet supported? It's tough to distinguish -- are they real bugs to be fixed, errors in the build/release process? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160124/ed86f723/attachment.html>