[LLVMdev] 3.6.1 -rc1 has been tagged. Testing begins.

[Tom Stellard]

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
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Renato Golin]

On 11 May 2015 at 21:30, Tom Stellard <t...@stellard.net> wrote:
> 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.

ARM binary passes all tests / test-suite. Uploaded.

AArch64 to come next.

cheers,
--renato

[Ben Pope]

On Tuesday, May 12, 2015 04:30 AM, Tom Stellard wrote:
> 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.

Ubuntu 14.04 x86_64 looks good, uploaded
clang+llvm-3.6.1-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz

Ben

[Renato Golin]

On 12 May 2015 at 10:23, Renato Golin <renato...@linaro.org> wrote:
> ARM binary passes all tests / test-suite. Uploaded.

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.

[Dimitry Andric]

On 11 May 2015, at 22:30, Tom Stellard <t...@stellard.net> wrote:
> 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.

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

[Nikola Smiljanic]

All tests passing on Fedora and openSUSE, binaries uploaded.

_______________________________________________
cfe-dev mailing list
cfe...@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

[Hans Wennborg]

On Mon, May 11, 2015 at 1:30 PM, Tom Stellard <t...@stellard.net> wrote:
> 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.

Windows binary uploaded. sha1:
d4a63197f3ce50ca71a46e1ac2728c7f73f8cc4a LLVM-3.6.1-rc1-win32.exe

I didn't have any issues.

Thanks,
Hans

[Daniel Sanders]

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.

[Renato Golin]

On 13 May 2015 at 18:47, Renato Golin <renato...@linaro.org> wrote:
> 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.

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...

[Renato Golin]

On 14 May 2015 at 16:49, Renato Golin <renato...@linaro.org> wrote:
> 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.

[Kristof Beyls]

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

> -----Original Message-----
> From: Renato Golin [mailto:renato...@linaro.org]
> Sent: 14 May 2015 17:31
> To: Tom Stellard
> Cc: LLVM Dev; Clang Dev; Kristof Beyls
> Subject: Re: [LLVMdev] 3.6.1 -rc1 has been tagged. Testing begins.
>
> On 14 May 2015 at 16:49, Renato Golin <renato...@linaro.org> wrote:
> > 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

[Renato Golin]

On 14 May 2015 at 17:50, Kristof Beyls <kristo...@arm.com> wrote:
> 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.

Perfect, thanks!

The binary in the SFTP site is good to go, then.

[Daniel Sanders]

> 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'.

________________________________________
From: Daniel Sanders
Sent: 14 May 2015 11:52
To: Tom Stellard; llv...@cs.uiuc.edu
Cc: cfe...@cs.uiuc.edu
Subject: RE: [LLVMdev] 3.6.1 -rc1 has been tagged. Testing begins.

[Renato Golin]

On 14 May 2015 at 21:39, Daniel Sanders <Daniel....@imgtec.com> wrote:
> 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.

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

[Daniel Sanders]

> -----Original Message-----
> From: Renato Golin [mailto:renato...@linaro.org]

> Sent: 15 May 2015 12:51
> To: Daniel Sanders
> Cc: Tom Stellard; llv...@cs.uiuc.edu; cfe...@cs.uiuc.edu
> Subject: Re: [LLVMdev] 3.6.1 -rc1 has been tagged. Testing begins.
>
> On 14 May 2015 at 21:39, Daniel Sanders <Daniel....@imgtec.com>
> wrote:
> > 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.
>
> 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.

[Renato Golin]

On 15 May 2015 at 13:34, Daniel Sanders <Daniel....@imgtec.com> wrote:
> 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

[Daniel Sanders]

> -----Original Message-----
> From: Renato Golin [mailto:renato...@linaro.org]
> Sent: 15 May 2015 14:15
> To: Daniel Sanders
> Cc: Tom Stellard; llv...@cs.uiuc.edu; cfe...@cs.uiuc.edu
> Subject: Re: [LLVMdev] 3.6.1 -rc1 has been tagged. Testing begins.
>

> On 15 May 2015 at 13:34, Daniel Sanders <Daniel....@imgtec.com>
> wrote:
> > 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.

[Renato Golin]

On 15 May 2015 at 14:32, Daniel Sanders <Daniel....@imgtec.com> wrote:
> 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

[Daniel Sanders]

The cross-compilation testruns all passed with r237432 reverted.
________________________________________
From: Renato Golin [renato...@linaro.org]
Sent: 15 May 2015 14:42

To: Daniel Sanders
Cc: Tom Stellard; llv...@cs.uiuc.edu; cfe...@cs.uiuc.edu
Subject: Re: [LLVMdev] 3.6.1 -rc1 has been tagged. Testing begins.