[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 --- Comment #11 from Peter Bergner --- (In reply to Nicholas Krause from comment #9) > Sorry if I'm misunderstanding the power code but is there a way to rewrite > the test to: > if (VECTOR_MEM_ALTIVEC(mode) > and another branch for VSX_P instructions. There's no need. > I'm assuming that because its checking both we can get a infinite loop. I'm > assuming that in order to hand this off to the LRA we will need to > rewrite in to have two paths one for VSX_P and one for standard MEM_ALTIVEC. No. We get into an infinite loop, because LRA passes us a valid Altivec type address and rs6000_legitimate_address_p erroneously tells LRA, that it is invalid. So LRA tries to spill it again. After a few iterations of that, the address is simplified to just a register inside the (and: ...) and that is trivially valid, but rs6000_legitimate_address_p continues to say it's invalid. At this point, LRA replaces that one reg with a copy of the one reg. Again, rs6000_legitimate_address_p says it's invalid, so around and around it goes. The bug isn't that we cannot recognize the address as valid. It's that we have a bogus test that uses VECTOR_MEM_ALTIVEC_P(), which only is true for vector modes, when Altivec is enabled and VSX is disabled. When VSX is enabled (which implies Altivec is enabled), VECTOR_MEM_ALTIVEC_P() return false. That is because rs6000_vector_mem[] returns VECTOR_VSX rather than VECTOR_ALTIVEC when VSX is enabled.
[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 --- Comment #10 from Peter Bergner --- (In reply to Jakub Jelinek from comment #8) > With a reversion we get to a known state, keeping it we remain in far less > tested state, so unless one bug is much more severe than the other one, I'd > go for the known state. Ok, I pushed the reversions for both GCC 8 & 9.
[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 Nicholas Krause changed: What|Removed |Added CC||xerofoify at gmail dot com --- Comment #9 from Nicholas Krause --- Peter and Jakub, Sorry if I'm misunderstanding the power code but is there a way to rewrite the test to: if (VECTOR_MEM_ALTIVEC(mode) and another branch for VSX_P instructions. I'm assuming that because its checking both we can get a infinite loop. I'm assuming that in order to hand this off to the LRA we will need to rewrite in to have two paths one for VSX_P and one for standard MEM_ALTIVEC. Maybe Vlad as mentioned has a better idea about the LRA issues. But I'm very suspicious of checking both VSX and non VSX_P instructions in the same way for legitimate_address_p. Maybe I'm misunderstanding the issue outside of backporting,
[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 --- Comment #8 from Jakub Jelinek --- Well, there is a significant difference, the other PR has been there for more than 2 years before somebody discovered it, while this one was discovered much quicker and there is a possibility there could be other issues too. With a reversion we get to a known state, keeping it we remain in far less tested state, so unless one bug is much more severe than the other one, I'd go for the known state.
[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 --- Comment #7 from Peter Bergner --- Another option would be to release now without reverting. If we revert and then release, then we're shipping a compiler with bug PR93658 in it. If we release now without reverting, then PR93658 is fixed and we'll ship with this bug in it. Both bugs fail with -O3 -mcpu=power8 -fstack-protector-strong and both can be worked around using -O2. The only difference would be we either ICE with this test case, or we go into an infinite loop in LRA. I guess as a user, I'd prefer the ICE. Your choice though.
[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 --- Comment #6 from Jakub Jelinek --- My slight preference would be probably reversion, maybe even on both 8 and 9 branches, do the releases, fix on the trunk, give it two or three weeks to settle and then backport again, but maybe I'm just trying to be too cautious when ra is involved.
[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 Segher Boessenkool changed: What|Removed |Added Component|target |rtl-optimization --- Comment #5 from Segher Boessenkool --- Not a target bug. Andrew, please don't change classification unless you know where the problem is.
[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #3 from Peter Bergner --- Looking.
[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.3 |8.4 Summary|[9/10 Regression] ICE in|[8/9/10 Regression] ICE in |decompose_normal_address, |decompose_normal_address, |at rtlanal.c:6403 on|at rtlanal.c:6403 on |powerpc64le-linux-gnu since |powerpc64le-linux-gnu since |r10-6762|r10-6762 --- Comment #2 from Jakub Jelinek --- Indeed, current 8 branch ICEs too, which makes this an 8.4 release blocker.
