[3.7.1 Release] -rc2 has been tagged

Hi,

There was one problem in -rc1, so we had to do another release
candidate. -rc2 has now been tagged and is ready for testing.

-Tom

Hi Tom,

ARM and AArch64 uploaded. All green.

cheers,
--renato

Should I expect the “-openmp” to work for this RC? I got a link error (only in phase 3?). Maybe the fact that it happened in phase 3 suggests some hardware malfunction of mine? Or are there tests executed on phase 3 that aren’t attempted on earlier phases?

$ CC=clang CXX=clang++ ./test-release.sh -release 3.7.1 -rc 2 -j1 -openmp -triple armv7l-ubuntu15.10-linux-gnueabihf

cd /home/brian/src/fuzzpy/llvm_src/llvm/utils/release/rc2/Phase3/openmp/src && /home/brian/src/fuzzpy/llvm_src/llvm/utils/release/rc2/Phase3/Release/llvmCore-3.7.1-rc2.install/usr/local/bin/clang -o test-touch-rt/test-touch /home/brian/src/fuzzpy/llvm_src/llvm/utils/release/rc2/openmp.src/runtime/src/test-touch.c -lpthread /home/brian/src/fuzzpy/llvm_src/llvm/utils/release/rc2/Phase3/openmp/src/libomp.so
/home/brian/src/fuzzpy/llvm_src/llvm/utils/release/rc2/Phase3/openmp/src/libomp.so: undefined reference to `__kmp_invoke_microtask’
clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation)
src/CMakeFiles/libomp-test-touch.dir/build.make:52: recipe for target ‘src/test-touch-rt/.success’ failed
make[3]: *** [src/test-touch-rt/.success] Error 1
make[3]: Leaving directory ‘/home/brian/src/fuzzpy/llvm_src/llvm/utils/release/rc2/Phase3/openmp’
CMakeFiles/Makefile2:271: recipe for target ‘src/CMakeFiles/libomp-test-touch.dir/all’ failed
make[2]: *** [src/CMakeFiles/libomp-test-touch.dir/all] Error 2
make[2]: Leaving directory ‘/home/brian/src/fuzzpy/llvm_src/llvm/utils/release/rc2/Phase3/openmp’
CMakeFiles/Makefile2:93: recipe for target ‘src/CMakeFiles/libomp-micro-tests.dir/rule’ failed
make[1]: *** [src/CMakeFiles/libomp-micro-tests.dir/rule] Error 2
make[1]: Leaving directory ‘/home/brian/src/fuzzpy/llvm_src/llvm/utils/release/rc2/Phase3/openmp’
Makefile:151: recipe for target ‘libomp-micro-tests’ failed
make: *** [libomp-micro-tests] Error 2

Built and tested OK on FreeBSD 10. Uploaded:

SHA256 (clang+llvm-3.7.1-rc2-amd64-unknown-freebsd10.tar.xz) = 814f3212dee930123183157b5a8ff3023520ab8a6a223d89b5a0c4e92305e0ef
SHA256 (clang+llvm-3.7.1-rc2-i386-unknown-freebsd10.tar.xz) = dec78456a585cddfb7631b9f81fbaa77d94f7ec54c1d9d65b41beffbaf8c4146

-Dimitry

Should I expect the "-openmp" to work for this RC?

Only if it worked before on the target you're building to in 3.7.0.

OpenMP support is experimental, so you shouldn't need to have it anyway.

I got a link error (only
in phase 3?). Maybe the fact that it happened in phase 3 suggests some
hardware malfunction of mine? Or are there tests executed on phase 3 that
aren't attempted on earlier phases?

Is this related to the OpenMP? Or a link error in Clang?

--renato

> Should I expect the "-openmp" to work for this RC?

Only if it worked before on the target you're building to in 3.7.0.

Ok, I'll check if I can get it to work on 3.7.0.

> I got a link error (only
> in phase 3?). Maybe the fact that it happened in phase 3 suggests some
> hardware malfunction of mine? Or are there tests executed on phase 3 that
> aren't attempted on earlier phases?

Is this related to the OpenMP? Or a link error in Clang?

AFAICT it's an OpenMP link error (that I got when running "test-release.sh"
with -openmp).

Right. In that case, don't worry too much.

The default release doesn't come with OpenMP, so unless you *want* and
know it *works*, you don't need it.

cheers,
--renato

Well, I preferred that my build would include openmp but didn't know
whether it worked, so was just checking.

So without openmp, I get nonzero "unexpected failures". It's fewer
failures than I saw on RC1 though.

$ clang --version
clang version 3.8.0 (http://llvm.org/git/clang.git
6b6df26f3b3b96552353a593bdc93333cf9ea6c3) (http://llvm.org/git/llvm.git
43928f790962f5f6d796416ae8c90b95efeaf01a)
Target: armv7l-unknown-linux-gnueabihf
Thread model: posix
InstalledDir: /opt/clang-latest/bin
...
  Expected Passes : 22688
  Expected Failures : 141
  Unsupported Tests : 422
  Unexpected Passes : 13
  Unexpected Failures: 31
...

$ clang --version
clang version 3.8.0 (http://llvm.org/git/clang.git

This looks wrong. Are you sure you're testing Phase3?

********************
Failing Tests (31):
    libc++abi :: catch_array_01.pass.cpp
    libc++abi :: catch_array_02.pass.cpp
(...)

I'm seeing these failures when building with Clang, too. That's why I
still don't release them as is for ARM.

However, the libc++ buildbot, which I assume is running the same
tests, is green, so it may just be a configuration issue that we
haven't solved in CMake yet.

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-arm-linux

That's why I'm not too worried about it for now, but I don't want to
include in the release as of yet, until I'm sure what it is and fix
it.

cheers,
--renato

I've uploaded the following builds:
  054eded5b0f921ea027613bc30f9c7364ec14840 clang+llvm-3.7.1-rc2-mips-linux-gnu.tar.xz
  9931d48ee11c03867f2ef6c51f5979268f331efb clang+llvm-3.7.1-rc2-x86_64-linux-gnu-debian8.tar.xz
The mipsel build is still building at the moment and I'll upload it once it's finished. The x86_64 build is mainly to allow me to test cross-compilation to MIPS but I think I might as well provide it to others so I'm testing native too.

clang+llvm-3.7.1-rc2-mips-linux-gnu.tar.xz
  2 of 3 complete. The last one should finish today.
  All good so far

clang+llvm-3.7.1-rc2-mipsel-linux-gnu.tar.xz
  Still building Phase 3. Should have results tomorrow.

clang+llvm-3.7.1-rc2-x86_64-linux-gnu-debian8.tar.xz
  Native: All good
  Cross compiling to various MIPS: All good

Windows binaries uploaded with the following sha1s:

2c1292a2a87e7844f41c61ac3540d8ab3438bb6e LLVM-3.7.1-rc2-win32.exe
a4eaf5b97b1d847ea95c3fc9bc4a4f5329c85c63 LLVM-3.7.1-rc2-win64.exe

No regressions.

They were built with the attached batch file.

Cheers,
Hans

build_llvm_371.bat|attachment (2.58 KB)

All looking good, uploaded:

0fc3549f429e4de240c664c3346337fdbf48a32c
clang+llvm-3.7.1-rc2-i586-opensuse13.2.tar.xz
da33a99c68654546a2fbb94b6a04a6799f93360a
clang+llvm-3.7.1-rc2-i686-fedora22.tar.xz
a181ae8e47db241566724978b84ddb9077359dba
clang+llvm-3.7.1-rc2-x86_64-fedora22.tar.xz
cfbaf7e6e0027b6db0d1c96bbd3ab42738e6fe21
clang+llvm-3.7.1-rc2-x86_64-opensuse13.2.tar.xz

The mipsel build is still building at the moment and I'll upload it once it's finished

I've uploaded the mipsel build:
   3648714f878de57d5e364bcab127392daea306dc clang+llvm-3.7.1-rc2-mipsel-linux-gnu.tar.xz
Everything passed for it.

For the sake of completeness, I should mention that the 'make check-all' in test-release.sh triggered a disk error in /tmp which caused it to remount read-only. It then failed the remaining tests because it couldn't create temporary files. After fixing the disk error, a manual re-run of 'make check-all' passed.

clang+llvm-3.7.1-rc2-mips-linux-gnu.tar.xz
        2 of 3 complete. The last one should finish today.
       All good so far

All good.

Uploaded the binaries for Ubuntu 14.04 and 15.10 for x86_64.

15.10 had 154 sanitizer failures and 14.04 had 150 sanitizer failures, but otherwise they seem fine.

Ben

I tried building a release of -rc2 on SuSE Linux Enterprise Server 11SP3. It sounds like some of these failures might be similar to ones encountered on other platforms.

Tom, should I try to open a bug(s) to help investigate these issues? Per http://llvm.org/docs/ReleaseProcess.html#bug-reporting-process I should only do it if these are new from 3.7.0 right?

No, it was not Phase3. I've R'd TFM now and I see that it's a critical
step. Thanks for pointing it out, sorry for confusion.

I tried building a release of -rc2 on SuSE Linux Enterprise Server 11SP3.
It sounds like some of these failures might be similar to ones encountered
on other platforms.

Tom, should I try to open a bug(s) to help investigate these issues? Per
http://llvm.org/docs/ReleaseProcess.html#bug-reporting-process I should
only do it if these are new from 3.7.0 right?

These failing tests also failed on 3.7.0, so no regression. Can I upload
the rc2 tarball? If so, is there a public FTP or a way to get credentials?

Uploaded rc2 tarball, thanks for the help Tom and Anton!

sha1sum:

874f160561badc175926ee6093047b64fe513b44 clang+llvm-3.7.1-rc2-x86_64-sles11.3-linux-gnu.tar.xz

Tom, as discussed previously, I reported the regressions from 3.7:
https://llvm.org/bugs/show_bug.cgi?id=25710
3.7.1 rc2 - CodeGen/address-safety-attr.cpp fails on i386

https://llvm.org/bugs/show_bug.cgi?id=25711
3.7.1 rc2 - CodeGen/asan-globals.cpp fails on i386

https://llvm.org/bugs/show_bug.cgi?id=25712
3.7.1 rc2 - CodeGen/sanitize-init-order.cpp fails on i386

https://llvm.org/bugs/show_bug.cgi?id=25713
3.7.1 rc2 - CodeGen/sanitize-thread-attr.cpp fails on i386

https://llvm.org/bugs/show_bug.cgi?id=25714
3.7.1 rc2 - CodeGen/ubsan-blacklist.c fails on i386

I also reported https://llvm.org/bugs/show_bug.cgi?id=25715
CodeGen/linux-arm-atomic.c fails on i386
but it is not a recent regression (I had this issue in 3.7).

Hope this helps,
Sylvestre

> Hi,
>
> There was one problem in -rc1, so we had to do another release
> candidate. -rc2 has now been tagged and is ready for testing.
>
>
Tom, as discussed previously, I reported the regressions from 3.7:
25710 – 3.7.1 rc2 / 38.0 rc1 - GNU/Linux: CodeGen/address-safety-attr.cpp fails on i386
3.7.1 rc2 - CodeGen/address-safety-attr.cpp fails on i386

I looked into this and the output on my x86_64 build is the same with
3.7.0 and 3.7.1-rc2. I also was not able to reproduce on a system
with an 32-bit OS and 64-bit CPU.

I don't think it is worth holding the release up more for this issue
as it seems unlikely to affect a larger number of users. I'll go
ahead and tag 3.7.1 -final tomorrow unless there are major objections.

-Tom