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
How To Validate a New Release — LLVM 18.0.0git documentation 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:
https://llvm.org/bugs/show_bug.cgi?id=25710
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