* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
@ 2020-04-01 8:09 ` jakub at gcc dot gnu.org
2020-04-01 8:10 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-01 8:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Richard Sandiford said on this PR, probably lost due to sourceware migration:
Sorry for the slow reply, been a bit of a hectic week.
I think both fixes would be valid. Like you say, the address
parsing code isn't yet ready to handle addresses that apply
an offset *before* the address "mutations". That's because
no target has yet wanted to support such an address. So as
things stand, the current address is not valid and shouldn't
have been created.
In some ways this is similar to creating an invalid highpart
subreg for the upper word of a doubleword vector hard register,
or a subreg that falls foul of some simplify_subreg_regno rule.
The RA has code to avoid doing that, see init_subregs_of_mode
and its users. We could do something similar here for
REG_EQUIV MEMs. One option would be to key off whether
strip_address_mutations is a no-op on the address.
Another would be to check whether each required sub-MEM
is valid for its mode and offset. The latter would be
more elaborate but might produce better code in general,
not just for cases like this.
Like you say in comment 4, even the zero-offset half isn't
actually a valid address for PowerPC, so either of the two
options should give better code as well as fixing the bug.
On the other hand, the idea was always that address_info
and its users could be extended if new targets have new
requirements. So if we want to make this operation valid
then that would be OK too.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
2020-04-01 8:09 ` [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762 jakub at gcc dot gnu.org
@ 2020-04-01 8:10 ` jakub at gcc dot gnu.org
2020-04-01 15:58 ` bergner at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-01 8:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Any progress?
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
2020-04-01 8:09 ` [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762 jakub at gcc dot gnu.org
2020-04-01 8:10 ` jakub at gcc dot gnu.org
@ 2020-04-01 15:58 ` bergner at gcc dot gnu.org
2020-04-01 16:02 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-04-01 15:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #17 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #16)
> Any progress?
I'm sorry, I've been swamped with other things. Even so, given this (up to now
latent) bug has been there a while, and any patch here will affect all other
architectures, do we really want to patch this area so close to the release?
Using -O2 is a workaround.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-04-01 15:58 ` bergner at gcc dot gnu.org
@ 2020-04-01 16:02 ` jakub at gcc dot gnu.org
2020-04-01 16:09 ` bergner at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-01 16:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yes, we want to fix it, unless you want to revert the PR93658 change even for
GCC 10 and reapply only to 11 once this bug is fixed too.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-04-01 16:02 ` jakub at gcc dot gnu.org
@ 2020-04-01 16:09 ` bergner at gcc dot gnu.org
2020-04-15 9:58 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-04-01 16:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #19 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #18)
> Yes, we want to fix it, unless you want to revert the PR93658 change even
> for GCC 10 and reapply only to 11 once this bug is fixed too.
Ok, let me take another stab at fixing this before we go the other route.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-04-01 16:09 ` bergner at gcc dot gnu.org
@ 2020-04-15 9:58 ` jakub at gcc dot gnu.org
2020-04-15 20:05 ` bergner at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-15 9:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Have you managed to make some progress? This is one of the last 10 P1 blockers
of the release.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-04-15 9:58 ` jakub at gcc dot gnu.org
@ 2020-04-15 20:05 ` bergner at gcc dot gnu.org
2020-04-15 22:35 ` bergner at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-04-15 20:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #21 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #20)
> Have you managed to make some progress? This is one of the last 10 P1
> blockers of the release.
I'm still working on it. I have a patch that fixes the issue, but I'm not sure
yet whether it's the "right" patch. Hopefully I'll know soon.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2020-04-15 20:05 ` bergner at gcc dot gnu.org
@ 2020-04-15 22:35 ` bergner at gcc dot gnu.org
2020-04-15 23:24 ` segher at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-04-15 22:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #22 from Peter Bergner <bergner at gcc dot gnu.org> ---
To be more specific, I have implemented the hook cannot_substitute_mem_equiv_p
for rs6000 that rejects these and: altivec addresses. The nice thing about the
patch is that it only affects rs6000, whereas a lra-constraints.c or rtlanal.c
change could affect everyone.
I have confirmed that the test case in Comment #1 compiles and we get the same
asm generated as a compiler built with the revision before my patch that caused
the ICE. I also confirmed that test case pr93658.c which used to go into an
infinite loop in LRA before my previous patch still compiles fine.
I'm running the testsuite now to see whether there are any regressions.
Whether this is the best long term fix is unknown right now (it could be), but
it might be the best thing for GCC 10 with the release so close. I'd rather
not revert the fix for PR93658 just to hide this bug again.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2020-04-15 22:35 ` bergner at gcc dot gnu.org
@ 2020-04-15 23:24 ` segher at gcc dot gnu.org
2020-04-17 4:27 ` cvs-commit at gcc dot gnu.org
2020-04-17 4:28 ` bergner at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: segher at gcc dot gnu.org @ 2020-04-15 23:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #23 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(cannot_substitute_mem_equiv_p,
"A target hook which returns @code{true} if @var{subst} can't\n\
substitute safely pseudos with equivalent memory values during\n\
register allocation.\n\
I guess "ICEs the compiler" falls under "not safely" ;-)
Since AltiVec addresses are "legacy", this is a fine change (well
I haven't seen the actual patch yet, heh).
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2020-04-15 23:24 ` segher at gcc dot gnu.org
@ 2020-04-17 4:27 ` cvs-commit at gcc dot gnu.org
2020-04-17 4:28 ` bergner at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-17 4:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Peter Bergner <bergner@gcc.gnu.org>:
https://gcc.gnu.org/g:dd75498db79675a1a0b73c25e5f110969ee72d9d
commit r10-7764-gdd75498db79675a1a0b73c25e5f110969ee72d9d
Author: Peter Bergner <bergner@linux.ibm.com>
Date: Thu Apr 16 23:26:41 2020 -0500
rs6000: Fix ICE in decompose_normal_address. [PR93974]
Fix an ICE in decompose_normal_address(), which cannot handle Altivec AND:
addresses, by disallowing them via implementing the target hook
rs6000_cannot_substitute_mem_equiv_p.
gcc/
PR rtl-optimization/93974
* config/rs6000/rs6000.c (TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P):
Define.
(rs6000_cannot_substitute_mem_equiv_p): New function.
gcc/testsuite/
PR rtl-optimization/93974
* g++.dg/pr93974.C: New test.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
[not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2020-04-17 4:27 ` cvs-commit at gcc dot gnu.org
@ 2020-04-17 4:28 ` bergner at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-04-17 4:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Peter Bergner <bergner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #25 from Peter Bergner <bergner at gcc dot gnu.org> ---
Patch committed. Fixed.
^ permalink raw reply [flat|nested] 11+ messages in thread