This is the mail archive of the
mailing list for the GCC project.
Re: PR 35232: Recent regression due to reload inheritance bug
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: rsandifo at nildram dot co dot uk (Richard Sandiford)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 19 Mar 2008 22:51:54 +0100 (CET)
- Subject: Re: PR 35232: Recent regression due to reload inheritance bug
Richard Sandiford wrote:
> >> However, going back to the "this isn't worse or better after my patch",
> >> I think it would be best to deal with this as a separate issue.
> >> Especially given that I'm still hoping to get this patch into 4.3. ;)
> > OK. I agree that your patch doesn't change the behaviour here, so I'm
> > fine with addressing this separately.
> OK, thanks. Since it's a one-liner, I'll probably test it after
> we've sorted out the current patch.
> Hmm. You're probably right that that's the intention behind the naming,
> but given that we're dealing with existing moves (and even looking at
> existing sets) it seems a very counter-intuitive scheme to me.
> However, it looks like both styles of naming are going to cause
> confusion, so can we compromise on the ever-bland "reg" instead?
> (The most natural names for the new "i"- and "nr"-like variables
> were "regno" and "nregs", so "reg" fits in quite nicely with that.)
That's fine with me as well ...
> OK, I've kept it as-is and added the new "regno" and "nregs" variables
> mentioned above. I also renamed "nregno" and "nnr" to "out_regno"/
> "in_regno"/"src_regno" and "out_nregs"/"in_nregs"/"src_nregs" for
> consistency. Hopefully this makes things a little easier to follow;
> having so many terse variable names doesn't help with what is already
> hard-to-understand code.
I certainly agree.
> Index: binutils/readelf.c
> --- binutils/readelf.c 2008-03-19 19:30:55.000000000 +0000
> +++ binutils/readelf.c 2008-03-19 21:00:59.000000000 +0000
> @@ -9125,6 +9125,33 @@ process_power_specific (FILE *file)
> +/* DATA points to the contents of a MIPS GOT that starts at VMA PLTGOT.
> + Print the Address, Access and Initial fields of an entry at VMA ADDR
> + and return the VMA of the next entry. */
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE