[7.0.0 Release] rc1 has been tagged

Dear testers,

7.0.0-rc1 was just tagged (from the branch at r338847).

It's early in the release process, but I'd like to find out what the
status is of the branch on our various platforms.

Please run the test script, share the results, and upload binaries.

Thanks,
Hans

Hi Hans,

I was just trying to push a release note about DWARF v5 support. I did:
  git checkout release_70 # in the monorepo
  git commit <update to llvm/docs/ReleaseNotes.rst>
  git llvm push
but that fails. How do you want to do release notes?

Thanks,
--paulr

Hi Hans,

I was just trying to push a release note about DWARF v5 support. I did:
  git checkout release_70 # in the monorepo
  git commit <update to llvm/docs/ReleaseNotes.rst>
  git llvm push
but that fails. How do you want to do release notes?

I'm not familiar with "git llvm", but I suspect it doesn't work for
release branches. Can you just svn commit it instead?

Thanks,
Hans

From: hwennborg@google.com [mailto:hwennborg@google.com] On Behalf Of Hans
Wennborg
Sent: Friday, August 03, 2018 9:40 AM
To: Robinson, Paul
Cc: Release-testers; llvm-dev; openmp-dev (openmp-dev@lists.llvm.org);
LLDB Dev
Subject: Re: [cfe-dev] [7.0.0 Release] rc1 has been tagged

> Hi Hans,
>
> I was just trying to push a release note about DWARF v5 support. I did:
> git checkout release_70 # in the monorepo
> git commit <update to llvm/docs/ReleaseNotes.rst>
> git llvm push
> but that fails. How do you want to do release notes?

I'm not familiar with "git llvm", but I suspect it doesn't work for
release branches. Can you just svn commit it instead?

"git llvm" is a script for tying together the monorepo with svn.
I'll do an svn checkout of the release branch and do the note there.
--paulr

Paul,

Are you using llvm-project-20170507.git ?

Regarding to release_70, I am updating it manually, due to each repo.git/release_70 might not be up-to-date. In fact, openmp.git/release_70 isn’t yet.

Sorry for the inconvenience. Please be patient.

All Zig tests passed with a debug build of LLVM/Clang/LLD 7.0.0rc1.

Hmm, I'm running into a rather nasty snag now on i386-freebsd11, due to our lack of atomic 64 bit primitives; Phase2's configure dies with:

    -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB
    -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success
    -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB
    -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed
    -- Looking for __atomic_load_8 in atomic
    -- Looking for __atomic_load_8 in atomic - not found
    CMake Error at cmake/modules/CheckAtomic.cmake:75 (message):
      Host compiler appears to require libatomic, but cannot find it.

Interestingly, Phase1 does *not* suffer from this, but there the "host compiler" is clang 6.0.0.

Phase1 CMake output:

    Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS64_WITHOUT_LIB succeeded with the following output:
    Change Dir: /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp

    Run Build Command:"/usr/local/bin/gmake" "cmTC_845df/fast"
    /usr/local/bin/gmake -f CMakeFiles/cmTC_845df.dir/build.make CMakeFiles/cmTC_845df.dir/build
    gmake[1]: Entering directory '/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
    Building CXX object CMakeFiles/cmTC_845df.dir/src.cxx.o
    /usr/bin/c++ -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11 -Werror=unguarded-availability-new -o CMakeFiles/cmTC_845df.dir/src.cxx.o -c /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp/src.cxx
    Linking CXX executable cmTC_845df
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_845df.dir/link.txt --verbose=1
    /usr/bin/c++ -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11 -Werror=unguarded-availability-new CMakeFiles/cmTC_845df.dir/src.cxx.o -o cmTC_845df -lm
    gmake[1]: Leaving directory '/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'

    Source file was:

    #include <atomic>
    #include <cstdint>
    std::atomic<uint64_t> x (0);
    int main() {
      uint64_t i = x.load(std::memory_order_relaxed);
      return 0;
    }

Phase2 CMake output:

    Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS64_WITHOUT_LIB failed with the following output:
    Change Dir: /home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp

    Run Build Command:"/usr/local/bin/gmake" "cmTC_720f3/fast"
    /usr/local/bin/gmake -f CMakeFiles/cmTC_720f3.dir/build.make CMakeFiles/cmTC_720f3.dir/build
    gmake[1]: Entering directory '/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
    Building CXX object CMakeFiles/cmTC_720f3.dir/src.cxx.o
    /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.install/usr/local/bin/clang++ -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11 -Werror=unguarded-availability-new -o CMakeFiles/cmTC_720f3.dir/src.cxx.o -c /home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp/src.cxx
    Linking CXX executable cmTC_720f3
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_720f3.dir/link.txt --verbose=1
    /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.install/usr/local/bin/clang++ -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11 -Werror=unguarded-availability-new CMakeFiles/cmTC_720f3.dir/src.cxx.o -o cmTC_720f3 -lm
    CMakeFiles/cmTC_720f3.dir/src.cxx.o: In function `main':
    src.cxx:(.text+0x33): undefined reference to `__atomic_load_8'
    clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
    gmake[1]: *** [CMakeFiles/cmTC_720f3.dir/build.make:98: cmTC_720f3] Error 1
    gmake[1]: Leaving directory '/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
    gmake: *** [Makefile:126: cmTC_720f3/fast] Error 2

    Source file was:

    #include <atomic>
    #include <cstdint>
    std::atomic<uint64_t> x (0);
    int main() {
      uint64_t i = x.load(std::memory_order_relaxed);
      return 0;
    }

Apparently, with clang 6.0 it didn't generate libcalls to atomic functions, but just put in cmpxchg8b's, I guess? And with clang 7.0 this seems to have changed.

For now, I can only test on amd64 due to this, since I don't have an easy workaround.

-Dimitry

Couldn’t it be the consequence of https://github.com/llvm-mirror/compiler-rt/commit/e8b47a537f4c849e66e450dadddfbfe03d1f06fd#diff-376935638380b425bdd8d9c735545491?

This doesn't sound so good, but I'm glad we found out early.

Did you file a bug to track this? (Sorry if you already did, I haven't
read through the list today.)

Thanks,
Hans

Windows is ready:

$ sha1sum LLVM-7.0.0-rc1-win*.exe
9c5662a622be0b73880d366b1c9d146907844b38 LLVM-7.0.0-rc1-win32.exe
b7e4ff1e748de3aaa6c3730a55d7ab01a23d0795 LLVM-7.0.0-rc1-win64.exe

Built with the attached batch file.

build_llvm_700-rc1.bat|attachment (4.09 KB)

Hi,

There are a few libc++ tests and a libFuzzer test failing on macOS/x86_64, but everything else looks good. I'll file PRs for the failures.

Uploaded: clang+llvm-7.0.0-rc1-x86_64-apple-darwin.tar.xz
SHA256: 236b1e0d8787293a928eeeae455466b7273e19ff361e0a0033d59500583c6567

Failing Tests (17):
    libFuzzer :: shrink.test
    libc++ :: std/language.support/support.exception/except.nested/assign.pass.cpp
    libc++ :: std/language.support/support.exception/except.nested/ctor_copy.pass.cpp
    libc++ :: std/language.support/support.exception/except.nested/ctor_default.pass.cpp
    libc++ :: std/language.support/support.exception/except.nested/rethrow_if_nested.pass.cpp
    libc++ :: std/language.support/support.exception/except.nested/rethrow_nested.pass.cpp
    libc++ :: std/language.support/support.exception/propagation/make_exception_ptr.pass.cpp
    libc++ :: std/language.support/support.exception/propagation/rethrow_exception.pass.cpp
    libc++ :: std/thread/futures/futures.async/async.pass.cpp
    libc++ :: std/thread/futures/futures.promise/dtor.pass.cpp
    libc++ :: std/thread/futures/futures.promise/set_exception.pass.cpp
    libc++ :: std/thread/futures/futures.promise/set_exception_at_thread_exit.pass.cpp
    libc++ :: std/thread/futures/futures.shared_future/get.pass.cpp
    libc++ :: std/thread/futures/futures.task/futures.task.members/dtor.pass.cpp
    libc++ :: std/thread/futures/futures.task/futures.task.members/make_ready_at_thread_exit.pass.cpp
    libc++ :: std/thread/futures/futures.task/futures.task.members/operator.pass.cpp
    libc++ :: std/thread/futures/futures.unique_future/get.pass.cpp

  Expected Passes : 51812
  Expected Failures : 260
  Unsupported Tests : 2891
  Unexpected Failures: 17
make[3]: *** [CMakeFiles/check-all] Error 1

thanks,
vedant

7.0.0-rc1 was just tagged (from the branch at r338847).

...

Hmm, I'm running into a rather nasty snag now on i386-freebsd11, due to our lack of atomic 64 bit primitives; Phase2's configure dies with:

   -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB
   -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success
   -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB
   -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed
   -- Looking for __atomic_load_8 in atomic
   -- Looking for __atomic_load_8 in atomic - not found

...

Apparently, with clang 6.0 it didn't generate libcalls to atomic functions, but just put in cmpxchg8b's, I guess? And with clang 7.0 this seems to have changed.

...

Did you file a bug to track this? (Sorry if you already did, I haven't
read through the list today.)

This is a regression caused by https://reviews.llvm.org/rL323281:

Hi,

There are a few libc++ tests and a libFuzzer test failing on macOS/x86_64, but everything else looks good. I'll file PRs for the failures.

Uploaded: clang+llvm-7.0.0-rc1-x86_64-apple-darwin.tar.xz
SHA256: 236b1e0d8787293a928eeeae455466b7273e19ff361e0a0033d59500583c6567

Failing Tests (17):
   libFuzzer :: shrink.test

Thanks Vedant, I’m looking into this one.
The test file was not modified for a while, but started crashing only fairly recently.

I've built and tested for FreeBSD 11 (a.k.a 11-STABLE) this time, since
FreeBSD 10 will be going EOL pretty soon now. Uploaded:

SHA256 (clang+llvm-7.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = ed3191635be26cced8c75d5e57ff7e559f44b927a64c10d22611d8d912cf6df4

I posted the full test results here:

https://gist.github.com/DimitryAndric/64e9a7805a01e6027e2aaabfcda42bed

Summary:
  Expected Passes : 50388
  Expected Failures : 233
  Unsupported Tests : 3687
  Unexpected Passes : 1
  Unexpected Failures: 2490

The failures are distributed as follows:

  2028 libc++
   205 AddressSanitizer-i386-freebsd-dynamic
   200 AddressSanitizer-x86_64-freebsd-dynamic
    20 XRay-Unit
    11 MemorySanitizer-Unit
     7 lldb-Suite
     4 libunwind
     3 XRay-x86_64-freebsd
     3 lldb
     2 ThreadSanitizer-x86_64
     2 UBSan-MemorySanitizer-x86_64
     2 libFuzzer
     1 SanitizerCommon-asan-i386-FreeBSD
     1 SanitizerCommon-asan-x86_64-FreeBSD
     1 libomp

Almost all libc++ failures are due to FreeBSD missing timespec_get(),
and this became mandatory with https://reviews.llvm.org/rL338419:

In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/test/libcxx/containers/unord/next_pow2.pass.cpp:26:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/iostream:38:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ios:216:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__locale:18:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/mutex:191:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__mutex_base:15:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/chrono:795:
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ctime:77:9: error: no member named 'timespec_get' in the global namespace; did you mean 'timespec'?
using ::timespec_get;
      ~~^~~~~~~~~~~~
        timespec
/usr/include/sys/_timespec.h:44:8: note: 'timespec' declared here
struct timespec {
       ^

We're tracking this in FreeBSD here: 230400 – devel/cmake, devel/qt5-buildtools: fails to build with libc++ 7,
but for existing FreeBSD releases this isn't fixable, so we could really
use some sort of workaround in libc++. :slight_smile:

-Dimitry

Dear testers,

7.0.0-rc1 was just tagged (from the branch at r338847).

It's early in the release process, but I'd like to find out what the
status is of the branch on our various platforms.

Please run the test script, share the results, and upload binaries.

I've built and tested for FreeBSD 11 (a.k.a 11-STABLE) this time, since
FreeBSD 10 will be going EOL pretty soon now. Uploaded:

SHA256 (clang+llvm-7.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = ed3191635be26cced8c75d5e57ff7e559f44b927a64c10d22611d8d912cf6df4

I posted the full test results here:

https://gist.github.com/DimitryAndric/64e9a7805a01e6027e2aaabfcda42bed

Summary:
Expected Passes : 50388
Expected Failures : 233
Unsupported Tests : 3687
Unexpected Passes : 1
Unexpected Failures: 2490

The failures are distributed as follows:

2028 libc++
  205 AddressSanitizer-i386-freebsd-dynamic
  200 AddressSanitizer-x86_64-freebsd-dynamic
   20 XRay-Unit
   11 MemorySanitizer-Unit
    7 lldb-Suite
    4 libunwind
    3 XRay-x86_64-freebsd
    3 lldb
    2 ThreadSanitizer-x86_64
    2 UBSan-MemorySanitizer-x86_64
    2 libFuzzer
    1 SanitizerCommon-asan-i386-FreeBSD
    1 SanitizerCommon-asan-x86_64-FreeBSD
    1 libomp

Almost all libc++ failures are due to FreeBSD missing timespec_get(),
and this became mandatory with https://reviews.llvm.org/rL338419:

In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/test/libcxx/containers/unord/next_pow2.pass.cpp:26:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/iostream:38:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ios:216:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__locale:18:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/mutex:191:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__mutex_base:15:
In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/chrono:795:
/home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ctime:77:9: error: no member named 'timespec_get' in the global namespace; did you mean 'timespec'?
using ::timespec_get;
     ~~^~~~~~~~~~~~
       timespec
/usr/include/sys/_timespec.h:44:8: note: 'timespec' declared here
struct timespec {
      ^

We're tracking this in FreeBSD here: 230400 – devel/cmake, devel/qt5-buildtools: fails to build with libc++ 7,
but for existing FreeBSD releases this isn't fixable, so we could really
use some sort of workaround in libc++. :slight_smile:

Ugh. The problem here is that libc++ checks whether the underlying C standard library implementation has support for C11 as a whole, not on a function-by-function basis. This means that the easiest workaround is to pretend that FreeBSD does NOT support C11 as a whole, but that is going to be a regression from prior releases, which provided a subset of C11 through libc++.

Generally, I think supporting things on a per-platform basis like this is a bad idea because it becomes a complete maze. Perhaps the current situation justifies a workaround, perhaps only targeted to the LLVM 7 branch. Marshall, what’s your opinion?

Louis

I tested with test-release.sh on CentOS (x86_64) and results were pretty good:
  - Two failing tests in check-all because the system didn't have a static 32bit libstdc++.a (I usually don't build and test 32bit compiler-rt).
  - One build failure in test-suite because it was using the outdated <complex> header from gcc 4.8.5: It appears real() and imaginary() are not declared const in there.

Today I fired our internal install script and found a whole lot of errors in LLDB. Is there a reason LLDB is disabled in test-release.sh?
(For reference Michal already reported some of the failing tests in https://bugs.llvm.org/show_bug.cgi?id=38453, https://bugs.llvm.org/show_bug.cgi?id=38456, and https://bugs.llvm.org/show_bug.cgi?id=38457. I can dig up the full log if needed, I've for now disabled installation of the debugger.)

Cheers,
Jonas

Hi,

There are a few libc++ tests and a libFuzzer test failing on macOS/x86_64, but everything else looks good. I'll file PRs for the failures.

Thanks! Please mark them blocking PR38406 so they're on my radar.

Uploaded: clang+llvm-7.0.0-rc1-x86_64-apple-darwin.tar.xz
SHA256: 236b1e0d8787293a928eeeae455466b7273e19ff361e0a0033d59500583c6567

I'll add this to the pre-release web page.

Thanks for the explanation. Let me know what comes out of the discussion.

Cheers,
Hans

Can you please file a release-blocking PR to make this easier to track?

Thanks,
Hans

Hi,

There are a few libc++ tests and a libFuzzer test failing on macOS/x86_64, but everything else looks good. I'll file PRs for the failures.

Uploaded: clang+llvm-7.0.0-rc1-x86_64-apple-darwin.tar.xz
SHA256: 236b1e0d8787293a928eeeae455466b7273e19ff361e0a0033d59500583c6567

Failing Tests (17):
   libFuzzer :: shrink.test

Committed the fix to trunk.