[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #11 from Jakub Jelinek --- So fixed?

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Mon Dec 3 13:04:57 2018 New Revision: 266736 URL: https://gcc.gnu.org/viewcvs?rev=266736=gcc=rev Log: PR target/88287 * g++.target/aarch64/sve/vcond_1.C: Adjust for

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #9 from Christophe Lyon --- Yes, that works, thanks!

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 Jakub Jelinek changed: What|Removed |Added Attachment #45141|0 |1 is obsolete|

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #7 from Christophe Lyon --- Ha, yes the testcase checks whether the assembler supports .arch_extension sve, that's why it's unsupported in your testcase. Here is the full list of regressions I noticed:

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #6 from Jakub Jelinek --- Created attachment 45141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45141=edit gcc9-pr88287.patch Ok, reproduced in my incomplete cross with that option (no binutils), but can't reproduce on

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #4 from Christophe Lyon --- Created attachment 45139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45139=edit vcond_1.s.ok (before r266620)

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #5 from Christophe Lyon --- Created attachment 45140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45140=edit vcond_1.s.ko (after r266620)

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #3 from Christophe Lyon --- I do see different output with and without r266620 (attaching vcond_1.s.ok and vcond_1.s.ko). They are now checking different condition codes: $ diff vcond_1.s.ok vcond_1.s.ko1014c1014 < cmplt

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-12-03 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-11-30 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #2 from Jakub Jelinek --- BTW, it is unclear to me how to reproduce it, I've tried ./cc1plus -quiet -O -msve-vector-bits=256 vcond_1.C -o vcond_1.s -nostdinc -march=armv8.4-a+simd with the match.pd changes reverted and the same

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

2018-11-30 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88287 --- Comment #1 from Jakub Jelinek --- FAILs just because it has too much scan-assembler in it and expects something in particular, or do we generate worse code? The patch certainly added some canonicalization that was previously done only for