This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Thanks!

> 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)
>  			     display_power_gnu_attribute);
>  }
>  
> +/* 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.  */

Wrong patch?


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]