[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from rsandifo at gcc dot gnu.org --- Fixed for GCC 10+.
[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305 --- Comment #16 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:3e44c89e672ec18ce31edecf5b5bac980ce411e5 commit r10-10040-g3e44c89e672ec18ce31edecf5b5bac980ce411e5 Author: Richard Sandiford Date: Tue Aug 17 15:14:22 2021 +0100 aarch64: Fix address mode for vec_concat pattern [PR100305] The load_pair_lanes patterns match a vec_concat of two adjacent 64-bit memory locations as a single 128-bit load. The Utq constraint made sure that the address was suitable for a 128-bit vector, but this meant that it allowed some addresses that aren't valid for the 64-bit element mode. Two obvious fixes were: (1) Continue to accept addresses that aren't valid for the element modes. This would mean changing the mode of operands[1] before printing it. It would also mean using a custom predicate instead of the current memory_operand. (2) Restrict addresses to the intersection of those that are valid element and vector addresses. The problem with (1) is that, as well as being more complicated, it doesn't deal with the fact that we still have a memory_operand for the second element. If we encourage the first operand to be outside the range of a normal element memory_operand, we'll have to reload the second operand to make it valid. This reload will often be dead code, but will be kept around because the RTL pattern makes it look as though the second element address is still needed. This patch therefore does (2) instead. As mentioned in the PR notes, I think we have a general problem with the way that the aarch64 port deals with paired addresses. There's nothing to guarantee that the two addresses will be reloaded in a way that keeps them âobviouslyâ adjacent, so the rtx_equal_p conditions could fail if something rechecked them later. For this particular pattern, I think it would be better to teach simplify-rtx.c to fold the vec_concat to a normal vector memory reference, to remove any suggestion that targets should try to match the unsimplified form. That obviously wouldn't be suitable for backports though. gcc/ PR target/100305 * config/aarch64/constraints.md (Utq): Require the address to be valid for both the element mode and for V2DImode. gcc/testsuite/ PR target/100305 * gcc.c-torture/compile/pr100305.c: New test. (cherry picked from commit 668df9e769e7d89bcefa07f72b68dcae9a8f3970)
[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305 Richard Biener changed: What|Removed |Added Target Milestone|11.2|11.3 --- Comment #15 from Richard Biener --- GCC 11.2 is being released, retargeting bugs to GCC 11.3
[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305 --- Comment #14 from rsandifo at gcc dot gnu.org --- (In reply to Gilles Gouaillardet from comment #13) > Thanks Richard for the quick fix. > > I am happy to confirm that the latest trunk passes the three reproducers > included in this ticket. > > However, the latest gcc-11 branch only passes the mini reproducer you posted > (and crashes with a similar stack trace with Andrew's reproducer and the one > I trimmed from GROMACS) Hmm, those also pass for me on the branch (after g:cd0a059bd384da58d43674496a79ecb7de610800). However, it's certainly possible that some of the other patterns have a similar bug. I'll try a few variations to see if I can reproduce.
[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305 --- Comment #13 from Gilles Gouaillardet --- Thanks Richard for the quick fix. I am happy to confirm that the latest trunk passes the three reproducers included in this ticket. However, the latest gcc-11 branch only passes the mini reproducer you posted (and crashes with a similar stack trace with Andrew's reproducer and the one I trimmed from GROMACS) FWIW, I am still unable to build GROMACS 2021.1 with the latest trunk (both neon and SVE, now checking x86_64), but this is a different issue (looks like a C++ frontend issue, unless this is a legit error in the application).
[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a515ce926b9d779922debc33ecad424c9ac22c65 commit r11-8327-ga515ce926b9d779922debc33ecad424c9ac22c65 Author: Jakub Jelinek Date: Thu Apr 29 11:42:08 2021 +0200 testsuite: Remove dg-options from pr100305.c [PR100305] The test FAILs on i?86-linux (due to -Wpsabi warnings). But, on closer inspection it seems there is another problem, the dg-options in the testcase means that the test is compiled with -O0 -O, -O1 -O, -O2 -O, -O3 -O, -Os -O etc. options, so effectively is tested multiple times with the same options. Fixed by dropping the dg-options line, then we have -w by default and iterate over all the optimization levels (including the -O). 2021-04-29 Jakub Jelinek PR target/100305 * gcc.c-torture/compile/pr100305.c: Remove dg-options. Add PR line. (cherry picked from commit 62a44a9797edce11b1f7051ea0016ee975d41233)
[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:62a44a9797edce11b1f7051ea0016ee975d41233 commit r12-283-g62a44a9797edce11b1f7051ea0016ee975d41233 Author: Jakub Jelinek Date: Thu Apr 29 11:42:08 2021 +0200 testsuite: Remove dg-options from pr100305.c [PR100305] The test FAILs on i?86-linux (due to -Wpsabi warnings). But, on closer inspection it seems there is another problem, the dg-options in the testcase means that the test is compiled with -O0 -O, -O1 -O, -O2 -O, -O3 -O, -Os -O etc. options, so effectively is tested multiple times with the same options. Fixed by dropping the dg-options line, then we have -w by default and iterate over all the optimization levels (including the -O). 2021-04-29 Jakub Jelinek PR target/100305 * gcc.c-torture/compile/pr100305.c: Remove dg-options. Add PR line.
