[3.8 Release] RC3 has been tagged

Dear testers,

Release Candidate 3 has just been tagged [1]. Please build, test, and
upload to the sftp.

If there are no regressions from previous release candidates, this
will be the last release candidate before the final release.

Release notes can still go into the branch.

Thanks again for all your work!
Hans

[1] http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html

On Ubuntu 15.10 x86_64 I got:

Failing Tests (2):
     MemorySanitizer :: Linux/forkpty.cc
     MemorySanitizer :: Linux/tcgetattr.cc

   Expected Passes : 31860
   Expected Failures : 209
   Unsupported Tests : 648
   Unexpected Failures: 2

With RC2 there were no failures, but it looks like 15 tests have been added.

Ben

Windows (sha1):
76f8f91debd2e101b9adc4a6f2230fcd5e18bb5c LLVM-3.8.0-rc3-win32.exe
b87654327d3ae537f8afec06ea0fa63121b9a86e LLVM-3.8.0-rc3-win64.exe

- Hans

Hmm, those two tests are not new, but maybe something changed that
made them run now and not before. Perhaps related to r261162? In any
case, I'm not too worried about these failures, they probably just
didn't run before.

Thanks,
Hans

Uploaded and tested for ARM and AArch64, all good.

Remember, this is *not* using a new Linux, so the GCC 5 issue doesn't
apply. I'm hoping we fix the issue for 3.9, so that I can update our
machine and test newer system behaviour.

cheers,
--renato

Built and tested just fine on FreeBSD 10. Uploaded the following tarballs:

SHA256 (clang+llvm-3.8.0-rc3-amd64-unknown-freebsd10.tar.xz) = 0ac847a23b881d27883b83add8926fff8265b650ef6fbf49bae3fc145305399a
SHA256 (clang+llvm-3.8.0-rc3-i386-unknown-freebsd10.tar.xz) = 91a0f3c108f9baa9e0f374931f2efa1b1e2413b0ae3a6217fb8bf4111c5c4adb

-Dimitry

Uploaded:
clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10.tar.xz
clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz

On Ubuntu 16.04 x86_64:

Failing Tests (7):
     MemorySanitizer :: Linux/forkpty.cc
     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
     Profile :: instrprof-error.c

   Expected Passes : 31128
   Expected Failures : 172
   Unsupported Tests : 615
   Unexpected Failures: 7

On Ubuntu 15.10 x86_64:

Failing Tests (2):
     MemorySanitizer :: Linux/forkpty.cc
     MemorySanitizer :: Linux/tcgetattr.cc

   Expected Passes : 31860
   Expected Failures : 209
   Unsupported Tests : 648
   Unexpected Failures: 2

On Ubuntu 14.04 x86_64:

Failing Tests (9):
     MemorySanitizer :: Linux/forkpty.cc
     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
     Profile :: instrprof-error.c
     libc++ :: std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
     libc++ :: std/localization/locales/locale/locale.cons/char_pointer.pass.cpp

   Expected Passes : 31194
   Expected Failures : 195
   Unsupported Tests : 526
   Unexpected Failures: 9

LNT results look good, although they are, perhaps 20% slower than most of my previous runs.

Ben

Uploaded Fedora and openSUSE binaries. Looking good.

Hi,

I’ve run into some unexpected problems with the rc3 tarballs for OSX and would like to ask for advice.

I’ve repeatedly started from scratch (that’s what’s been taking so long) only to always end up at the same point: When Phase3 is built and the tests are run, I get a hang. Immediately, before a single test is run. Every time. There’s a few lines of the type

lit.py: util.py:254: note: using SDKROOT: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk'
lit.py: lit.cfg:195: note: using clang: '/Users/pipping/llvm-testing/rc3/Phase3/Release/llvmCore-3.8.0-rc3.obj/./bin/clang'
lit.py: util.py:254: note: using SDKROOT: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk'

and then silence. I can also manually reproduce this by `cd`ing to

  rc3/Phase3/Release/llvmCore-3.8.0-rc3.obj/

and running `make check-all` from there. The line that I then get (that I otherwise don’t see) is

                          -- Testing: 32833 tests, 4 threads --
  0% [-----------------------------------------------------------------------------------]

beyond which there is no progress. A Ctrl-C tells me

File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/queues.py", line 268, in _feed
    send(obj)

here. The actual command that is run can be obtained via

  % make -n check-all | grep -w lit

It is

  % /usr/bin/python2.7 /Users/pipping/llvm-testing/rc3/llvm.src/utils/lit/lit.py -sv

followed by a few config files and then large amounts of test directories. If I put them into corresponding arrays, that’s

  % /usr/bin/python2.7 /Users/pipping/llvm-testing/rc3/llvm.src/utils/lit/lit.py -sv ${args[@]} ${tests[@]}

Now, it’s clear that not a single test is to blame: There are 28 test directories (the last one being by far the largest, containing about half of all tests) and both

  % /usr/bin/python2.7 /Users/pipping/llvm-testing/rc3/llvm.src/utils/lit/lit.py -sv ${args[@]} ${tests[1,27]} # 17231 tests
  % /usr/bin/python2.7 /Users/pipping/llvm-testing/rc3/llvm.src/utils/lit/lit.py -sv ${args[@]} ${tests[28]} # 15602 tests

immediately start to run tests. So it seems to be related to the number of tests or the number of directories. Moreover, it’s related to parallelisation: With

  % /usr/bin/python2.7 /Users/pipping/llvm-testing/rc3/llvm.src/utils/lit/lit.py -j1 -sv ${args[@]} ${tests[@]}

the tests do run but with

  % /usr/bin/python2.7 /Users/pipping/llvm-testing/rc3/llvm.src/utils/lit/lit.py -j2 -sv ${args[@]} ${tests[@]}

they don’t. Finally, I tried this, suspecting that the command might simply be too long

  % /usr/bin/python2.7 /Users/pipping/llvm-testing/rc3/llvm.src/utils/lit/lit.py -sv ${args[@]} \
    $(echo ${tests[@]} | sed s:/Users/pipping/llvm-testing/rc3/Phase3/Release/llvmCore-3.8.0-rc3.obj/:./:g)

but unfortunately that didn’t help.

Now the part that makes me a bit uncomfortable is that I tried again with rc2, which previously worked, but no longer does. I threw my /usr/local out of the window and looked for potential sources. Maybe it’s a system update that I’ve since had. I really have no idea what’s causing this and wonder if anyone has seen something similar.

Elias

It really does sound like a system problem rather than a problem with
any specific tests. It sounds like when trying to run in parallel, the
test framework hangs. Are you still on a beta version of OS X?

FWIV, the tests pass fine on my Mac with -j32.

I, too, was actually convinced it’s my system that’s to blame, when I wrote those lines.

Now I’ve gone through the same process on another mac, which has hardly any software on it (the default, xcode, and cmake, essentially) and hit the very same problem. That one runs the current release of 10.11.

Elias

But something must have changed since rc2 passed and rc3 doesn't. And
since rc2 now doesn't pass either, it can't be the LLVM code.

I did a new run of test-release.sh for rc3 on my Mac, and all tests passed.

Could you have gained a new python version? Some bad environment variable?

I, too, was actually convinced it’s my system that’s to blame, when I wrote those lines.

Now I’ve gone through the same process on another mac, which has hardly any software on it (the default, xcode, and cmake, essentially) and hit the very same problem. That one runs the current release of 10.11.

But something must have changed since rc2 passed and rc3 doesn't. And
since rc2 now doesn't pass either, it can't be the LLVM code.

I agree completely.

I did a new run of test-release.sh for rc3 on my Mac, and all tests passed.

Could you have gained a new python version? Some bad environment variable?

My system could, but the other system (on which I had to create a new user) couldn’t, really.
I know that I upgraded cmake from something to 3.5.0-rc3, so I went back and tested with 3.4.3; didn’t change a thing.

I’m really confused now.

Elias

Uploaded clang+llvm-3.8.0-rc3-linux-x86_64-sles11.3.tar.xz and clang+llvm-3.8.0-rc3-linux-armhf-vivid.tar.xz

f8f8b0ff8f9709cbf63097727a96fde5054efefe rc3/clang+llvm-3.8.0-rc3-linux-x86_64-sles11.3.tar.xz

9202d52a9bff5464d0b76750c41ffec0d7d99c17 rc3/clang+llvm-3.8.0-rc3-linux-armhf-vivid.tar.xz

No new unexpected failures for each.

Hi all,

I’ve found a problem with libclang 3.8RC2

I checked and libclang 3.7 does not have this problem.

I get assertion failed:

src\llvm_package_3.8.0-rc2\llvm\tool…\ASTWriter.cpp Line 4975

Expression 0 && “New decl seen after serializing all the decls to emit!”

I’m trying to integrate this into a new IDE and would be grateful if anyone that’s familiar with this part of libclang could help debug.

Its happening when I’m parsing a complex project so its hard to reproduce, but I’m prepared to do what ever it takes to help you guys fix this, so get in touch.

Kind Regards

Dan

clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c)
  Native: All ok
  Cross compiling to MIPS: All ok

clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f)
  All ok (aside from non-regression failures in check-all).
  There were two kinds of check-all failure:
  * mips64 sanitizers. Not a regression since mip64 sanitizers didn't ship in 3.7.1
  * atomic tests fail due to missing -latomic on link. Not a regression since _no_ libc++ tests ran in 3.7.1 (this was obscured by the -s on llvm-lit).
  Failing Tests (76):
      AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct-activation.cc
      AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct-large.cc
      AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct.cc
      AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-fork-direct.cc
      AddressSanitizer-mips64-linux :: TestCases/Posix/coverage.cc
      DataFlowSanitizer :: custom.cc
      DataFlowSanitizer :: propagate.c
      LeakSanitizer-AddressSanitizer :: TestCases/swapcontext.cc
      LeakSanitizer-AddressSanitizer :: TestCases/use_registers.cc
      LeakSanitizer-Standalone :: TestCases/swapcontext.cc
      LeakSanitizer-Standalone :: TestCases/use_registers.cc
      MemorySanitizer :: Linux/process_vm_readv.cc
      MemorySanitizer :: allocator_mapping.cc
      MemorySanitizer :: dlerror.cc
      MemorySanitizer :: dtls_test.c
      MemorySanitizer :: memcmp_test.cc
      MemorySanitizer :: msan_print_shadow3.cc
      MemorySanitizer :: param_tls_limit.cc
      MemorySanitizer :: unaligned_read_origin.cc
      MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.SmallPreAllocatedStackThread
      MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedLoad
      MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedStore16
      MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise
      MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise2
      MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedStore32
      MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.gethostbyname_r_erange
      MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.ptrtoint
      MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.shmat
      MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
      MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedLoad
      MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16
      MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise
      MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise2
      MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore32
      MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.gethostbyname_r_erange
      MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.ptrtoint
      SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerCommon.FileOps
      SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_LAPIC
      SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_MP_STATE
      SanitizerCommon-asan :: Linux/getpwnam_r_invalid_user.cc
      SanitizerCommon-lsan :: Linux/getpwnam_r_invalid_user.cc
      ThreadSanitizer-mips64 :: atexit2.cc
      ThreadSanitizer-mips64 :: deadlock_detector_stress_test.cc
      ThreadSanitizer-mips64 :: java_alloc.cc
      ThreadSanitizer-mips64 :: java_race_pc.cc
      ThreadSanitizer-mips64 :: longjmp.cc
      ThreadSanitizer-mips64 :: longjmp2.cc
      ThreadSanitizer-mips64 :: longjmp3.cc
      ThreadSanitizer-mips64 :: longjmp4.cc
      ThreadSanitizer-mips64 :: map32bit.cc
      ThreadSanitizer-mips64 :: race_on_mutex.c
      ThreadSanitizer-mips64 :: signal_longjmp.cc
      libc++ :: std/atomics/atomics.types.generic/integral.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong_explicit.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_weak.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_weak_explicit.pass.cpp
     libc++ :: std/atomics/atomics.types.oper
  1 warning(s) in tests.
  ations/atomics.types.operations.req/atomic_exchange_explicit.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_add.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_add_explicit.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_and.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_and_explicit.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_or.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_or_explicit.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_sub.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_sub_explicit.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_xor.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_xor_explicit.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_init.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_is_lock_free.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load_explicit.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store_explicit.pass.cpp
      libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/ctor.pass.cpp
  
    Expected Passes : 31225
    Expected Failures : 211
    Unsupported Tests : 875
    Unexpected Failures: 76

clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz
  My machine died during the check-all stage and disappeared from the network. I've fixed it and am currently running the last few bits of test-release.sh manually.

clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c)
        Native: All ok
        Cross compiling to MIPS: All ok

clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f)
        All ok (aside from non-regression failures in check-all).
        There were two kinds of check-all failure:
        * mips64 sanitizers. Not a regression since mip64 sanitizers didn't ship in 3.7.1
        * atomic tests fail due to missing -latomic on link. Not a regression since _no_ libc++ tests ran in 3.7.1 (this was obscured by the -s on llvm-lit).
        Failing Tests (76):
            AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct-activation.cc
            AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct-large.cc
            AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct.cc
            AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-fork-direct.cc
            AddressSanitizer-mips64-linux :: TestCases/Posix/coverage.cc
            DataFlowSanitizer :: custom.cc
            DataFlowSanitizer :: propagate.c
            LeakSanitizer-AddressSanitizer :: TestCases/swapcontext.cc
            LeakSanitizer-AddressSanitizer :: TestCases/use_registers.cc
            LeakSanitizer-Standalone :: TestCases/swapcontext.cc
            LeakSanitizer-Standalone :: TestCases/use_registers.cc
            MemorySanitizer :: Linux/process_vm_readv.cc
            MemorySanitizer :: allocator_mapping.cc
            MemorySanitizer :: dlerror.cc
            MemorySanitizer :: dtls_test.c
            MemorySanitizer :: memcmp_test.cc
            MemorySanitizer :: msan_print_shadow3.cc
            MemorySanitizer :: param_tls_limit.cc
            MemorySanitizer :: unaligned_read_origin.cc
            MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.SmallPreAllocatedStackThread
            MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedLoad
            MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedStore16
            MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise
            MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise2
            MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.UnalignedStore32
            MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.gethostbyname_r_erange
            MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.ptrtoint
            MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.shmat
            MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
            MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedLoad
            MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16
            MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise
            MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise2
            MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore32
            MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.gethostbyname_r_erange
            MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.ptrtoint
            SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerCommon.FileOps
            SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_LAPIC
            SanitizerCommon-Unit :: Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_MP_STATE
            SanitizerCommon-asan :: Linux/getpwnam_r_invalid_user.cc
            SanitizerCommon-lsan :: Linux/getpwnam_r_invalid_user.cc
            ThreadSanitizer-mips64 :: atexit2.cc
            ThreadSanitizer-mips64 :: deadlock_detector_stress_test.cc
            ThreadSanitizer-mips64 :: java_alloc.cc
            ThreadSanitizer-mips64 :: java_race_pc.cc
            ThreadSanitizer-mips64 :: longjmp.cc
            ThreadSanitizer-mips64 :: longjmp2.cc
            ThreadSanitizer-mips64 :: longjmp3.cc
            ThreadSanitizer-mips64 :: longjmp4.cc
            ThreadSanitizer-mips64 :: map32bit.cc
            ThreadSanitizer-mips64 :: race_on_mutex.c
            ThreadSanitizer-mips64 :: signal_longjmp.cc
            libc++ :: std/atomics/atomics.types.generic/integral.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong_explicit.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_weak.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_weak_explicit.pass.cpp
           libc++ :: std/atomics/atomics.types.oper
        1 warning(s) in tests.
        ations/atomics.types.operations.req/atomic_exchange_explicit.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_add.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_add_explicit.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_and.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_and_explicit.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_or.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_or_explicit.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_sub.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_sub_explicit.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_xor.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_xor_explicit.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_init.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_is_lock_free.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load_explicit.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store_explicit.pass.cpp
            libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/ctor.pass.cpp

          Expected Passes : 31225
          Expected Failures : 211
          Unsupported Tests : 875
          Unexpected Failures: 76

clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz
        My machine died during the check-all stage and disappeared from the network. I've fixed it and am currently running the last few bits of test-release.sh manually.

Thanks, let me know how this turns out.

So far, it sounds like there are no new issues in rc3, so I'm hoping
we can make that the final version for 3.8.0 real soon.

Cheers,
Hans

> clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz
> My machine died during the check-all stage and disappeared from the
network. I've fixed it and am currently running the last few bits of test-
release.sh manually.

Thanks, let me know how this turns out.

So far, it sounds like there are no new issues in rc3, so I'm hoping
we can make that the final version for 3.8.0 real soon.

Cheers,
Hans

'check-all' is still killing the machine but I think I know what the problem is. While investigating some of the rc2 problems I noticed that g++-multilib wasn't installed and this was disabling the mips64el sanitizers. Installing this didn't cause problems at the time but I've noticed that some of the mips64el sanitizer tests are very memory hungry. I noticed several occasions where parallel asan tests were consuming ~200% of RAM and it would have been swapping heavily (on a USB2 disk) to cope. If later tests require even more RAM then it would explain why the system stops responding. I'm going to uninstall g++-multilib and rebuild rc3. Hopefully that will make check-all work again.

For now, I've commented out the check-all command and uploaded clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz (sha1sum: e280bf6db094a81f22f4cdf6c0b5955493a11b05). I'm going to run this through my usual test-suites and I should have the results by this evening.

> > clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz
> > My machine died during the check-all stage and disappeared from the
> network. I've fixed it and am currently running the last few bits of test-
> release.sh manually.
>
> Thanks, let me know how this turns out.
>
> So far, it sounds like there are no new issues in rc3, so I'm hoping
> we can make that the final version for 3.8.0 real soon.
>
> Cheers,
> Hans
>

'check-all' is still killing the machine but I think I know what the problem is. While investigating some of the rc2
problems I noticed that g++-multilib wasn't installed and this was disabling the mips64el sanitizers. Installing this
didn't cause problems at the time but I've noticed that some of the mips64el sanitizer tests are very memory hungry.
I noticed several occasions where parallel asan tests were consuming ~200% of RAM and it would have been
swapping heavily (on a USB2 disk) to cope. If later tests require even more RAM then it would explain why the
system stops responding. I'm going to uninstall g++-multilib and rebuild rc3. Hopefully that will make check-all work
again.

It seems there's was still just enough multilib support on the machine to trigger mips64el sanitizers again but having worked around that the parts of lit that aren't mips64el sanitizers are working so far. llvm-lit is still going but big-endian mips and cross compilation was fine so I'm expecting little endian to be ok too. It's showing an ETA of about 90 mins for the remaining tests from clang and llvm at the moment. I'm going to run the MIPS32 sanitizer lit tests after that.

Overall, I think we're probably ready for final. I just can't confirm that rc3 was definitely ok for little endian mips yet.

For now, I've commented out the check-all command and uploaded clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz
(sha1sum: e280bf6db094a81f22f4cdf6c0b5955493a11b05). I'm going to run this through my usual test-suites and I
should have the results by this evening.

The LNT test-suite runs were ok with the rc3 build.

I've uploaded a package in the meantime (sha1sum):
282503c3a56114d5aafbf5c1d64a027f7d732209
clang+llvm-3.8.0-rc3-x86_64-apple-darwin14.4.0.tar.xz