Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752843AbcDVBBB (ORCPT ); Thu, 21 Apr 2016 21:01:01 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:44145 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752020AbcDVBBA (ORCPT ); Thu, 21 Apr 2016 21:01:00 -0400 Date: Fri, 22 Apr 2016 02:00:47 +0100 From: "Maciej W. Rozycki" To: Matthew Fortune CC: Ralf Baechle , "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 In-Reply-To: <6D39441BF12EF246A7ABCE6654B023537E3DB822@hhmail02.hh.imgtec.org> Message-ID: References: <201604170836.kTyP1sCY%fengguang.wu@intel.com> <20160417011926.GA4014@linux-mips.org> <20160418133449.GB24051@linux-mips.org> <20160418155440.GC24051@linux-mips.org> <6D39441BF12EF246A7ABCE6654B023537E3DB822@hhmail02.hh.imgtec.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [10.20.78.30] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3075 Lines: 69 On Tue, 19 Apr 2016, Matthew Fortune wrote: > > 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. I had thought it might have been intentional before I realised the problem also affected ISA restoration, at which point I concluded it had been simply an oversight. While looking at it I've noticed we support somewhat questionable settings with the related `.module' directive, such as: .module at=$k0 .module nomove They have no command-line counterparts, so there's really no difference between having a `.module' or a corresponding `.set' directive at the top of a source file. There's no `.module' support for the similar `nomacro' or `noreorder' settings though. Was there a hidden motivation that you had to make such an arrangement? > 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. Sure, my only concern has been the inconsistency between the case where the ISA is actually switched and one where it remains the same after a `.set' pseudo-op. > 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 Well, historically we had very little control and old code adapted to it. Even the `.set gp=' and `.set fp=' directives are relatively recent in the history of the MIPS port. So I agree -- had we had control we have today back when the MIPS port started, this would have been better handled with these more finegrained knobs. Before NewABI support was added even using e.g. `-mips3' on the command line made full 64-bit registers available. I have fixed the bug upstream now: commit 22522f880a8e17a17c4f195796ec89caece7652b Author: Maciej W. Rozycki Date: Fri Apr 22 01:04:52 2016 +0100 MIPS/GAS: Fix an ISA override not lifting ABI restrictions and included suitable test cases with the fix. The lack of testsuite coverage here is what let this bug remain unnoticed. Maciej