From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932359AbcDSOoR (ORCPT ); Tue, 19 Apr 2016 10:44:17 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:41019 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754777AbcDSOns convert rfc822-to-8bit (ORCPT ); Tue, 19 Apr 2016 10:43:48 -0400 From: Matthew Fortune To: Maciej Rozycki , Ralf Baechle CC: "Maciej W. Rozycki" , kbuild test robot , Paul Burton , "kbuild-all@01.org" , "linux-kernel@vger.kernel.org" Subject: RE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits Thread-Topic: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits Thread-Index: AQHRmZ2CB6Zh+fDldEy+jhEmdeH4OJ+QX/8AgAD9vIA= Date: Tue, 19 Apr 2016 14:43:45 +0000 Message-ID: <6D39441BF12EF246A7ABCE6654B023537E3DB822@hhmail02.hh.imgtec.org> References: <201604170836.kTyP1sCY%fengguang.wu@intel.com> <20160417011926.GA4014@linux-mips.org> <20160418133449.GB24051@linux-mips.org> <20160418155440.GC24051@linux-mips.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.152.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Maciej Rozycki writes: > On Mon, 18 Apr 2016, Maciej W. Rozycki wrote: > > > The thing is that to match some software's (such as ours) > > requirements an ISA override -- as a side effect -- relaxes ABI > > restrictions on certain operations. E.g. the DLI macro and its 64-bit > > immediate argument are not valid in the o32 ABI. When no actual > > override happens, such as with `-march=r4600' which already implies > > `mips3' for the ISA, the side effect is lost: > > > > /* The use of .set [arch|cpu]= historically 'fixes' the width of gp > and fp > > registers based on what is supported by the arch/cpu. */ > > if (mips_opts.isa != prev_isa) > > It's worse yet actually, as operations such as `.set pop' and `.set > mips0' may not restore the ABI restrictions, possibly leading to wrong > code generation elsewhere, generally in handcoded assembly only. This > can be illustrated with a program like: > > .set push > .set mips3 > dli $2, 0x9000000080000000 > .set mips0 > dli $2, 0x9000000080000000 > .set mips3 > .set pop > dli $2, 0x9000000080000000 > > -- try building it with `-mips3' and `-mips4' to see how it fails or > succeeds to assemble all the three DLI macros respectively, where it is > supposed to succeed with the first macro only and fail with the other > two in both cases. > > I have a fix in the works and to have it integrated upstream I just > need to accompany it with suitable cases -- like the fragment above -- > for the GAS testsuite. I'll send an update when it's ready. I do not think the change in behaviour was intentional. I think it came about because I separated the handling of an explicit .set mips* directive from the implicit setting of gp/fp. I needed to ensure that gp/fp was only updated when there was a .set mips* directive but missed the case where you have an explicit directive that matches the current mips* setting. The conditional nature of updating 'fp' is however very much intentional in that if a user enters 'fpxx' mode where fp==0 then the implicit update of fp does not happen. This is OK as this behaviour only triggers when using the newly added fpxx feature anyway. I am generally not in favour of these implicit side-effect behaviours as they are only useful in niche cases and are somewhat non-intuitive but we are stuck with them because of history. It would be possible to write code that does not need them by explicitly using the .set gp or .set fp options. There is little we can do about that given historic precedent though. Instead code that does not want the implicit behaviour has to explicitly do things like: .set mips3 .set gp=default .set fp=default Matthew