[3.7 Release] RC3 has been tagged, let's wrap this up

Runtimes OpenMP
1

Hello everyone,

3.7-rc3 has just been tagged. Testers, please test, build binaries,
upload to the sftp and report results to this thread.

Again, a lot of patches got merged between rc2 and rc3, but hopefully
nothing that should upset things.

One thing that did change is that the release script now correctly
symlinks clang-tools-extra into the build. If this causes problems on
your platform, please just remove it.

This is a release candidate in the real sense: at this point I have
zero release blockers on my radar. I will now only accept fixes for
critical regressions, and if nothing comes up, rc3 will be promoted to
3.7.0-final.

Documentation and release note patches are still welcome all the way
up until the final tag goes in.

Issues that were on my radar, but I don't consider blocking:

- Sanitizer test failures on various platforms, e.g. PR24222. We never
ran these tests in previous releases, so it's not a regression. It
would be great if the sanitizer folks could look into the test
failures, but it's not blocking 3.7.

- PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in
__cxa_allocate_exception", Renato will exclude libc++ from his build
for now.

- Lack of key functions in some Instruction classes causing build
failures without -fno-rtti
(http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No
patches have been forthcoming, so this will not get fixed for 3.7. At
least we correctly report -fno-rtti in llvm-config built with CMake
now.

- r244221: "[SPARC] Don't compare arch name as a string, use the enum
instead", owner is unresponsive.

- "[lldb] r245020 - [MIPS]Handle floating point and aggregate return
types in SysV-mips [32 bit] ABI", owner is unresponsive.

Cheers,
Hans

2

lnt looks fine, uploaded:
clang+llvm-3.7.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz

test-release output:

Testing Time: 158.19s

3

Hm, it does not seem to compile at all here? The build ends with:

In file included from /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:17:
/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.

Any idea? I had no problems at all with -rc2.

-Dimitry

4

Hi Dmitry, if I understood Hans clang-extra wasn’t part of the build prior to rc3. Just delete it and run script with --no-checkout.

5

Strangely, the clang-tools-extra stuff does build if I manually check it out like so (without any symlinks):

. <-- https://llvm.org/svn/llvm-project/llvm/branches/release_37
tools/clang <-- https://llvm.org/svn/llvm-project/cfe/branches/release_37
tools/clang/tools/extra <-- https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37

I'll investigate, because it would be nice to have those tools.

-Dimitry

6

Windows binaries uploaded. sha1 sums:

1f0ad138830146aa3ea93561772b82e0b93c855d LLVM-3.7.0-rc3-win32.exe
afb014481a46a6d354bb3c2fc2cac9c18b7a6776 LLVM-3.7.0-rc3-win64.exe

Attaching the batch file I used for building.

Thanks,
Hans

build_llvm_370.bat|attachment (2.53 KB)

7

AArch64 up. All green.

8

Fedora and openSUSE uploaded.

9

ARM up. All green.

10

The problem seems to be caused by the way the symlinks are setup in test-release.sh, e.g. like so:

llvm.src/tools/clang -> ../../cfe.src
cfe.src/tools/extra -> ../../clang-tools-extra.src

When it then tries to access the path llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include, it fails. I tried this on both FreeBSD, OSX and Linux, but it fails everywhere.

For example, on Linux:

$ ls -l ~/foo/llvm.src/tools/clang
lrwxrwxrwx 1 dim dim 13 2015-08-22 18:40:16 /home/dim/foo/llvm.src/tools/clang -> ../../cfe.src/
$ ls -l ~/foo/cfe.src/tools/extra
lrwxrwxrwx 1 dim dim 27 2015-08-22 18:53:04 /home/dim/foo/cfe.src/tools/extra -> ../../clang-tools-extra.src/
$ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling
total 16
-rw-r--r-- 1 dim dim 8983 2015-08-22 18:17:18 ApplyReplacements.cpp
-rw-r--r-- 1 dim dim 526 2015-08-22 18:17:18 Makefile
$ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include
ls: cannot access /home/dim/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include: No such file or directory

Note that llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. goes back to the top level, where *.src is checked out:

$ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../..
total 12
drwxr-xr-x 16 dim dim 4096 2015-08-22 18:17:16 cfe.src/
drwxr-xr-x 14 dim dim 4096 2015-08-22 18:40:32 clang-tools-extra.src/
drwxr-xr-x 16 dim dim 4096 2015-08-22 18:13:58 llvm.src/

Of course at a level even below that, there is little chance of an include directory existing. How does anybody else manage to build using the test-release.sh script, and having clang-tools-extra?

-Dimitry

11

It's building with this patch now, already at Phase3, so it seems to work:

Index: trunk/utils/release/test-release.sh

12

Uploaded in Debian.
Works fine on the major archs
However, lldb fails to build on some archs. I reported bug:
https://llvm.org/bugs/show_bug.cgi?id=24548

Cheers,
Sylvestre

13

Still no complete go, doing the tests on i386 failed with some weird sed error:

[...]
Making Unit/lit.site.cfg for Clang extra tools...
sed: lit.tmp: No such file or directory
Makefile:61: recipe for target 'Unit/lit.site.cfg' failed
gmake[2]: *** [Unit/lit.site.cfg] Error 1

Strangely enough, this does not happen on amd64. Maybe it is some sort of race condition? Did anybody see this too?

Back to the investigation again... :frowning:

-Dimitry

14

Right, I found out the problem. It's because clang-tools-extra's test Makefile uses the temporary filename "lit.tmp" for both its main lit.site.cfg, and for Unit/lit.site.cfg. If these make jobs get run simultaneously, one or the other temp file can unexpectedly disappear.

The following fixes it, similar to what is done in clang's own test Makefile. Hans, are you OK with me checking this in to clang-tools-extra trunk (not sure who owns that), then merging it to the release_37 branch? Then it is at least fixed for the final build.

Index: tools/clang/tools/extra/test/Makefile

15

Finally, all building and testing succeeded, even with clang-tools-extra now (the tarballs became ~15% bigger). :slight_smile:

Uploaded:

SHA256 (clang+llvm-3.7.0-rc3-i386-unknown-freebsd10.tar.xz) = 319a7d6758bad7976dab2774309504432a69705c5662b38e05062018b71f655f
SHA256 (clang+llvm-3.7.0-rc3-amd64-unknown-freebsd10.tar.xz) = 91997accc86379f7b2334ca9444a1fe017210871774153b87f4b1723125807fc

-Dimitry

16

It seems this is a cmake vs autoconf thing. With cmake, it builds
correctly, but with autoconf I get the same error as you.

I probably shouldn't have made this change while we were in the
release process as it was potentially risky :-/ I've reverted it now,
so hopefully the next build should be problem free.

Thanks,
Hans

17

clang+llvm-3.7.0-rc3-mips-linux-gnu.tar.xz
  All ok.
  
clang+llvm-3.7.0-rc3-mipsel-linux-gnu.tar.xz
  All ok.

clang+llvm-3.7.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling for Mips)
  Still running the last few test-suite runs but no unexpected problems so far.
  I say 'unexpected' because I updated to a new GCC cross-compilation toolchain which no longer contains certain multilibs. The three runs that depend on these removed multilibs (mips32r1 and mips64r1 n32/n64) failed as expected.

18

Hans,

Note that the patches I posted solved the problems, at least for me. :slight_smile:

-Dimitry

19

Thanks, we should probably do something like that after this release,
but for now I think it's best to revert to safety.