PATCH: Fix sign-extension of bignums

[Ian Lance Taylor]

Mark Mitchell <mark@codesourcery.com> writes:

> Could we generate a bignum when the negation overflows?

I know from experience that some people do write assembler code which
expects that assembly constants are handled as unsigned 32-bit values,
wrapping on overflow.  To make that work, we would have to convert
back from a bignum to an integer in scenarios which require an
integer, such as the immediate value in an instruction.  Right now
that does not happen--see, e.g., the handling of O_big in
i386_immediate() in gas/config/tc-i386.c, where a bignum is basically
treated as an error.  So generating a bignum for integer overflow in
expr.c would require modifying various pieces of code which call
expression() to convert back to an integer.

Note that bignums are unsigned values, so we would have to generate an
expression tree of O_uminus with a bignum.  This suggests the
possibility of generating O_uminus with an ordinary constant only in
the case of integer overflow.  We would then have to modify
emit_expr() to handle this case.  We would also to modify other uses
of expression(), as above.  Presumably either case could be handled
using a wrapper call.

The assembler has had irritating issues like this for a long time,
because the assembler has no notion of the proper size for arithmetic
operations (or, for that matter, the proper signedness).  Basically,
we assume that everything is a simple signed integer, unless it
obviously isn't.  And the size of the simple integer depends upon how
the assembler is configured (your test case would probably work
correctly if you configured with --enable-64-bit-bfd).  This approach
works 99% of the time, but fails for specific cases like yours.

I think a more coherent approach would require telling expression()
the context in which the expression is being evaluated, as that
effectively determines the appropriate size and signedness for the
arithmetic operations.

I'm not sure what other assemblers do.

Ian