[3.8 Release] RC1 has been tagged

Runtimes OpenMP
1

Dear testers,

Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
r258223. (It took a little longer than I'd planned, sorry about that.)

There are still a bunch of open merge requests and bug reports, but I
wanted to get the tag in so we can see what the build and test status
are on the various platforms.

I verified that it currently builds and tests cleanly for me on x86_64
Linux, Mac OS X* and Windows.

Please build, test, and upload binaries to the sftp. Let me know if how it goes.

Thanks,
Hans

[*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`"
CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work,
otherwise stage-2 Clang couldn't find the SDK. I don't remember if I
had to do this last time; maybe some upgrade changed something.

2

(cc'ing non-legacy llvm-dev this time; apologies if you get this
twice. Please don't reply-all to the first one.)

3

What about creating a release management mailing list ?
The testers are usually the same (hello folks!) :slight_smile:

Sylvestre

4

Hi,

Dear testers,

Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
r258223. (It took a little longer than I'd planned, sorry about that.)

There are still a bunch of open merge requests and bug reports, but I
wanted to get the tag in so we can see what the build and test status
are on the various platforms.

I verified that it currently builds and tests cleanly for me on x86_64
Linux, Mac OS X* and Windows.

Doesn't looks good here, stage2 build crashes:

[8/2948] Building CXX object
lib/Support/CMakeFiles/LLVMSupport.dir/BranchProbability.cpp.o
FAILED: /home/abuild/rpmbuild/BUILD/llvm-3.8.0/stage1/bin/clang++
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support -Iinclude
-I../include -fPIC -fvisibility-inlines-hidden -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-std=c++11 -ffunction-sections -fdata-sections -O2 -g -DNDEBUG -fPIC
-fno-exceptions -MMD -MT
lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o -MF
lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o.d -o
lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o -c
../lib/Support/APFloat.cpp
0 clang-3.8 0x0000000001093285
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1 clang-3.8 0x00000000010912d6 llvm::sys::RunSignalHandlers() + 54
2 clang-3.8 0x00000000010914d5
3 libpthread.so.0 0x00007fd59dbdc890
4 clang-3.8 0x0000000000ad0578
5 clang-3.8 0x0000000000da8afa
llvm::FPPassManager::runOnFunction(llvm::Function&) + 634
6 clang-3.8 0x0000000000da8e5b
llvm::FPPassManager::runOnModule(llvm::Module&) + 43
7 clang-3.8 0x0000000000da9150
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 720
8 clang-3.8 0x0000000001199043
clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&,
clang::LangOptions const&, llvm::StringRef, llvm::Module*,
clang::BackendAction, llvm::raw_pwrite_stream*) + 3475
9 clang-3.8 0x0000000001679f7a
10 clang-3.8 0x00000000019457fb
clang::ParseAST(clang::Sema&, bool, bool) + 571
11 clang-3.8 0x0000000001425f0e clang::FrontendAction::Execute() + 286
12 clang-3.8 0x00000000014058c5
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) +
245
13 clang-3.8 0x00000000014a18e1
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1969
14 clang-3.8 0x0000000000826420 cc1_main(llvm::ArrayRef<char
const*>, char const*, void*) + 1920
15 clang-3.8 0x00000000007febdd main + 4589
16 libc.so.6 0x00007fd59cd97b05 __libc_start_main + 245
17 clang-3.8 0x0000000000822c44

Note that initial 3.8 branch from r257891 was fine so it should be due
the latest llvm merges (nothing else changes as far as I can see).
Reporting here too in case someone else sees it.

Regards,
ismail

5

This isn't rc1 but the tip of the release branch had some X86 test failures on my most recent build:
Failing Tests (24):
    libc++ :: std/input.output/file.streams/fstreams/filebuf.virtuals/overflow.pass.cpp
    libc++ :: std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cpp
    libc++ :: std/input.output/iostream.format/ext.manip/get_time.pass.cpp
    libc++ :: std/input.output/iostream.format/ext.manip/put_time.pass.cpp
    libc++ :: std/input.output/iostreams.base/ios.base/ios.base.callback/register_callback.pass.cpp
    libc++ :: std/input.output/iostreams.base/ios.base/ios.base.locales/imbue.pass.cpp
    libc++ :: std/input.output/iostreams.base/ios/basic.ios.members/imbue.pass.cpp
    libc++ :: std/input.output/stream.buffers/streambuf/streambuf.cons/copy.pass.cpp
    libc++ :: std/input.output/stream.buffers/streambuf/streambuf.cons/default.pass.cpp
    libc++ :: std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/assign.pass.cpp
    libc++ :: std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/swap.pass.cpp
    libc++ :: std/localization/locale.categories/category.collate/locale.collate.byname/hash.pass.cpp
    libc++ :: std/localization/locale.categories/category.collate/locale.collate.byname/types.pass.cpp
    libc++ :: std/localization/locale.categories/category.ctype/locale.codecvt.byname/ctor_wchar_t.pass.cpp
    libc++ :: std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
    libc++ :: std/localization/locales/locale/locale.cons/default.pass.cpp
    libc++ :: std/localization/locales/locale/locale.members/name.pass.cpp
    libc++ :: std/localization/locales/locale/locale.operators/eq.pass.cpp
    libc++ :: std/localization/locales/locale/locale.statics/global.pass.cpp
    libc++ :: std/re/re.regex/re.regex.locale/imbue.pass.cpp
    libc++ :: std/re/re.traits/default.pass.cpp
    libc++ :: std/re/re.traits/getloc.pass.cpp
    libc++ :: std/re/re.traits/imbue.pass.cpp
    libomp :: barrier/omp_barrier.c

Big-endian mips gave this during phase 3:
  CMake Error at cmake/modules/HandleLLVMOptions.cmake:43 (message):
    Host Clang must be able to find libstdc++4.7 or newer!
It's possible that this is a machine config issue. We moved offices over the weekend (just across the street) and my normal machine somehow lost the ability to boot in the process. I'm borrowing a replacement at the moment.

Little-endian mips is just about to finish Phase 2 so I'll know if it's a more general problem soon.

6

Unfortunately I'm having lots of trouble with rc1 at this point:
* libcxxabi can't build, because it requires unwind.h, which we do not yet have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not ready for general consumption).
* The test-release.sh script has no option to disable only libcxxabi, you can only disable libcxx, libcxxabi and libunwind together (maybe this can be improved)
* Last time I hand-built libcxx, it still had a lot of test failures in the locale parts, but I haven't had time to investigate.
* OpenMP does not support i386-freebsd, so I have to disable it there
* 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.

I also had to hack the test-release.sh script to fix a number of problems that I encountered during the 3.7.1 release, but haven't gotten to upstreaming them. E.g. the way the source code is checked out with symlinks all over the place does not work, and I need to add a custom patch to clang-tools-extra to make the tests succeed, because there is a race condition in the Makefile.

-Dimitry

7

Some issues:

LNT didn't finish: perhaps my checkout is incomplete, this bit seems to have changed with the switch to cmake. Some unexpected failures on Ubuntu 14.04, but 15.10 was great.

LNT:
nt.py:499: fatal error: unable to import test module: '3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule'
Traceback (most recent call last):
   File "/home/ben/development/llvm/lnt/lnt/tests/nt.py", line 495, in execute_test_modules
     exec module_file in locals, globals
   File "3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule", line 4, in <module>
     import spec
ImportError: No module named spec

Ubuntu 14.04 x86_64:
Failing Tests (14):
     AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
     MemorySanitizer :: Linux/forkpty.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
     Profile :: instrprof-error.c
     libc++ :: std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
     libc++ :: std/localization/locales/locale/locale.cons/char_pointer.pass.cpp

   Expected Passes : 31165
   Expected Failures : 195
   Unsupported Tests : 527
   Unexpected Failures: 14

Ubuntu 15.10 x86_64:
   Expected Passes : 31838
   Expected Failures : 209
   Unsupported Tests : 649

Uploaded:
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-15.10.tar.xz

Ben

8

That would certainly make my emails easier to address :slight_smile: On the other
hand, I do think there's a point to asking for testers each time and
then only addressing those that sign up explicitly. What do the rest
of you think about having a list?

9

:frowning:

Can you file a bug with the preprocessed source and invocation attached?

10

Unfortunately I'm having lots of trouble with rc1 at this point:
* libcxxabi can't build, because it requires unwind.h, which we do not yet have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not ready for general consumption).
* The test-release.sh script has no option to disable only libcxxabi, you can only disable libcxx, libcxxabi and libunwind together (maybe this can be improved)

Yes, I'd be happy to take a patch for this, or I suppose you could
just hack it out locally when building.

* Last time I hand-built libcxx, it still had a lot of test failures in the locale parts, but I haven't had time to investigate.

Did we have that for 3.7 too?

* OpenMP does not support i386-freebsd, so I have to disable it there

That's perfectly fine. Including OpenMP by default is new for this
release, so if it causes any problems, just exclude it.

* 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?

I also had to hack the test-release.sh script to fix a number of problems that I encountered during the 3.7.1 release, but haven't gotten to upstreaming them. E.g. the way the source code is checked out with symlinks all over the place does not work, and I need to add a custom patch to clang-tools-extra to make the tests succeed, because there is a race condition in the Makefile.

:frowning: What's not working with the symlinks? Please send patches. I'm
sorry for the trouble here.

Thanks,
Hans

11

Dear testers,

Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
r258223. (It took a little longer than I'd planned, sorry about that.)

Some issues:

LNT didn't finish: perhaps my checkout is incomplete, this bit seems to have
changed with the switch to cmake. Some unexpected failures on Ubuntu 14.04,
but 15.10 was great.

How did you build LNT? I think previously it used to get configured
automatically, but not built. Recently someone added a cmake file to
it, which didn't work, so I excluded it from the test-release build in
r257791

LNT:
nt.py:499: fatal error: unable to import test module:
'3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule'
Traceback (most recent call last):
  File "/home/ben/development/llvm/lnt/lnt/tests/nt.py", line 495, in
execute_test_modules
    exec module_file in locals, globals
  File
"3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule",
line 4, in <module>
    import spec
ImportError: No module named spec

Ubuntu 14.04 x86_64:
Failing Tests (14):
    AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
    MemorySanitizer :: Linux/forkpty.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
    Profile :: instrprof-error.c
    libc++ ::
std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
    libc++ ::
std/localization/locales/locale/locale.cons/char_pointer.pass.cpp

Weird. These all passed for me on 14.04.

Uploaded:
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-15.10.tar.xz

Thanks!

12

Unfortunately I'm having lots of trouble with rc1 at this point:
* libcxxabi can't build, because it requires unwind.h, which we do not yet have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not ready for general consumption).
* The test-release.sh script has no option to disable only libcxxabi, you can only disable libcxx, libcxxabi and libunwind together (maybe this can be improved)

Yes, I'd be happy to take a patch for this, or I suppose you could
just hack it out locally when building.

It's not terribly important right now, as libcxx isn't succeeding its tests anyway. I can locally hack it in, but I hope I won't forget it later. :slight_smile:

* Last time I hand-built libcxx, it still had a lot of test failures in the locale parts, but I haven't had time to investigate.

Did we have that for 3.7 too?

With 3.7, we used autoconf builds for FreeBSD, and that skipped libcxx altogether. I did a few builds by hand, and I remember I saw similar failures. This is just something that nobody (from FreeBSD) has seriously looked at, and I never had the time for it. There are only so much hours in a day...

For example, recently with trunk r256945, I saw these:

Failing Tests (39):
    libc++ :: std/depr/depr.c.headers/stddef_h.pass.cpp
    libc++ :: std/depr/depr.c.headers/wchar_h.pass.cpp
    libc++ :: std/language.support/support.types/max_align_t.pass.cpp
    libc++ :: std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp
    libc++ :: std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp
    libc++ :: std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_1.pass.cpp
    libc++ :: std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_many.pass.cpp
    libc++ :: std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_1.pass.cpp
    libc++ :: std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_many.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_zh_CN.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_zh_CN.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/curr_symbol.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/grouping.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/pos_format.pass.cpp
    libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
    libc++ :: std/localization/locale.categories/category.time/locale.time.get.byname/get_date.pass.cpp
    libc++ :: std/localization/locale.categories/category.time/locale.time.get.byname/get_date_wide.pass.cpp
    libc++ :: std/localization/locale.categories/category.time/locale.time.get.byname/get_one.pass.cpp
    libc++ :: std/localization/locale.categories/category.time/locale.time.get.byname/get_one_wide.pass.cpp
    libc++ :: std/localization/locale.categories/category.time/locale.time.put.byname/put1.pass.cpp
    libc++ :: std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/grouping.pass.cpp
    libc++ :: std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp
    libc++ :: std/re/re.alg/re.alg.match/basic.pass.cpp
    libc++ :: std/re/re.alg/re.alg.match/ecma.pass.cpp
    libc++ :: std/re/re.alg/re.alg.match/extended.pass.cpp
    libc++ :: std/re/re.alg/re.alg.search/awk.pass.cpp
    libc++ :: std/re/re.alg/re.alg.search/basic.pass.cpp
    libc++ :: std/re/re.alg/re.alg.search/ecma.pass.cpp
    libc++ :: std/re/re.alg/re.alg.search/extended.pass.cpp
    libc++ :: std/re/re.traits/lookup_collatename.pass.cpp
    libc++ :: std/re/re.traits/transform_primary.pass.cpp
    libc++ :: std/re/re.traits/translate_nocase.pass.cpp
    libc++ :: std/strings/string.conversions/stof.pass.cpp
    libc++ :: std/utilities/meta/meta.trans/meta.trans.other/aligned_storage.pass.cpp

Individual failures were typically of the form:

FAIL: libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp (27654 of 30312)
******************** TEST 'libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp' FAILED ********************
Compiled With: ['/usr/bin/clang++', '-o', '/home/dim/obj/llvm-256945-trunk-freebsd11-i386-ninja-rel-1/projects/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/Output/thousands_sep.pass.cpp.o', '-x', 'c++', '/share/dim/
src/llvm/trunk/projects/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp', '-c', '-v', '-std=c++1z', '-nostdinc++', '-I/share/dim/src/llvm/trunk/projects/libcxx/test/support', '-include', '/share/
dim/src/llvm/trunk/projects/libcxx/test/support/nasty_macros.hpp', '-I/share/dim/src/llvm/trunk/projects/libcxx/include', '&&', '/usr/bin/clang++', '-o', '/home/dim/obj/llvm-256945-trunk-freebsd11-i386-ninja-rel-1/projects/libcxx/test/std/localization/locale.c
ategories/category.monetary/locale.moneypunct.byname/Output/thousands_sep.pass.cpp.exe', '/home/dim/obj/llvm-256945-trunk-freebsd11-i386-ninja-rel-1/projects/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/Output/thous
ands_sep.pass.cpp.o', '-v', '-nodefaultlibs', '-L/home/dim/obj/llvm-256945-trunk-freebsd11-i386-ninja-rel-1/lib', '-Wl,-rpath,/home/dim/obj/llvm-256945-trunk-freebsd11-i386-ninja-rel-1/lib', '-lc++', '-lc', '-lm', '-lpthread', '-lgcc_s', '-lcxxrt']
Command: ['/home/dim/obj/llvm-256945-trunk-freebsd11-i386-ninja-rel-1/projects/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/Output/thousands_sep.pass.cpp.exe']
Exit Code: -6
Standard Error:

13

As to the symlinks, the test-release.sh script originally checks out the sources in parallel directories, e.g.:

llvm.src
cfe.src
compiler-rt.src

and so on. Within llvm.src, symlinks are made to point to each of these. For some reason, on FreeBSD, this causes .cpp files under llvm.src/tools/clang/tools/extra to not be able to find their include files, and my log files show the following kind of errors:

/home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10: fatal error: 'clang/Tooling/Refactoring.h' file not found
#include "clang/Tooling/Refactoring.h"
         ^
1 error generated.

I remember trying lots of things to make this work, but failing. Apparently there is some issue with following a double symlink path, e.g. llvm.src/tools/clang is a symlink to ../../cfe.src, while llvm.src/tools/clang/tools/extra (which really is under ../../cfe.src/tools) is a symlink to ../../clang-tools-extra.src.

Oh, I thought it was a CMake vs. autoconf thing, and we were just
symlinking clang-tools-extra wrong (see r257905). I guess I jumped to
wrong conclusions there :-/

The way I fixed this during the 3.7 test phase, is by changing test-release.sh so it exports directly into these locations:

# Exporting llvm 3.7.0-rc3 sources to llvm.src
# Exporting cfe 3.7.0-rc3 sources to llvm.src/tools/clang
# Exporting clang-tools-extra 3.7.0-rc3 sources to llvm.src/tools/clang/tools/extra
# Exporting compiler-rt 3.7.0-rc3 sources to llvm.src/projects/compiler-rt
# Exporting libcxx 3.7.0-rc3 sources to llvm.src/projects/libcxx
# Exporting libcxxabi 3.7.0-rc3 sources to llvm.src/projects/libcxxabi
# Exporting libunwind 3.7.0-rc3 sources to llvm.src/projects/libunwind
# Exporting test-suite 3.7.0-rc3 sources to llvm.src/projects/test-suite

This is probably not so handy if you want to create tarballs of the individual components, though.

Actually, I use export.sh for creating the tarballs, so that's not a
problem. Maybe just exporting into the right directories is the way to
go.

14

Dear testers,

Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
r258223. (It took a little longer than I'd planned, sorry about that.)

Some issues:

LNT didn't finish: perhaps my checkout is incomplete, this bit seems to have
changed with the switch to cmake. Some unexpected failures on Ubuntu 14.04,
but 15.10 was great.

How did you build LNT? I think previously it used to get configured
automatically, but not built. Recently someone added a cmake file to
it, which didn't work, so I excluded it from the test-release build in
r257791

I only checked out the test-suite and ran LNT as I normally do. Do I need to "build" the test suite?

I'll have another look at the docs on the weekend, as I haven't looked at them for a while.

LNT:
nt.py:499: fatal error: unable to import test module:
'3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule'
Traceback (most recent call last):
   File "/home/ben/development/llvm/lnt/lnt/tests/nt.py", line 495, in
execute_test_modules
     exec module_file in locals, globals
   File
"3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule",
line 4, in <module>
     import spec
ImportError: No module named spec

Ubuntu 14.04 x86_64:
Failing Tests (14):
     AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
     MemorySanitizer :: Linux/forkpty.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
     Profile :: instrprof-error.c
     libc++ ::
std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
     libc++ ::
std/localization/locales/locale/locale.cons/char_pointer.pass.cpp

Weird. These all passed for me on 14.04.

It was built in a chroot environment, but I don't see how that would affect things.

Uploaded:
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-15.10.tar.xz

Thanks!

Ben

15

I still haven't built rc1 yet but I've found the cause of most (if not all) of the libc++ failures. This system does not have the en_US.UTF-8 locale.

I'm currently putting a patch together to add appropriate REQUIRES lines to tests that require en_US.UTF-8. Once I've done that and committed it, I'm going to enable this locale along with the others that lit is complaining about (fr_FR.UTF-8, ru_RU.UTF-8, zh_CN.UTF-*, fr_CA.ISO8859-1, and cs_CZ.ISO8859-2).

16

ARM and AArch64 seem both good. Uploaded.

17

I second that! It'd also be much easier on mail filters... :slight_smile:

--renato

18

OK, that sounds good. I was worried it was getting pulled in and
failing through the CMake build in test-release.sh.

19

Tanya, can you help us set up an llvm-release-testers mailing list?

Thanks,
Hans

20

...

The way I fixed this during the 3.7 test phase, is by changing test-release.sh so it exports directly into these locations:

# Exporting llvm 3.7.0-rc3 sources to llvm.src
# Exporting cfe 3.7.0-rc3 sources to llvm.src/tools/clang
# Exporting clang-tools-extra 3.7.0-rc3 sources to llvm.src/tools/clang/tools/extra
# Exporting compiler-rt 3.7.0-rc3 sources to llvm.src/projects/compiler-rt
# Exporting libcxx 3.7.0-rc3 sources to llvm.src/projects/libcxx
# Exporting libcxxabi 3.7.0-rc3 sources to llvm.src/projects/libcxxabi
# Exporting libunwind 3.7.0-rc3 sources to llvm.src/projects/libunwind
# Exporting test-suite 3.7.0-rc3 sources to llvm.src/projects/test-suite

This is probably not so handy if you want to create tarballs of the individual components, though.

Actually, I use export.sh for creating the tarballs, so that's not a
problem. Maybe just exporting into the right directories is the way to
go.

I have created ⚙ D16420 Let test-release.sh checkout subprojects directly into the target tree, instead of using symlinks for this change. Please review.

-Dimitry