{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

Hi,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   da2f6aba4a21f8da3331e5251a117c52764da579
commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC
date:   1 year ago
config: mips-jz4740 (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout de361e8bb9f666235d44ae9770238718be4f0483
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

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

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 17012 bytes --]

{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

Hi,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   45b00c94be33db5d00595046663163ce55cbbfb9
commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC
date:   12 months ago
config: mips-jz4740 (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout de361e8bb9f666235d44ae9770238718be4f0483
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

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

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 17012 bytes --]

{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   306a63bee192859ebd32c7328c7766636d882d8f
commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC
date:   10 months ago
config: mips-jz4740 (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout de361e8bb9f666235d44ae9770238718be4f0483
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

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

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 17008 bytes --]

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[Ralf Baechle]

On Sun, Apr 17, 2016 at 08:20:38AM +0800, kbuild test robot wrote:

> FYI, the error/warning still remains.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   306a63bee192859ebd32c7328c7766636d882d8f
> commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC
> date:   10 months ago
> config: mips-jz4740 (attached as .config)
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout de361e8bb9f666235d44ae9770238718be4f0483
>         # save the attached .config to linux build tree
>         make.cross ARCH=mips 
> 
> 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?

  Ralf

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[Maciej W. Rozycki]

Ralf,

> > 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.

  Maciej

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[Ralf Baechle]

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

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[Maciej W. Rozycki]

On Mon, 18 Apr 2016, Ralf Baechle wrote:

> 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"

 That does not help me, I'm afraid, I can't trigger the issue with this 
piece of code alone.  It may be caused by a particular combination of GAS
command line options and `.set' directives.

 Since you can reproduce it, can you please send me the offending .s file 
(`make arch/mips/mm/sc-ip22.s') and the GAS invocation line used?  GCC 
will print the latter along all kinds of diagnostic stuff if -v is passed 
to an invocation involving assembly (e.g. `make V=1 CFLAGS_sc-ip22.o=-v 
arch/mips/mm/sc-ip22.o').  You can send me the whole diagnostics, I'll 
filter what I need.

 I think it'll be the most efficient way to move forward; otherwise I may 
keep missing the issue.

 Thanks,

  Maciej

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[Ralf Baechle]

On Mon, Apr 18, 2016 at 03:25:56PM +0100, Maciej W. Rozycki wrote:

> On Mon, 18 Apr 2016, Ralf Baechle wrote:
> 
> > 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"
> 
>  That does not help me, I'm afraid, I can't trigger the issue with this 
> piece of code alone.  It may be caused by a particular combination of GAS
> command line options and `.set' directives.
> 
>  Since you can reproduce it, can you please send me the offending .s file 
> (`make arch/mips/mm/sc-ip22.s') and the GAS invocation line used?  GCC 
> will print the latter along all kinds of diagnostic stuff if -v is passed 
> to an invocation involving assembly (e.g. `make V=1 CFLAGS_sc-ip22.o=-v 
> arch/mips/mm/sc-ip22.o').  You can send me the whole diagnostics, I'll 
> filter what I need.
> 
>  I think it'll be the most efficient way to move forward; otherwise I may 
> keep missing the issue.

I extracted a rather simple test case:

$ echo >> testcase .s << EOF
        .set    mips3
        dli     $2, 0x9000000080000000
EOF
$ mips-linux-as -mips3 -march=r4600 -o testcase.o testcase.s
testcase.s: Assembler messages:
testcase.s:2: Error: number (0x9000000080000000) larger than 32 bits
$ mips-linux-as -mips4 -march=vr5000 -o testcase.o testcase.s
$

I can trigger the error message with vanilla 2.25 and 2.26 but not 2.24.

  Ralf

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[Maciej W. Rozycki]

On Mon, 18 Apr 2016, Ralf Baechle wrote:

> I extracted a rather simple test case:
> 
> $ echo >> testcase .s << EOF
>         .set    mips3
>         dli     $2, 0x9000000080000000
> EOF
> $ mips-linux-as -mips3 -march=r4600 -o testcase.o testcase.s
> testcase.s: Assembler messages:
> testcase.s:2: Error: number (0x9000000080000000) larger than 32 bits
> $ mips-linux-as -mips4 -march=vr5000 -o testcase.o testcase.s
> $

 Ah, and if you use `.set mips4' instead, then the symptoms reverse.

 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)

> I can trigger the error message with vanilla 2.25 and 2.26 but not 2.24.

 The regression has come with:

commit 919731affbef19fcad8dddb0a595bb05755cb345
Author: mfortune <matthew.fortune@imgtec.com>
Date:   Tue May 20 13:28:20 2014 +0100

    Add MIPS .module directive

-- previously the side effect was unconditional, even if no ISA change 
resulted.

 Matthew, this functional change was not mentioned in the review: 
<https://sourceware.org/ml/binutils/2014-05/msg00179.html> -- what was the 
rationale behind it?  Do you expect any issues if we revert to old 
semantics?

  Maciej

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[Maciej W. Rozycki]

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.

  Maciej

RE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[Matthew Fortune]

Maciej Rozycki <Maciej.Rozycki@imgtec.com> 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

RE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[Maciej W. Rozycki]

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 <macro@imgtec.com>
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

{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   03c668a93187fe7fba9464f96fbe7c22eebd9897
commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC
date:   9 months ago
config: mips-jz4740 (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout de361e8bb9f666235d44ae9770238718be4f0483
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

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

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 17008 bytes --]

{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   a7c9b603cf2371edacb054abc35597e810c1e5fd
commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC
date:   9 months ago
config: mips-jz4740 (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout de361e8bb9f666235d44ae9770238718be4f0483
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

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

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 17008 bytes --]

{standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   691429e13dfaf5b0994b07cc166db41bd608ee3d
commit: de361e8bb9f666235d44ae9770238718be4f0483 MIPS: JZ4740: introduce CONFIG_MACH_INGENIC
date:   8 months ago
config: mips-jz4740 (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout de361e8bb9f666235d44ae9770238718be4f0483
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

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

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 17008 bytes --]