[lldb-dev] [3.8 Release] RC1 has been tagged

[Brian Cain via lldb-dev]

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.

~~~~~~~~~~~~~~~~
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
    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
    libc++abi :: cxa_thread_atexit_test.pass.cpp

  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160121/2e8b0c9f/attachment-0001.html>