Re: 0xffffffff when BFD64

[Alexandre Oliva <aoliva at cygnus dot com>]

On Apr  7, 2000, Alan Modra <alan@linuxcare.com.au> wrote:

> On 7 Apr 2000, Alexandre Oliva wrote:
>> On Apr  7, 2000, Alan Modra <alan@linuxcare.com.au> wrote:
>> 
>> > I guess we should check all hex constants in the range 0x80000000 to
>> > 0xffffffff, replacing them with const & N_ONES(32).  Blechh.
>> 
>> I started doing something like that, but gave up.  It's just too much
>> of a hassle.  I'd rather just fix the problem at hand, which occurs

> Actually, a plain (unsigned) should do it, as you did in your sparc
> patch.  binutils requires that int and unsigned be at least 32 bits.

I don't think it always does.  If the constant is used in a test such
as [<>]=? test, and it is not casted back to int, it may produce
different results.

Hmmm...  No, the current code assumes the constant is unsigned.  In
fact, explicitly casting it to unsigned would *protect* it from being
taken as int, in case some compiler ever decides to use 64 bits for
int.

So, here's the revised patch-generator:

grep -lr '\<0x[89a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z]\>' bfd opcodes binutils gas ld |
while read f; do
  sed 's,\<0x[89a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z]\>,(unsigned)(&),g' \
    < $f > $f.new && mv $f.new $f
done

-- 
Alexandre Oliva    Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me