From: Oleg Endo <olegendo1024@gmail.com>
To: Simon Marchi <simark@simark.ca>, gdb-patches@sourceware.org
Subject: Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator
Date: Wed, 11 Mar 2026 15:20:27 +0900 [thread overview]
Message-ID: <af159442220bc3c1e3ce634a2ee685c46ff6f691.camel@gmail.com> (raw)
In-Reply-To: <6eb50919-75d8-4725-9afa-e241e4cabab6@simark.ca>
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
On Wed, 2026-03-11 at 00:27 -0400, Simon Marchi wrote:
>
> On 2026-03-10 23:02, Oleg Endo wrote:
> > Hi,
> >
> > On SH variants with double-precision FPU the insns fli0 and flid1 require
> > that FPSCR.PR must be set to 0, i.e. single-precision mode. The attached
> > patch fixes that.
> >
> > OK to apply?
> >
> > Best regards,
> > Oleg Endo
>
> I looked for an ISA manual [1] and checked it for fun. For the FLID0,
> it says:
>
> When FPSCR.PR = 0, this instruction loads floating-point 0.0 (0x00000000) into FRn.
>
> Curiously, it does not say what happens if `FPSCR.PR = 1`. However,
> the description for FPSCR.PR says:
>
> PR: Precision mode
> PR = 0: Floating-point instructions are executed as single-precision operations.
> PR = 1: Floating-point instructions are executed as double-precision operations (the result of
> instructions for which double-precision is not supported is undefined).
>
> I guess that FLID0 and FLID1 fall into that "is undefined" category?
> Do you know what the real hardware does in this case?
I have not checked what exactly happens on real hardware. I have checked a
few ISA manuals (Renesas, ST). The instruction descriptions doesn't say
that FLDI0 / FLID1 raises an exception (when in the wrong mode). So I guess
it will produce garbage quietly. Maybe some silicon implementations have
actually an undocumented but well defined behavior.
QEMU traps in this case. We found this while chasing an GCC bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182
I find using sh-sim for compiler testing quite useful. Hence this patch.
>
> The patch LGTM, but I am not a maintainer of the sim, so:
>
> Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
>
> One note, please put the relevant information (the body of your email)
> into the commit log itself).
Yeah, sure I can expand the comment of the commit. Updated patch/commit
attached.
Best regards,
Oleg Endo
[-- Attachment #2: 0002-simsh-check-PFSCRPR-setting-for-fldi0-and-fldi1-insns.patch --]
[-- Type: text/x-patch, Size: 1330 bytes --]
From dcda716308837151a22b765381d0003cc4b9723f Mon Sep 17 00:00:00 2001
From: Oleg Endo <olegendo@gcc.gnu.org>
Date: Wed, 11 Mar 2026 11:55:20 +0900
Subject: [PATCH] sim/sh: check PFSCR.PR setting for fldi0 and fldi1 insns
On SH variants with double-precision FPU the insns fli0 and flid1 are only
defined when FPSCR.PR = 0. The hardware does not necessarily trap but might
quietly load undefined values. However, qemu traps in that case, so do the
same.
---
sim/sh/gencode.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/sim/sh/gencode.c b/sim/sh/gencode.c
index 42009fc..9c882d2 100644
--- a/sim/sh/gencode.c
+++ b/sim/sh/gencode.c
@@ -644,18 +644,22 @@ static op tab[] =
/* sh2e */
{ "", "", "fldi0 <FREG_N>", "1111nnnn10001101",
{
- "SET_FR (n, (float) 0.0);",
- "/* FIXME: check for DP and (n & 1) == 0? */",
+ "if (FPSCR_PR)",
+ " RAISE_EXCEPTION (SIGILL);",
+ "else",
+ " SET_FR (n, (float) 0.0);",
},
},
/* sh2e */
{ "", "", "fldi1 <FREG_N>", "1111nnnn10011101",
{
- "SET_FR (n, (float) 1.0);",
- "/* FIXME: check for DP and (n & 1) == 0? */",
+ "if (FPSCR_PR)",
+ " RAISE_EXCEPTION (SIGILL);",
+ "else",
+ " SET_FR (n, (float) 1.0);",
},
},
/* sh2e */
--
libgit2 1.9.1
next prev parent reply other threads:[~2026-03-11 6:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 3:02 Oleg Endo
2026-03-11 4:27 ` Simon Marchi
2026-03-11 6:20 ` Oleg Endo [this message]
2026-03-11 14:39 ` Simon Marchi
2026-03-17 1:18 ` Oleg Endo
2026-03-17 1:19 ` Simon Marchi
2026-03-17 4:50 ` Oleg Endo
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=af159442220bc3c1e3ce634a2ee685c46ff6f691.camel@gmail.com \
--to=olegendo1024@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/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