Dear testers,
3.7.0-rc1 was just tagged; please start your testing engines 
Upload binaries to the sftp and report your results to this thread.
I'm sorry for the delay between branching and tagging. The changes to
the release script took a little longer than I hoped.
Thanks for helping with the release, and do let me know of any issues,
questions, etc.
The tracking bug for release blockers is PR24126.
Cheers,
Hans
Is it OK to do an autoconf build? The CMake build tries to build various components which do not yet work on FreeBSD, e.g. libcxxabi does not compile at all, libcompiler-rt has a bunch of test failures, etc. Alternatively, can I disable these components in the CMake build locally?
-Dimitry
Hans,
Do we intend to leave -fopenmp defaulted to the no-op libgomp
support for 3.7.0 or do the sensible thing by applying...
Index: CMakeLists.txt
Yes, go ahead and use the autoconf build.
Can you send a patch to test-release.sh that makes this default for
FreeBSD? It's already the default for Darwin.
Thanks,
Hans
Hi Jack,
Hans,
Do we intend to leave -fopenmp defaulted to the no-op libgomp
support for 3.7.0 or do the sensible thing by applying...Index: CMakeLists.txt
--- CMakeLists.txt (revision 242425)
+++ CMakeLists.txt (working copy)
@@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di
set(DEFAULT_SYSROOT "" CACHE PATH
"Default <path> to all compiler invocations for --sysroot=<path>." )-set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
+set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
"Default OpenMP runtime used by -fopenmp.")set(CLANG_VENDOR "" CACHE STRING
so that the new llvm openmp library (which passes a three stage
bootstrap as part of an
in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on
x86_64-apple-darwin).
I'm not fully aware of the implications of this, but if we do want to
change it, it needs to be done on trunk first.
If you get it through review and committed to trunk, I'm open to merging it.
I assume utils/release/test-release.sh would also need an update so
the library gets built?
Thanks,
Hans
CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): Cannot compile for i686
CMakeError.log attached, seems like #include checks are failing? This is x86 openSUSE.
CMakeError.log.zip (6.35 KB)
Hi Hans,
We're missing libunwind from the list of projects in 3.7.
The current way libcxxabi builds depends on libunwin (looking for
libunwind.h), so we need to tag libunwind, check it out in the script
and build it together.
For now, I'll disable libcxx from my build, but it would be good to
have it on later, so we can test it with the rest, too.
cheers,
--renato
Hans,
This change is required because Chandler reverted the OpenMP
developers original commit that enabled clang to default to the new
OpenMP with...
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150518/129487.html
The major complaints with the cmake support for OpenMP have been addressed in...
http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000441.html
http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000442.html
as well as in prior commits which addressed the cmake variable naming
convention issues.
Otherwise, the release notes for 3.7.0 will have to
explain why we don't trust our own fully functional OpenMP 3.1 support
to the point that we choose to default to non-functional libgomp
support. Note that the -fopenmp currently implies -fopenmp=libgomp
which doesn't generate any code for OpenMP support is thus simple
serial execution.
Jack
Hi Renato,
We're missing libunwind from the list of projects in 3.7.
The current way libcxxabi builds depends on libunwin (looking for
libunwind.h), so we need to tag libunwind, check it out in the script
and build it together.For now, I'll disable libcxx from my build, but it would be good to
have it on later, so we can test it with the rest, too.
I've created the branch and rc1 tag for libunwind, and included it in
the scripts in r242543. Let me know how it works out.
Thanks,
Hans
Hi Jack,
Hans,
This change is required because Chandler reverted the OpenMP
developers original commit that enabled clang to default to the new
OpenMP with...http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150518/129487.html
The major complaints with the cmake support for OpenMP have been addressed in...
http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000441.html
http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000442.htmlas well as in prior commits which addressed the cmake variable naming
convention issues.
Thank you for the links.
It's not me you need to convince though. As I said before, the change
would have to be committed to trunk first, and then I'm open to
consider merging it.
Thanks,
Hans
Seems on OpenSUSE x86, it's called i586, not i686 
+Alexey: do you think we can handle this in the compiler-rt cmake
files somehow? Maybe try targeting both i686 and i586 unless that
would break something else?
Thanks! It solved the CMake issue, but now it doesn't build. Since I
had problems building libcxx on ARM directly before, I won't release
them now. Just Clang+tools and Compiler RT.
Still, removing the libraries from the list of projects (and
commenting out the hardcoded symlinks), I can build all the way to
Phase3, but some of the ASAN tests fail (not sure why) and the tar
ball isn't created.
I'll investigate the ASAN issues, but it would be good to create the
binary package anyway, so at least I can upload it to the website and
other people test their stuff while I figure out the problems in the
tests.
Finally, for some reason, the install directory is
...install/usr/local/... which is odd.
I'll send a patch with some changes to the test-release.sh script.
cheers,
--renato
I've created the branch and rc1 tag for libunwind, and included it in
the scripts in r242543. Let me know how it works out.Thanks! It solved the CMake issue, but now it doesn't build. Since I
had problems building libcxx on ARM directly before, I won't release
them now. Just Clang+tools and Compiler RT.
Sounds good to me.
Still, removing the libraries from the list of projects (and
commenting out the hardcoded symlinks), I can build all the way to
Phase3, but some of the ASAN tests fail (not sure why) and the tar
ball isn't created.I'll investigate the ASAN issues, but it would be good to create the
binary package anyway, so at least I can upload it to the website and
other people test their stuff while I figure out the problems in the
tests.
I thought we ran the tests with "make -k", so I'd expect the tarball
to be created anyway. Hmm...
Finally, for some reason, the install directory is
...install/usr/local/... which is odd.
Oops, that's from r242187. I think the install directory is fine, but
it shouldn't become part of the tarball.
I'll send a patch with some changes to the test-release.sh script.
Thanks! Are you including a fix for not including "/usr/local" in the
tarball? Otherwise I'll do that.
Cheers,
Hans
I was going to send two patches, but feel free to get that one out of
the way, since you know where to fix it.
cheers,
--renato
ARMv7 with Compiler-RT up. There were unexpected passes on the
sanitizer, but that's ok.
I'm running tests and benchmarks now, but people can already try it
out if they want.
AArch64 will come early next week.
cheers,
--renato
Here it is. While here, I replaced the multiple calls to uname -s with a variable assignment.
It's currently building for FreeBSD 10.x i386 and amd64.
-Dimitry
use-autoconf-on-freebsd-too-1.diff (1.25 KB)
Hm, strangely enough, this version of the script does not go further than the Phase 2 installation, and does not run any tests? This used to work fine for the release_36 branch.
I think it is because of the "set -o pipefail" which was introduced, but I don't yet understand why this causes the Phase 2 installation to appear to fail, as there is no visible error. I will investigate, or work around it by removing the pipefail option again.
-Dimitry
Hi Hans,
Test Result Report: Ubuntu 15.04 AMD64 3.7.0-RC1 release . Everything works fine without any problem.
SFTP Upload: Not done yet. Since do not have the SFTP access information.
Kun Ling
On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and no tarball:
Failing Tests (18):
AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
MemorySanitizer :: Linux/tcgetattr.cc
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent
MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r
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.gethostent
MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r
MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
SanitizerCommon-asan :: Linux/getpass.cc
SanitizerCommon-asan :: Posix/decorate_proc_maps.cc
SanitizerCommon-lsan :: Linux/getpass.cc
SanitizerCommon-msan :: Linux/getpass.cc
SanitizerCommon-msan :: Linux/signal_segv_handler.cc
SanitizerCommon-msan :: Posix/decorate_proc_maps.cc
SanitizerCommon-tsan :: Linux/getpass.cc
SanitizerCommon-tsan :: Posix/decorate_proc_maps.cc
Expected Passes : 24006
Expected Failures : 131
Unsupported Tests : 377
Unexpected Failures: 18
Ben
On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and no
tarball:
The tarball is an issue Hans is aware of. We're fixing it.
Failing Tests (18):
AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
Did you use to build compiler-rt on the previous (autoconf) releases?
If not, this might explain why you're only seeing these errors now.
cheers,
--renato