This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [patch] MIPS/gas: load/store address overflow on binutils 2.14
- From: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- To: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- Cc: binutils at sources dot redhat dot com, Atsushi Nemoto <anemo at mba dot ocn dot ne dot jp>
- Date: Fri, 12 Sep 2003 16:33:31 +0200 (MET DST)
- Subject: Re: [patch] MIPS/gas: load/store address overflow on binutils 2.14
- Organization: Technical University of Gdansk
On Fri, 12 Sep 2003, Thiemo Seufer wrote:
> > It looks like a good idea, except that I'd do sign extension differently
> > -- to let gcc know what we really mean.
>
> Huh? gcc provides input for the assembler, it will never see what
> happens here.
Well, gcc is definitely going to see gas code -- it won't hurt to try to
optimize it, either.
> > Like this:
> >
> > if (! dbl && (! (ep->X_add_number & ~(offsetT) 0xffffffff))
> > && ! (-ep->X_add_number & ~(offsetT) 0xffffffff)))
> > ep->X_add_number = (ep->X_add_number << 32) >> 32;
>
> IIRC X_add_number is unsigned.
Well, offsetT seems to be defined as signed: either "bfd_signed_vma", or,
for legacy code, "long".
> > This might need checking for BFD64 though. The second check of
> > ep->X_add_number is needed to handle cases like "lw $2,-0xf0000000" (try
> > it out!).
>
> What's the meaning of a negative address?
I'd like to see all valid numbers handled consistently. While
"-0xf0000000" may look strange itself, a result of a more complicated
expression may also be negative and we should preserve the commutative
property of addition, i.e. we should not force people to reorder
operations to avoid unary minuses.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +