From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4161 invoked by alias); 11 Apr 2005 21:40:24 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 4105 invoked from network); 11 Apr 2005 21:40:17 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Apr 2005 21:40:17 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3BLeHPR023475 for ; Mon, 11 Apr 2005 17:40:17 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3BLeGO26454; Mon, 11 Apr 2005 17:40:16 -0400 Received: from dhcp-172-16-25-252.sfbay.redhat.com (dhcp-172-16-25-252.sfbay.redhat.com [172.16.25.252]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j3BLeAYE021862; Mon, 11 Apr 2005 17:40:12 -0400 Subject: Re: "Error: constant too large" on mips gas From: Eric Christopher To: "Maciej W. Rozycki" Cc: Daniel Jacobowitz , Atsushi Nemoto , binutils@sources.redhat.com In-Reply-To: References: <20050401.123528.122254594.nemoto@toshiba-tops.co.jp> <20050404.175833.115610647.nemoto@toshiba-tops.co.jp> <1112638226.5320.0.camel@localhost.localdomain> <20050409153120.GA7020@nevyn.them.org> <1113068818.5494.4.camel@localhost.localdomain> Content-Type: text/plain Date: Mon, 11 Apr 2005 21:40:00 -0000 Message-Id: <1113255609.5094.18.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00260.txt.bz2 > > gas/: > 2005-04-11 Maciej W. Rozycki > > * 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 > > * 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