[3.6 Release] RC4 has been tagged

Hello testers,

RC4 has just been tagged (at r229782 on the branch).

RC3 was disqualified due to an infloop that Duncan reported, and fixed
in r229421. That, fixes for a few scary X86 bugs, a GCC5 bootstrap
problem (PR22625), and parts of PR22589 is included in RC4.

Baring any showstoppers, this release candidate will be promoted to release.

Please let me know how it looks and upload binaries as usual.

Thanks,
Hans

Ok, this issue might not have been solved... The test:

test/CodeGen/R600/Output/infinite-loop-evergreen.ll

Is actually in an infinite loop on AArch64... This is RC4 Phase3. I
didn't see that on RC3.

I'll kill the test and proceed with the test-suite, but I'm not sure
we found all problems.

cheers,
--renato

Well, I spoke too early. Apparently the test finished after 8 minutes
running... Is that expected?

8 minutes is longer than it takes to run the whole check-all on that box...

cheers,
--renato

AArch64 binaries uploaded. Apart from the long-lasting infinite-loop
test, everything else was fine.

ARM binaries still building.

cheers,
--renato

No problems encountered on FreeBSD 10. I have uploaded these files to SFTP:

SHA256 (clang+llvm-3.6.0-rc4-i386-unknown-freebsd10.tar.xz) = e38ff54a9fb9fbe20751c08783821bcc3416eb1961a799e1099857c456d9f396
SHA256 (clang+llvm-3.6.0-rc4-amd64-unknown-freebsd10.tar.xz) = 161e187eeb790a52fb07b508485c89f214dbcd03794e0cdff522cae97610e889

-Dimitry

+Matt who wrote that test.

test/CodeGen/R600/Output/infinite-loop-evergreen.ll

Is actually in an infinite loop on AArch64... This is RC4 Phase3. I
didn't see that on RC3.

...

Well, I spoke too early. Apparently the test finished after 8 minutes
running... Is that expected?

There weren't any R600 patches merged between rc3 and rc4.. I think
the test is just broken and you got unlucky with this build.

If I remove the XFAIL, the test fails for me by hitting an unreachable
in AMDILCFGStructurizer.cpp. The behaviour feels a little arbitrary.
Who knows what would happen in a non-asserts bug, and what the test
expectation really is.

I'm not going to worry about this one for the release.

Cheers,
Hans

Windows binary uploaded to the sftp:

$ sha1sum LLVM-3.6.0-rc4-win32.exe
4ae208f78c403c00cccdd9a65020df4ac277f189 LLVM-3.6.0-rc4-win32.exe

It was built with the attached script.

- Hans

build_llvm_360.bat|attachment (2.32 KB)

There weren't any R600 patches merged between rc3 and rc4.. I think
the test is just broken and you got unlucky with this build.

Yeah, I think I just didn't see it in time.

I'm not going to worry about this one for the release.

Ok.

cheers,
--renato

ARM binaries up. All green.

--renato

+Matt who wrote that test.

test/CodeGen/R600/Output/infinite-loop-evergreen.ll

Is actually in an infinite loop on AArch64... This is RC4 Phase3. I
didn't see that on RC3.

...

Well, I spoke too early. Apparently the test finished after 8 minutes
running... Is that expected?

There weren't any R600 patches merged between rc3 and rc4.. I think
the test is just broken and you got unlucky with this build.

If I remove the XFAIL, the test fails for me by hitting an unreachable
in AMDILCFGStructurizer.cpp. The behaviour feels a little arbitrary.
Who knows what would happen in a non-asserts bug, and what the test
expectation really is.

The point is basically to record this is broken so somebody notices in the future if this gets fixed. What the test does doesn’t really matter. It crashes immediately for me with the unreachable.

Everything looks fine on x86_64 ubuntu-14.04

Uploaded: clang+llvm-3.6.0-rc4-x86_64-linux-gnu-ubuntu-14.04.tar.xz

Ben

Fedora and openSUSE look good, upload in progress…

Mips binaries uploaded.

clang+llvm-3.6.0-rc4-mips-linux-gnu.tar.xz
  All good

clang+llvm-3.6.0-rc4-mipsel-linux-gnu.tar.xz
  Still running due to a silly setup mistake on the first run (a broken symlink to the test-suite source). Second attempt is a fair way through and looks good so far though

clang+llvm-3.6.0-rc4-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to Mips)
  Everything was fine until my disk filled up after 14 of the 23 configs I run. I'll rerun those that didn't run first time.

Renato and Daniel, how are you guys testing, are you using real hardware or emulation? I’m just curious about your setup.

Hi Nikola,

I use real hardware. I'm relying on the check-all from Phase3 and
running the whole test-suite cleanly. On RC1 of every release, I run
some benchmarks to track performance regressions, and make sure we can
still run the same benchmarks on ARM/AArch64, since we don't have
buildbots for them.

cheers,
--renato

Hi everyone,

I'm a bit late but nevertheless: uploaded RC4 for OS X to SFTP with
lights on green

MD5 (clang+llvm-3.6.0-rc4-x86_64-apple-darwin.tar.xz) =
7a1d49b04f889d70b07ff8e4fc42a2f3

Cheers,
Sebastian

The Mips binary releases are built and tested on Mips hardware Debian Jessie (mips/mipsel) systems. The little-endian system lacks a local hard disk and an FPU so it takes a very long time. The big-endian system still lacks an FPU but it has an SSD and 10 cores so it’s pretty quick. Each of these are tested for –mips32, -mips32r2, and default-options. I don’t look at the performance of the test-suite yet since the lack of FPU’s means that a lot of the tests are really testing the performance of the kernel instruction emulation (2% user 98% sys is pretty common). However, I discovered a few days ago that the ‘MIPS Creator CI20’ is pretty good at the test-suite (it has an FPU and finishes in ~2 hours) so I’m hoping to have this in place for future releases.

I’m not doing 64-bit builds yet because of a couple issues recursing the compiler with the release script but it’s hopefully on its way.

The cross compilation testing builds the test-suite several times (currently 23) for various ISA’s, endians, ABI’s, etc. and executes the tests under qemu. This lets me cover things I don’t have the silicon for at the moment (e.g. Mips32r6, MSA, etc.) but it also prevents meaningful performance testing. I’m hoping to get hardware involved in this where possible but I haven’t had time to look into it.

I've added them to the pre-release webpage.

Cheers,
Hans

Quick update before I move on to the final tag.

clang+llvm-3.6.0-rc4-mipsel-linux-gnu.tar.xz
  Still running due to a silly setup mistake on the first run (a broken
symlink to the test-suite source). Second attempt is a fair way through and
looks good so far though

Default options were all good. Mips32 was about halfway but was good so far.

clang+llvm-3.6.0-rc4-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling
to Mips)
  Everything was fine until my disk filled up after 14 of the 23 configs I
run. I'll rerun those that didn't run first time.

All ok here.

Are we waiting for an RC5? It seems like the release mirror on github has no recent activity.