From: "Maciej W. Rozycki" <macro@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>,
Matthew Fortune <Matthew.Fortune@imgtec.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
kbuild test robot <fengguang.wu@intel.com>,
Paul Burton <paul.burton@imgtec.com>, <kbuild-all@01.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits
Date: Mon, 18 Apr 2016 19:09:42 +0100 [thread overview]
Message-ID: <alpine.DEB.2.00.1604181724160.21846@tp.orcam.me.uk> (raw)
In-Reply-To: <20160418155440.GC24051@linux-mips.org>
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
next prev parent reply other threads:[~2016-04-18 18:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-17 0:20 {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits kbuild test robot
2016-04-17 1:19 ` Ralf Baechle
2016-04-17 14:43 ` Maciej W. Rozycki
2016-04-18 13:34 ` Ralf Baechle
2016-04-18 14:25 ` Maciej W. Rozycki
2016-04-18 15:54 ` Ralf Baechle
2016-04-18 18:09 ` Maciej W. Rozycki [this message]
2016-04-19 0:25 ` Maciej W. Rozycki
2016-04-19 14:43 ` Matthew Fortune
2016-04-22 1:00 ` Maciej W. Rozycki
-- strict thread matches above, loose matches on Subject: below --
2016-06-25 23:37 kbuild test robot
2016-06-11 23:37 kbuild test robot
2016-03-12 23:00 kbuild test robot
2016-03-05 23:09 kbuild test robot
2016-02-27 23:05 kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1604181724160.21846@tp.orcam.me.uk \
--to=macro@imgtec.com \
--cc=Matthew.Fortune@imgtec.com \
--cc=fengguang.wu@intel.com \
--cc=kbuild-all@01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=paul.burton@imgtec.com \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).