Hi,
I have tagged the 3.6.1-rc1 so testing can begin. We can always use
more testers, so if you are interested in helping, let me know.
Instructions for validating an LLVM release can be found here:
http://llvm.org/docs/ReleaseProcess.html
Reminder: We are using 3.6.0 as our baseline for regression testing.
Thanks,
Tom
ARM binary passes all tests / test-suite. Uploaded.
AArch64 to come next.
cheers,
--renato
Ubuntu 14.04 x86_64 looks good, uploaded
clang+llvm-3.6.1-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
Ben
AArch64 looks ok, though my environment was a bit unstable and I had
to add a few include paths here and there.
The binary was uploaded into the server, in case someone wants to have
a look, but I'll have to fix my environment for the final release.
cheers,
--renato
Building and testing passed on FreeBSD 10. Uploaded:
SHA256 (clang+llvm-3.6.1-rc1-amd64-unknown-freebsd10.tar.xz) = 2ae62a6472aaa34fd8a0fb88be83320b09c646ac91b77bdb8ac1faf39268fbcd
SHA256 (clang+llvm-3.6.1-rc1-i386-unknown-freebsd10.tar.xz) = 887a5b05a83550abe0eee4f1cf2a9db0bb3f5a4a98818d44202d56ac72328541
-Dimitry
All tests passing on Fedora and openSUSE, binaries uploaded.
Windows binary uploaded. sha1:
d4a63197f3ce50ca71a46e1ac2728c7f73f8cc4a LLVM-3.6.1-rc1-win32.exe
I didn't have any issues.
Thanks,
Hans
clang+llvm-3.6.1-rc1-mips-linux-gnu.tar.xz
All good
clang+llvm-3.6.1-rc1-mipsel-linux-gnu.tar.xz
Still running.
So far only ClamAV has failed. This seems to be due to forgetting to install zlib1g-dev after rebuilding the system recently. I'll re-run this test once the others finish
clang+llvm-3.6.1-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to Mips)
* Still running.
* For the 'mipsel-img-linux-gnu -mips32r6 -mfpxx', 'mipsel-img-linux-gnu -mmicromips' test runs I have several regressions that look like timeouts caused by a busy system. I'm re-running these at the moment and they are passing so far.
* For 'mips-img-linux-gnu -mips64r6 -mabi=n32' test run I have several regressions that look like timeouts caused by a busy system. I'll re-run these once the rest finish.
* For the 'mips-img-linux-gnu -mips64r6 -mabi=n32' test run I also have two failures that look like regressions. MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 is segfaulting. MultiSource/Applications/kimwitu++/kc is failing the hashed-output reference check. I'm looking into these.
I've disassembled the failing MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 and compared it to the one from the LLVM 3.6.0 test runs. There's nothing obvious. We've removed some useless 'addiu $sp,$sp,0', eliminated two (seemingly redundant) sign extends, and the addresses of functions+data has changed slightly.
So, I've uploaded a new binary, built with a stable Debian, GCC 4.9.2, etc.
I'm seeing two execution failures in the test-suite:
MultiSource/Benchmarks/MiBench/consumer-typeset/consumer-typeset
MultiSource/UnitTests/C++11/frame_layout/frame_layout
Investigating...
cheers,
--renato
MultiSource/Benchmarks/MiBench/consumer-typeset/consumer-typeset
This was a fluke. The test passed later on all subsequent runs.
MultiSource/UnitTests/C++11/frame_layout/frame_layout
This one is a new test, and I believe it wasn't there in 3.6.0, so
it's ok to fail, since the patch hasn't been backported.
$ ./frame_layout | grep NOT
+----, int_local, alignment: 4096 ALIGNMENT NOT AS EXPECTED: 0x7fec948520
+----, double_local, alignment: 4096 ALIGNMENT NOT AS EXPECTED: 0x7fec948510
...
Kristof,
Is this a fair assessment? If so, AArch64 3.6.1 is green.
cheers,
--renato
Renato, your assessment is spot on - the frame_layout test was
added to verify a bunch of frame layout aspects and indeed
the AArch64 backend didn't support over-aligning objects
on the stack on the 3.6 branch. This has been implemented
on trunk.
Thanks,
Kristof
Perfect, thanks!
The binary in the SFTP site is good to go, then.
cheers,
--renato
I've disassembled the failing MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 and compared it to
the one from the LLVM 3.6.0 test runs. There's nothing obvious. We've removed some useless
'addiu $sp,$sp,0', eliminated two (seemingly redundant) sign extends, and the addresses of
functions+data has changed slightly.
I've investigated further and I'm fairly confident that r235869 (http://llvm.org/viewvc/llvm-project?view=revision&revision=235869) is the cause of this regression.
The problem is these three definitions:
// Bypass trunc nodes for bitwise ops.
def : MipsPat<(i32 (trunc (and GPR64:$lhs, GPR64:$rhs))),
(EXTRACT_SUBREG (AND64 GPR64:$lhs, GPR64:$rhs), sub_32)>;
def : MipsPat<(i32 (trunc (or GPR64:$lhs, GPR64:$rhs))),
(EXTRACT_SUBREG (OR64 GPR64:$lhs, GPR64:$rhs), sub_32)>;
def : MipsPat<(i32 (trunc (xor GPR64:$lhs, GPR64:$rhs))),
(EXTRACT_SUBREG (XOR64 GPR64:$lhs, GPR64:$rhs), sub_32)>;
They're correct around 95% of the time since the instructions that act on i32 only care about the lowest 32-bits of the GPR. However, comparison instructions such as BEQ compare the whole 64-bit GPR, even for i32, and therefore needed the sign-extend we used to generate.
I'm going to try a build with that patch reverted to confirm this and assuming I'm right I'll revert this merge.
clang+llvm-3.6.1-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to Mips)
* Still running.
* For the 'mipsel-img-linux-gnu -mips32r6 -mfpxx', 'mipsel-img-linux-gnu -mmicromips' test runs I have
several regressions that look like timeouts caused by a busy system. I'm re-running these at the
moment and they are passing so far.
Just a quick update: The 'mipsel-img-linux-gnu -mips32r6 -mfpxx' failures all passed when rerun while the system was less busy. I've just started the re-runs for 'mipsel-img-linux-gnu -mmicromips'.
Has this been fixed in trunk? If the fix is simple, than maybe
applying it would be preferable to reverting this patch, no?
cheers,
--renato
Not yet, these two failures were the first time we had seen the problem. We're still looking into fixing it properly but I'm currently thinking that the correct fix is to add
if (Subtarget.isGP64bit())
setOperationAction(ISD::SETCC, MVT::i32, Promote);
to MipsISelLowering.cpp and sort out the consequences of this on the patterns for all the comparison instructions. This is likely to be a fairly big change to our target.
Right, so the best thing is probably reverting this one for 3.6.1.
cheers,
--renato
I agree. I reverted it this morning (in r237432) after confirming that doing so fixed the regressions. I've also kicked off the cross-compilation test-runs again just to be sure removing it doesn't break anything else.
Tom, do you think we need an RC2 for this one? AFAIK, this was the
only failure, and if Daniel's tests pass after reverting it, we may be
ok for just a final release.
cheers,
--renato
The cross-compilation testruns all passed with r237432 reverted.