Re: LO_SUM still breaking rs6000, revert patch?

[Geoff Keating <geoffk at geoffk dot org>]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> Very peculiar: this doesn't seem to be crashing in new code.
> 
> The problem is that print_operand in the 'L' (and other) cases uses
> plus_constant to address other words of an operand.  But in this case
> the address was a LO_SUM and so plus_constant doesn't now (and never did!)
> modify inside that.  So it makes a PLUS that output_address doesn't
> know how to handle.

Yes.  That's why plus_constant_for_output existed.  The difference
between plus_constant and plus_constant_for_output is that
plus_constant_for_output would go inside a LO_SUM; it was supposed to
be called only when this would be safe.

The code for 'L' used to (before your change, revision 1.187) look like:

	    output_address (plus_constant_for_output (XEXP (XEXP (x, 0), 0),
						      UNITS_PER_WORD));

and thus it used to work.

> The right thing to do is for me to modify the code in rs6000.c so that
> it calls adjust_address, but I admit to complete confusion as to how this
> ever worked.

Yes.  adjust_address is apparently the new equivalent of
plus_constant_for_output, with a less efficient calling sequence.
(I presume you have some good reason for removing plus_constant_for_output,
although I can't imagine what it might be.)

You probably need to go through your patch, see every place where you
replaced plus_constant_for_output with plus_constant, and then replace
plus_constant with adjust_address.

I would suggest that this time you test the patch on the systems that
are actually affected, not just on alpha.  There have also been
reports that PA is broken, and weren't there some reports about MIPS?.
I think you probably need to test on all the systems your previous
patch touched, that is arm, m68k, m88k, mips, pa, rs6000, and sparc,
to ensure you don't miss anything.  Some of these have simulators, I
would start by testing those first.

> Are we sure it's my patch that broke this?

Yes.

-- 
- Geoffrey Keating <geoffk@geoffk.org>