3.6.2-rc1 has been tagged. Testers needed.

Hi,

I have just tagged 3.6.2-rc1, so testing can begin. We can always use
more testers, so if you are interested in testing, let me know.

-Tom

I checked out the test-release script from 3.6.2 rc1 tag:

/home/development/llvm/3.6.2# ./release_tools/test-release.sh -release 3.6.2 -rc 1 -triple x86_64-linux-gnu -no-64bit# Validating llvm SVN URL
# Validating cfe SVN URL
# Validating dragonegg SVN URL
dragonegg 3.6.2 release candidate rc1 doesn't exist!

Ben

But checked out from trunk, it appears to be progressing.

Ben

> Hi,
>
> I have just tagged 3.6.2-rc1, so testing can begin. We can always use
> more testers, so if you are interested in testing, let me know.

I checked out the test-release script from 3.6.2 rc1 tag:

/home/development/llvm/3.6.2# ./release_tools/test-release.sh -release
3.6.2 -rc 1 -triple x86_64-linux-gnu -no-64bit# Validating llvm SVN URL
# Validating cfe SVN URL
# Validating dragonegg SVN URL
dragonegg 3.6.2 release candidate rc1 doesn't exist!

This should be fixed now. I tagged the release candidates using
tag.sh from trunk, which had dragonegg removed.

-Tom

Looks good: clang+llvm-3.6.2-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz

Ben

So far so good:

clang+llvm-3.6.2-rc1-aarch64-linux-gnu.tar.xz
clang+llvm-3.6.2-rc1-armv7a-linux-gnueabihf.tar.xz

cheers,
--renato

I had trouble building on Windows, getting errors in
AMDGPUGenSubtargetInfo.inc about 'uint64_t' being unrecognized. It
seems after r240285, FeatureWavefrontSize16 etc. changed from being
enumerators to uint64_t values.

If I add "#include "llvm/Support/DataTypes.h"" to
AMDGPUMCTargetDesc.h, it builds. Can I go ahead and commit that to the
branch?

Yes, that's fine.

-Tom

Thanks. Committed in r240577.

I've uploaded a Windows installer based on that version to the sftp
with sha1 f8ead22e954933357edaab312df04ad1ad6fdab2.

Cheers,
Hans

I have just tagged 3.6.2-rc1, so testing can begin. We can always use
more testers, so if you are interested in testing, let me know.

...

Thanks. Committed in r240577.

I've uploaded a Windows installer based on that version to the sftp
with sha1 f8ead22e954933357edaab312df04ad1ad6fdab2.

Built and tested fine on FreeBSD. Binaries uploaded:

SHA256 (clang+llvm-3.6.2-rc1-amd64-unknown-freebsd10.tar.xz) = c4ecb25f1a4042432de9e77bd7bff80243d8f66b11cd4a1365aba52cbde35bc5
SHA256 (clang+llvm-3.6.2-rc1-i386-unknown-freebsd10.tar.xz) = eef5b9aedbb0c54468d6c4f06267ae3bbdf97f49d91273ce16eedde83bb33db5

-Dimitry

No failures on Fedora and Suse, binaries uploaded.

Hi,

I'm not sure how important this will be but I found problems [1] with
the way the test-release script creates packages. Specifically it's
not using DESTDIR for the temporary tarball directory and instead is
using --prefix and it really shouldn't be doing that.

My observation so far has been that the only breakages I've seen are
that the LLVM CMake export files have broken paths in them in the
3.5.0 binary tarballs.

For some reason the LLVM 3.6.x release binary tarballs don't have the
CMake export files in. Any idea what happened there?

I'm going to a bit more testing myself but where are the release
candidate tarballs being uploaded to? I was expecting
http://llvm.org/pre-releases/3.6.2/rc1/ but there's nothing there.

[1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150622/284436.html

Thanks,
Dan.

I think someone needs to move them there, we upload to ftp but I don’t think it’s publicly accessible.

Hi Tom,

I uploaded

clang+llvm-3.6.2-rc1-x86_64-apple-darwin.tar.xz = 7f13063eb18b299fb3928bd9da1daeab

Testing was OK.

Cheers,
Sebastian

clang+llvm-3.6.2-rc1-mips-linux-gnu.tar.xz
    All good

clang+llvm-3.6.2-rc1-mipsel-linux-gnu.tar.xz
    One test-suite run passed. One still running.

clang+llvm-3.6.2-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to various mips)
    All good.

Is there anyway to get access? I want to take a look at the packages.
The CMake files have been "broken in"/"missing from" previous releases
so it would be good to fix it this time.

There are several commits / patches (currently awaiting review) that
it would be good to back port to the branch that fix various issues.

* Make CMake files relocatable [2]
* Fix misuse of --prefix in the test-release.sh script [1]
* Don't export gtest in CMake files r240981

[1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150622/284436.html
[2] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150629/284641.html

I think you need to send your public RSA key to Anton Korobeynikov.

So far, moving the files from uploads to the public website has been
the job of the release manager, as he/she has a wider view of the
issues and can make sure the release is only public when it's intended
to be.

I believe we shouldn't be able to push packages public for that very reason.

cheers,
-renato

clang+llvm-3.6.2-rc1-mipsel-linux-gnu.tar.xz
    The second test run finally finished (the machine lacks an FPU). All good.

Hi Tom,

I'd like to backport some fixes in LLVM trunk to the 3.6 branch. These
changes only effect the generation of CMake files and should not
change the generated binaries. The changes are

r240981
r241080

which need to be applied in order.

Is this okay?

Thanks,
Dan.