"Bingfeng Mei" <b...@broadcom.com> writes: > I think I found the cause. find_reloads_address returns 0 even > it reloads both parts of address (see the patch). Therefore, > corresponding address_reloaded[i] is not set and in > the following code of find_reloads, > > if (EXTRA_CONSTRAINT_STR (operand, c, p)) > win = 1; > /* If the address was already reloaded, > we win as well. */ > else if (MEM_P (operand) > && address_reloaded[i] == 1) <-- address_reloaded[i] still 0 > win = 1; > ... > > Extra reload is thus generated even it is unnecessary > and causes ICE. > > It looks like a general GCC bug. But I couldn't produce > a test for x86. The following patch is bootstrapped > and passes tests on x86_64-unknown-linux-gnu. Is it > OK to apply the patch? > > Cheers, > Bingfeng > > > Index: reload.c > =================================================================== > --- reload.c (revision 167979) > +++ reload.c (working copy) > @@ -5188,7 +5188,7 @@ find_reloads_address (enum machine_mode > &XEXP (ad, 1 - op_index), opnum, > type, 0, insn); > > - return 0; > + return 1;
I'm willing to believe that there is a problem here, but that patch isn't right. find_reloads_address should only return 1 if the address is replaced or reloaded as a whole, and that is not what is happening here. What is happening here is that the components of the address are being reloaded. Frankly I would fix this problem in LEGITIMIZE_RELOAD_ADDRESS. Ian
