Re: "Error: constant too large" on mips gas

[Eric Christopher <echristo@redhat.com>]

> 
> gas/:
> 2005-04-11  Maciej W. Rozycki  <macro@linux-mips.org>
> 
>         * config/tc-mips.c (IS_ZEXT_32BIT_NUM): New macro.
>         (normalize_address_expr): New function to sign-extend address
>         offsets that fit into 32 bits in 32-bit mode.
>         (macro_build_ldst_constoffset): Use normalize_address_expr()
>         instead of a handcoded sequence.
>         (load_register): Likewise.  Report oversized numbers in a useful
>         way.
>         (macro) [ld_st, ldd_std]: Reject all oversized offsets, not only
>         for constant addresses.  Report oversized numbers in a useful way.
>         (mips_ip): Use normalize_address_expr() for addresses.
> 
> gas/testsuite/:
> 2005-04-11  Maciej W. Rozycki  <macro@linux-mips.org>
> 
>         * gas/mips/ldstla-32.s: Exclude offsets that are now meant to fail
>         and include more instructions/offsets that are meant to succeed.
>         Use $4 instead $3 to avoid register dependencies.
>         * gas/mips/ldstla-32.d: Update accordingly.
>         * gas/mips/ldstla-32-shared.d: Likewise.
> 	* gas/mips/ldstla-32-mips3.d: New test based on the above, except 
> 	for mips3.
> 	* gas/mips/ldstla-32-mips3-shared.d: Similarly, for PIC.
> 	* gas/mips/ldstla-32-mips3.s: Source for the new tests.
>         * gas/mips/ldstla-32-1.s: New test for offsets that are meant to
>         fail.
> 	* gas/mips/ldstla-32-mips3-1.s: Likewise, for mips3.
>         * gas/mips/ldstla-32-1.l: Stderr output for the new test.
> 	* gas/mips/ldstla-32-mips3-1.l: Likewise.
>         * gas/mips/mips.exp: Run the new tests.
> 
>  I've tested it with mips64el-linux-gnu with no regressions.  OK to apply?
> 

This is all OK for 2.16, committing it to mainline for the current
timeframe is ok since you plan on working on a different implementation.
I'd like them to be mostly the same while working on things.

Interestingly enough there's still the problem of this:

la $2,0x80000000

on 64-bit abis. I believe the general consensus is to sign-extend the
constant when loading it. Currently we expand to:

ori $2,$0,0x8000
dsll $2,$2,0x10

which ends up getting us a zero-extended value which ends up being
unpredictable for calculations based on that.

>  I haven't updated documentation though, as I consider it a short-term 
> hack for 2.16 only.  For 2.17, I think expr() should be modified to be 
> able to do signed arithmetic/logic and perform operations modulo (1 << n), 
> at least for reasonable values of n.  Therefore only that implementation 
> would be able to specify the desired number ranges accepted rather than 
> accept what happens to be implemented.
> 
>  Does it sound reasonable?  I hope so.

Elaborate a bit please? It sounds ok so far, but I like examples :)

I'm working on some documentation for all of the macro instructions we
support since this is getting to be mind numbing as to what we should
expect and how we handle it. Any start that you have would be nice as
well.

-eric