Ok, after debugging, this looks to be a bug in rs6000_legitimate_address_p().
At the beginning of LRA, we have the following insn:
(insn 520 67 71 5 (set (mem:V16QI (and:DI (reg/f:DI 110 sfp)
(const_int -16 [0xfff0])) [0 MEM
[(char *)&a + 16B]+0 S16 A128])
(re
Simple backports to GCC 8 and 9 exposed some bugs that have already been
fixed on trunk. The following patch resubmission includes those extra
fixes that need backports too:
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01253.html
--
You received this bug notification because you are a memb
Fixed everywhere.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1862053
Title:
Compiler gets stuck (or extremely slow) on ppc64el
To manage notifications about this bug go to:
https://bugs.launchpa
Here's the minimal test case using options -O3 -mcpu=power8 -fstack-
protector-strong:
void bar();
char b;
void
foo (void)
{
char a;
int d = b;
char *e = &a;
while (d)
*e++ = --d;
bar ();
}
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subs
So we are in an infinite loop in process_address() calling
process_address_1(). I've hacked in some code to ICE if we loop for too
long and I'm currently using creduce to minimize the test case.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Confirmed. With the options in Comment 4, I'm able to recreate the
hang/infinite loop. I'll have a look.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1862053
Title:
Compiler gets stuck (or extrem
I cannot recreate this with trunk or GCC 9 from today. DO you have
extra patches applied or ???
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1862053
Title:
Compiler gets stuck (or extremely slow)
(In reply to Jakub Jelinek from comment #8)
> On the #c7 testcase, this started with
> r8-6072-ga3a821c903c9fa2288712d31da2038d0297babcb (so I wonder why this
> isn't a 8/9/10 Regression).
I'm not sure Kelvin's patch is to blame. I think it's just exposing a
latent issue.
--
You received this b
