This is the mail archive of the
mailing list for the GCC project.
Re: GCC 5.4 Release Candidate available from gcc.gnu.org
- From: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 31 May 2016 12:19:49 +0100
- Subject: Re: GCC 5.4 Release Candidate available from gcc.gnu.org
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1605271342170 dot 13344 at t29 dot fhfr dot qr> <574D7165 dot 2010309 at foss dot arm dot com> <alpine dot LSU dot 2 dot 11 dot 1605311316560 dot 1493 at t29 dot fhfr dot qr>
On 31/05/16 12:17, Richard Biener wrote:
On Tue, 31 May 2016, Kyrill Tkachov wrote:
On 27/05/16 12:43, Richard Biener wrote:
The first release candidate for GCC 5.4 is available from
and shortly its mirrors. It has been generated from SVN revision 236809.
I have sofar bootstrapped the release candidate on x86_64-suse-linux-gnu.
Please test the release candidate and report any issues to bugzilla.
If all goes well I'd like to release GCC 5.4 at the beginning of next
Bootstrap and test on arm-none-linux-gnueabihf looks fine.
Unfortunately, on aarch64-none-linux-gnu I noticed a regression compared to
FAIL: gcc.target/aarch64/vbslq_u64_1.c scan-assembler-times bif\\tv 1
This is PR 68696 that has been triggered on that branch.
The patch fixing that is at:
I have bootstrapped and tested it on aarch64-none-linux-gnu on top of the 5.4
and it fixes the regression. It applies cleanly to that branch.
Is it okay to backport it to the branch?
While it doesn't look like having the same cause (r231178) the patch
looks safe to me to backport.
Indeed, the bug is a missing pattern in the backend that ends up
with us relying on xor+and sequences being emitted in a certain order
after the tree passes, so it can be triggered by any of a number of tree-level
I'll commit it shortly.