From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752714AbcDRNe5 (ORCPT ); Mon, 18 Apr 2016 09:34:57 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:54836 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751879AbcDRNez (ORCPT ); Mon, 18 Apr 2016 09:34:55 -0400 Date: Mon, 18 Apr 2016 15:34:49 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: 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 Message-ID: <20160418133449.GB24051@linux-mips.org> References: <201604170836.kTyP1sCY%fengguang.wu@intel.com> <20160417011926.GA4014@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 17, 2016 at 03:43:49PM +0100, Maciej W. Rozycki wrote: > > > All errors (new ones prefixed by >>): > > > > > > {standard input}: Assembler messages: > > > >> {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits > > > {standard input}:161: Error: number (0x9000000080000000) larger than 32 bits > > > > This is a toolchain issue afaik which I believe is the same I was seeing > > a while ago on Imaginations buildbot. There it has gone away presumably > > after a toolchain upgrade. Maciej, do you recall which versions were > > affected? > > I've been wondering about these errors too as I have never come across > them myself. So I have no idea what's causing them and I can't really > help other than maybe running `git bisect' on binutils sometime. Or is > there a way to get the version of GAS involved? -- `as --version' will do. > I could see if I could build it and reproduce the problem to see what's > causing it. Also seeing the offending .s file could help too, i.e. > knowing what the context is here. I tried to reproduce the issue with stock FSF GCC 5.2.0 and binutils 2.24, 2.25 and 2.26 and the commit ID and .config from this thread, no luck. The old case btw, affects ip22 with a random_config: CC arch/mips/mm/sc-ip22.o {standard input}: Assembler messages: {standard input}:137: Error: number (0x9000000080000000) larger than 32 bits {standard input}:162: Error: number (0x9000000080000000) larger than 32 bits scripts/Makefile.build:258: recipe for target 'arch/mips/mm/sc-ip22.o' failed make[2]: *** [arch/mips/mm/sc-ip22.o] Error 1 scripts/Makefile.build:403: recipe for target 'arch/mips/mm' failed make[1]: *** [arch/mips/mm] Error 2 Makefile:947: recipe for target 'arch/mips' failed make: *** [arch/mips] Error 2 and I was able to reproduce it with binutils 2.26 and commit c517d838eb7d07bbe9507871fab3931deccff539 ("Linux 4.0-rc1"). The code in question looks like: static inline void indy_sc_wipe(unsigned long first, unsigned long last) { unsigned long tmp; __asm__ __volatile__( ".set\tpush\t\t\t# indy_sc_wipe\n\t" ".set\tnoreorder\n\t" ".set\tmips3\n\t" ".set\tnoat\n\t" "mfc0\t%2, $12\n\t" "li\t$1, 0x80\t\t\t# Go 64 bit\n\t" "mtc0\t$1, $12\n\t" "dli\t$1, 0x9000000080000000\n\t" [...] The same commit, same toolchain with ip22_defconfig builds just fine. Seems the difference is CONFIG_CPU_R4X00 vs. CONFIG_CPU_R5000. Not sure why that would make a difference. Ralf