[3.8 Release] RC1 has been tagged

...

* Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the last version that can build without C++11 support), and it crashes with a segfault during building of CGBlocks.cpp. I'll need to find some way to work around this failure, since we cannot upgrade the compiler easily on FreeBSD 10.x.

This sounds like the biggest problem. Is there a PR for the crash? I
suppose the alternatives are either to try not to tickle the crash in
our source, or fixing the 3.4.1 compiler?

There is no PR, but I did a bisection, and the crash turns out to be fixed by r210467 ("[DAG] Expose NoSignedWrap, NoUnsignedWrap and Exact flags to SelectionDAG.") by Andrea DiBiagio.

And I finally found out this was a red herring, and I had already solved this issue before, in July 2015 [1], with excellent help from Andrea! This was originally known as PR24249, and eventually turned out to be solved by llvm r219009.

However, the two build VMs I have been using for LLVM release testing were never updated to include the fix, and were still at the version of FreeBSD from roughly May 2015.

I have now been able to do a successful build of the llvm, clang and (for amd64) openmp. Uploaded the following tarballs:

SHA256 (clang+llvm-3.8.0-rc1-amd64-unknown-freebsd10.tar.xz) = 28b8f7758736dab181da9e5e445eb734b134a579ed79bcf8b040d4a7d5c9d31d
SHA256 (clang+llvm-3.8.0-rc1-i386-unknown-freebsd10.tar.xz) = ba9712964c56bcc9ba50f511f2a98757d321d5cd1c7989790029dd64c3db6db4

I will now spend some time to see if I can get more components to build for the next release candidate.

-Dimitry

[1] [base] Revision 286033
[2] https://llvm.org/bugs/show_bug.cgi?id=24249
[3] http://llvm.org/viewvc/llvm-project?view=revision&revision=219009

I would like to take a look at the errors, can you send me the full output?
Unfortunatly I no longer have a FreeBSD machine to test on, but I think
it's important libc++ gets/keeps the test suite clean on FreeBSD.

/Eric

Uploaded Win binaries to the sftp:
842c6b6165089cd0771020c0bdb542456690aab9 LLVM-3.8.0-rc1-win32.exe
5031bd338856b3cd06fce260c9cc1c2445536963 LLVM-3.8.0-rc1-win64.exe

- Hans

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.

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?

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.

371rc2_test_failures.txt (1.73 KB)

Something is failing on 32bit Fedora 23 (compiler-rt?), test suite looks good.

llvm.check-Phase3-Release.log (40.2 KB)

Two libc++ tests fail on 64bit Fedora 23, get_monthname and get_monthname_wide. Test suite looks good.

Uploaded in Debian. Waiting for approval as it is a new package.
By the way, I'd like to mention that it is the first upload in Debian
(and therefor Ubuntu) to be built with Cmake. I would like
to send a HUGE thanks to Andrew Wilkins who did all the work!
Many thanks. This also means that compiler-rt should be back soon
on http://llvm.org/apt/

However, under Debian amd64, the following clang tests are failing
    Clang :: CodeGen/address-safety-attr.cpp
    Clang :: CodeGen/asan-globals.cpp
    Clang :: CodeGen/linux-arm-atomic.c
    Clang :: CodeGen/sanitize-init-order.cpp
    Clang :: CodeGen/sanitize-thread-attr.cpp
    Clang :: CodeGen/ubsan-blacklist.c
    Clang :: Driver/arm-features.c
    Clang :: Driver/arm-ias-Wa.s
    Clang :: Driver/arm-mfpu.c
    Clang :: Preprocessor/arm-acle-6.5.c
    Clang :: Preprocessor/arm-target-features.c

I experienced the same test failures with 3.7.1 for the codegen tests:
https://llvm.org/bugs/show_bug.cgi?id=25712
https://llvm.org/bugs/show_bug.cgi?id=25713
https://llvm.org/bugs/show_bug.cgi?id=25714
https://llvm.org/bugs/show_bug.cgi?id=25715

I will have a look to the new tests when I have time.
Full log: http://sylvestre.ledru.info/bordel/clang-check.log
(forget about Sema/builtins.c & SemaCXX/warn-memsize-comparison.cpp,
they are knew known issues:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651454
/ https://llvm.org/bugs/show_bug.cgi?id=11533 )

Cheers,
Sylvestre

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?

I built rc1 on Ubuntu 15.04 armhf. Many tests fail (560, nearly all are libc++ and libc++abi). There’s also a handful of unexpected passing tests (12).

e29ac68df06f7fad8c773b7da9778469d84f3f32 rc1/clang+llvm-3.8.0-rc1-linux-armhf-vivid.tar.xz

I have some proper rc1 results now.

clang+llvm-3.8.0-rc1-mips-linux-gnu.tar.xz
  test-release.sh refused to run 'make check-all' because libcxx_tsan failed to configure. This is because the thread sanitizer is not supported on MIPS32.
  After working around this (patch will follow shortly):
    ~200 sanitizer failures. Most of them tsan (which as noted above shouldn't be running), but other sanitizers too.
  lots of libc++ failures split into two cases:
    (No ticket yet) - Missing builtins for 64-bit atomics. Vasileios Kalintiris has given me a patch that should fix this
    PR26277 - Some diagnostic checking tests fail because the assembler can't find it's input file. Clang didn't create it due to frontend errors but still called GAS.

clang+llvm-3.8.0-rc1-mipsel-linux-gnu.tar.xz
  lots of libc++ failures split into two cases:
    (No ticket yet) - Missing builtins for 64-bit atomics. Vasileios Kalintiris has given me a patch that should fix this
    PR26277 - Some diagnostic checking tests fail because the assembler can't find it's input file. Clang didn't create it due to frontend errors but still called GAS.
  Test-suite was ok.

clang+llvm-3.8.0-rc1-x86_64-linux-gnu-debian8.tar.xz (native X86_64)
  PR26252 - libc++ fails 23 tests due to missing en_US-UTF8 locale. I have two patches in progress for this and I've also made the problem go away by enabling this locale.
  PR26253 - libomp fails runtime/test/barrier/omp_barrier.c
  Test-suite was ok

clang+llvm-3.8.0-rc1-x86_64-linux-gnu-debian8.tar.xz (cross compiling to Mips)
  10/23 test-suite configs ok. The rest are still running.

Ideally, all tests should pass on the platforms we build for. In your
case, it's not even very exotic, just x86_64 Linux. The LLVM and Clang
tests are pretty good in this regard, but various sanitizer and libc++
tests seem less stable. In practice, we've been releasing as long as
the failures don't look like regressions from previous releases.

Phase1 fails to build on openSUSE 13.2, can anyone see what’s wrong from this log file?

log.zip (161 KB)

Something wrong with the test-suite:

make -f CMakeFiles/test-suite.dir/build.make CMakeFiles/test-suite.dir/depend
make[2]: Entering directory
'/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
CMakeFiles/test-suite.dir/build.make:112: *** target pattern contains
no '%'. Stop.
make[2]: Leaving directory
'/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
CMakeFiles/Makefile2:198: recipe for target
'CMakeFiles/test-suite.dir/all' failed
make[1]: *** [CMakeFiles/test-suite.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

The test-suite shouldn’t be being build with CMake for the release - the CMake system is not yet ready. Have you accidentally checked out the test-suite into /projects? if it’s there it will auto-configure.

James

If the test-suite setup with CMake is broken, why not replace the CMake auto-detection of the test-suite with an error?
Something like:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index d96afc465177…918da6f6c945 100644
— a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -693,11 +693,7 @@ endif()

if( LLVM_INCLUDE_TESTS )
if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite AND TARGET clang)

  • include(LLVMExternalProjectUtils)
  • llvm_ExternalProject_Add(test-suite ${LLVM_MAIN_SRC_DIR}/projects/test-suite
  • USE_TOOLCHAIN
  • EXCLUDE_FROM_ALL
  • NO_INSTALL)
  • message(FATAL_ERROR “The test-suite cannot be built in-tree with CMake at that time”)
    endif()
    add_subdirectory(test)
    add_subdirectory(unittests)

Have you accidentally checked out the test-suite into /projects? if it’s there it will auto-configure

We fixed it for rc1 but test-release.sh used to put the test-suite there.

It seems that test-release was fixed, thanks everyone. Builds are OK but I’d like to know where did test-suite go? All I see is the llvm.src directory, am I supposed to export test-suite myself?

I’ve been putting together a patch to bring that back and I’ve just posted it as http://reviews.llvm.org/D16679.