https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #8 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #2)
> I do not set any default CPU:
The default cpu on ppc64le is (should be!) POWER8.
That said, I cannot recreate the issue with a cross build using current trunk.
I will say that the change you identified did cause some fallout that was fixed
with a later change (below) that looks related to the bad insn you are seeing.
Maybe this is a bisec issue? Does adding the later fix from the following
"fix" the ICE?
commit dd75498db79675a1a0b73c25e5f110969ee72d9d
Author: Peter Bergner <berg...@linux.ibm.com>
AuthorDate: Thu Apr 16 23:26:41 2020 -0500
Commit: Peter Bergner <berg...@linux.ibm.com>
CommitDate: 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.
If that fixes it, are you really seeing the same ICE on current trunk?
