[SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[Oleg Endo]

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

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

[-- Attachment #2: 0001-simsh-check-PFSCRPR-setting-for-fldi0-and-fldi1-insns.patch --]
[-- Type: text/x-patch, Size: 1096 bytes --]

From 3417353c867efd502da6df1e80b9a8bdb0a422f0 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

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

Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[Simon Marchi]

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?

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

Thanks,

Simon

[1] https://0x04.net/~mwk/doc/sh/e602156_sh4.pdf

Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[Oleg Endo]

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

Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[Simon Marchi]

On 3/11/26 2:20 AM, Oleg Endo wrote:
> 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.

Ok, well since we're in "undefined behavior" territory we could argue
that the current sim behavior is fine.  But I think the patch is still
good, traping is a more useful behavior to catch something you don't
want to happen.

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

Good to know, thanks.  We often wonder "does anybody still use some old
architecture or feature X in gdb".

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

I would give it a week for Andrew or Mike to review and approve, but
otherwise I would feel comfortable merging it.

Simon

Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[Oleg Endo]

On Wed, 2026-03-11 at 10:39 -0400, Simon Marchi wrote:
> 
> Ok, well since we're in "undefined behavior" territory we could argue
> that the current sim behavior is fine.  But I think the patch is still
> good, traping is a more useful behavior to catch something you don't
> want to happen.

Yes, the current sim behavior is not wrong per se.  But like you said,
having it trap is more useful for sim's main purpose -- pre-verifying code. 


> > > 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.
> 
> I would give it a week for Andrew or Mike to review and approve, but
> otherwise I would feel comfortable merging it.
> 

Alright.  Last time I've checked I had write access.  I can commit & push it
myself.  Just let me know.

Best regards,
Oleg Endo

Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[Simon Marchi]

On 2026-03-16 21:18, Oleg Endo wrote:
> On Wed, 2026-03-11 at 10:39 -0400, Simon Marchi wrote:
>>
>> Ok, well since we're in "undefined behavior" territory we could argue
>> that the current sim behavior is fine.  But I think the patch is still
>> good, traping is a more useful behavior to catch something you don't
>> want to happen.
> 
> Yes, the current sim behavior is not wrong per se.  But like you said,
> having it trap is more useful for sim's main purpose -- pre-verifying code. 
> 
> 
>>>> 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.
>>
>> I would give it a week for Andrew or Mike to review and approve, but
>> otherwise I would feel comfortable merging it.
>>
> 
> Alright.  Last time I've checked I had write access.  I can commit & push it
> myself.  Just let me know.

Yes, please go ahead.

Simon

Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[Oleg Endo]

On Mon, 2026-03-16 at 21:19 -0400, Simon Marchi wrote:
> 
> On 2026-03-16 21:18, Oleg Endo wrote:
> > On Wed, 2026-03-11 at 10:39 -0400, Simon Marchi wrote:
> > > 
> > > Ok, well since we're in "undefined behavior" territory we could argue
> > > that the current sim behavior is fine.  But I think the patch is still
> > > good, traping is a more useful behavior to catch something you don't
> > > want to happen.
> > 
> > Yes, the current sim behavior is not wrong per se.  But like you said,
> > having it trap is more useful for sim's main purpose -- pre-verifying code. 
> > 
> > 
> > > > > 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.
> > > 
> > > I would give it a week for Andrew or Mike to review and approve, but
> > > otherwise I would feel comfortable merging it.
> > > 
> > 
> > Alright.  Last time I've checked I had write access.  I can commit & push it
> > myself.  Just let me know.
> 
> Yes, please go ahead.
> 
> 

Thanks.  Committed & pushed as 17eb89e3c1cc6098f08e77d257468486a5c04ce4.

Best regards,
Oleg Endo

Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[Oleg Endo]

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

Hi,

On Tue, 2026-03-17 at 13:50 +0900, Oleg Endo wrote:
> 
> On Mon, 2026-03-16 at 21:19 -0400, Simon Marchi wrote:
> > 
> > On 2026-03-16 21:18, Oleg Endo wrote:
> > > On Wed, 2026-03-11 at 10:39 -0400, Simon Marchi wrote:
> > > > 
> > > > Ok, well since we're in "undefined behavior" territory we could argue
> > > > that the current sim behavior is fine.  But I think the patch is still
> > > > good, traping is a more useful behavior to catch something you don't
> > > > want to happen.
> > > 
> > > Yes, the current sim behavior is not wrong per se.  But like you said,
> > > having it trap is more useful for sim's main purpose -- pre-verifying code. 
> > > 
> > > 
> > > > > > 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.
> > > > 
> > > > I would give it a week for Andrew or Mike to review and approve, but
> > > > otherwise I would feel comfortable merging it.
> > > > 
> > > 
> > > Alright.  Last time I've checked I had write access.  I can commit & push it
> > > myself.  Just let me know.
> > 
> > Yes, please go ahead.
> > 
> > 
> 
> Thanks.  Committed & pushed as 17eb89e3c1cc6098f08e77d257468486a5c04ce4.
> 

This is a little late, but better than never.

I've just noticed that running

   make check RUNTESTFLAGS="sh.exp"

in the sim build dir throws the following errors:

FAIL: sh fabs.s (execution)
FAIL: sh fadd.s (execution)
FAIL: sh fcmpeq.s (execution)
FAIL: sh fcmpgt.s (execution)
FAIL: sh fcnvsd.s (execution)
FAIL: sh float.s (execution)
FAIL: sh fmov.s (execution)
FAIL: sh fmul.s (execution)
FAIL: sh fneg.s (execution)
FAIL: sh fsqrt.s (execution)
FAIL: sh fsub.s (execution)
FAIL: sh ftrc.s (execution)

The behavior is correct and as expected.  The test cases need to be adjusted
to match the fli0/fldi1 behavior.  The attached patch fixes this.

OK to commit & push?

Best regards,
Oleg Endo



[-- Attachment #2: 0001-simsh-Fix-test-cases-after-flid0flid1-change-in-17eb89e3c1cc60.patch --]
[-- Type: text/x-patch, Size: 9249 bytes --]

From 121e27614329d3e6df97b030dbc92bf783f6eb11 Mon Sep 17 00:00:00 2001
From: Oleg Endo <olegendo@gcc.gnu.org>
Date: Sun, 2 Aug 2026 22:26:54 +0900
Subject: [PATCH] sim/sh: Fix test cases after flid0/flid1 change in 17eb89e3c1cc60

The previous change in 17eb89e3c1cc60 causes the sh sim fp tests to fail:

FAIL: sh fabs.s (execution)
FAIL: sh fadd.s (execution)
FAIL: sh fcmpeq.s (execution)
FAIL: sh fcmpgt.s (execution)
FAIL: sh fcnvsd.s (execution)
FAIL: sh float.s (execution)
FAIL: sh fmov.s (execution)
FAIL: sh fmul.s (execution)
FAIL: sh fneg.s (execution)
FAIL: sh fsqrt.s (execution)
FAIL: sh fsub.s (execution)
FAIL: sh ftrc.s (execution)

The behavior is correct and as expected.  The test cases need to be adjusted
to match the fli0/fldi1 behavior.
---
 sim/testsuite/sh/fabs.s   | 11 ++++++++++-
 sim/testsuite/sh/fadd.s   |  3 ++-
 sim/testsuite/sh/fcmpeq.s | 11 ++++++++---
 sim/testsuite/sh/fcmpgt.s | 11 ++++++++---
 sim/testsuite/sh/fcnvsd.s |  3 ++-
 sim/testsuite/sh/float.s  |  4 ++--
 sim/testsuite/sh/fmov.s   |  1 +
 sim/testsuite/sh/fmul.s   |  2 +-
 sim/testsuite/sh/fneg.s   | 11 +++++++++--
 sim/testsuite/sh/fsqrt.s  | 13 ++++++++++---
 sim/testsuite/sh/fsub.s   | 17 +++++++++++++++--
 sim/testsuite/sh/ftrc.s   |  7 ++++---
 12 files changed, 72 insertions(+), 22 deletions(-)

diff --git a/sim/testsuite/sh/fabs.s b/sim/testsuite/sh/fabs.s
index 1fb354e..e6b68b5 100644
--- a/sim/testsuite/sh/fabs.s
+++ b/sim/testsuite/sh/fabs.s
@@ -55,40 +55,49 @@ fabs_dreg_b0:
 	# double precision tests.
 	set_grs_a5a5
 	set_fprs_a5a5
-	double_prec
 	# fabs(0.0) = 0.0.
+	single_prec
 	fldi0	fr0
+	double_prec
 	flds	fr0, fpul
 	fcnvsd	fpul, dr0
 	fabs dr0
 	assert_dpreg_i 0 dr0
 
 	# fabs(1.0) = 1.0.
+	single_prec
 	fldi1	fr0
+	double_prec
 	flds	fr0, fpul
 	fcnvsd	fpul, dr0
 	fabs dr0
 	assert_dpreg_i 1 dr0
 
 	# check.
+	single_prec
 	fldi1 fr2
+	double_prec
 	flds	fr2, fpul
 	fcnvsd	fpul, dr2
 	fcmp/eq dr0, dr2
 	bt	.L4
 	fail
 
 .L4:
 	# fabs(-1.0) = 1.0.
+	single_prec
 	fldi1 fr0
+	double_prec
 	fneg fr0
 	flds	fr0, fpul
 	fcnvsd	fpul, dr0
 	fabs dr0
 	assert_dpreg_i 1 dr0
 
 	# check.
+	single_prec
 	fldi1 fr2
+	double_prec
 	flds	fr2, fpul
 	fcnvsd	fpul, dr2
 	fcmp/eq dr0, dr2
diff --git a/sim/testsuite/sh/fadd.s b/sim/testsuite/sh/fadd.s
index 72431f0..5895e36 100644
--- a/sim/testsuite/sh/fadd.s
+++ b/sim/testsuite/sh/fadd.s
@@ -44,9 +44,10 @@ fadd_freg_freg_b0:
 fadd_dreg_dreg_b0:
 	set_grs_a5a5
 	set_fprs_a5a5
-	double_prec
+	single_prec
 	fldi1	fr0
 	fldi1	fr2
+	double_prec
 	flds	fr0, fpul
 	fcnvsd	fpul, dr0
 	flds	fr2, fpul
diff --git a/sim/testsuite/sh/fcmpeq.s b/sim/testsuite/sh/fcmpeq.s
index 9c0ef57..5bebae2 100644
--- a/sim/testsuite/sh/fcmpeq.s
+++ b/sim/testsuite/sh/fcmpeq.s
@@ -59,39 +59,44 @@ fcmpeq_double:
 	# 1.0 == 1.0
 	set_grs_a5a5
 	set_fprs_a5a5
-	double_prec
+	single_prec
 	fldi1 fr0
 	fldi1 fr2
+	double_prec
 	_s2d fr0, dr0
 	_s2d fr2, dr2
 	fcmp/eq dr0, dr2
 	bt	.L10
 	fail
 .L10:
 	# 0.0 != 1.0
+	single_prec
 	fldi0 fr0
 	fldi1 fr2
+	double_prec
 	_s2d fr0, dr0
 	_s2d fr2, dr2
 	fcmp/eq dr0, dr2
 	bf	.L11
 	fail
 .L11:
 	# 1.0 != 0.0
+	single_prec
 	fldi1 fr0
 	fldi0 fr2
+	double_prec
 	_s2d fr0, dr0
 	_s2d fr2, dr2
 	fcmp/eq dr0, dr2
 	bf	.L12
 	fail
 .L12:
 	# 2.0 != 1.0
-	fldi1 fr0
 	single_prec
+	fldi1 fr0
 	fadd fr0, fr0
-	double_prec
 	fldi1 fr2
+	double_prec
 	_s2d fr0, dr0
 	_s2d fr2, dr2
 	fcmp/eq dr0, dr2
diff --git a/sim/testsuite/sh/fcmpgt.s b/sim/testsuite/sh/fcmpgt.s
index c6945ba..d631f94 100644
--- a/sim/testsuite/sh/fcmpgt.s
+++ b/sim/testsuite/sh/fcmpgt.s
@@ -59,40 +59,45 @@ fcmpgt_double:
 	# double precision tests.
 	set_grs_a5a5
 	set_fprs_a5a5
-	double_prec
 	# 1.0 !> 1.0.
+	single_prec
 	fldi1	fr0
 	fldi1	fr2
+	double_prec
 	_s2d	fr0, dr0
 	_s2d	fr2, dr2
 	fcmp/gt	dr0, dr2
 	bf	.L10
 	fail
 .L10:
 	# 0.0 !> 1.0.
+	single_prec
 	fldi0	fr0
 	fldi1	fr2
+	double_prec
 	_s2d	fr0, dr0
 	_s2d	fr2, dr2
 	fcmp/gt	dr0, dr2
 	bt	.L11
 	fail
 .L11:
 	# 1.0 > 0.0.
+	single_prec
 	fldi1	fr0
 	fldi0	fr2
+	double_prec
 	_s2d	fr0, dr0
 	_s2d	fr2, dr2
 	fcmp/gt	dr0, dr2
 	bf	.L12
 	fail
 .L12:
 	# 2.0 > 1.0.
-	fldi1	fr0
 	single_prec
+	fldi1	fr0
 	fadd	fr0, fr0
-	double_prec
 	fldi1	fr2
+	double_prec
 	_s2d	fr0, dr0
 	_s2d	fr2, dr2
 	fcmp/gt	dr0, dr2
diff --git a/sim/testsuite/sh/fcnvsd.s b/sim/testsuite/sh/fcnvsd.s
index 6592540..3c56236 100644
--- a/sim/testsuite/sh/fcnvsd.s
+++ b/sim/testsuite/sh/fcnvsd.s
@@ -7,8 +7,9 @@
 	start
 	set_grs_a5a5
 	set_fprs_a5a5
-	double_prec
+	single_prec
 	fldi1	fr0
+	double_prec
 	flds	fr0, fpul
 	fcnvsd	fpul, dr2
 	assert_dpreg_i	1, dr2
diff --git a/sim/testsuite/sh/float.s b/sim/testsuite/sh/float.s
index e5a3bc6..3e88640 100644
--- a/sim/testsuite/sh/float.s
+++ b/sim/testsuite/sh/float.s
@@ -81,9 +81,9 @@ double_pos:
 	float	fpul, dr4
 
 	# check the result.
+	single_prec
 	fldi1	fr0
 	fldi1	fr1
-	single_prec
 	fadd	fr0, fr1
 	fadd	fr0, fr1
 	double_prec
@@ -100,9 +100,9 @@ double_neg:
 	float	fpul, dr4
 
 	# check the result.
+	single_prec
 	fldi1	fr0
 	fldi1	fr1
-	single_prec
 	fadd	fr0, fr1
 	fadd	fr0, fr1
 	fneg	fr1
diff --git a/sim/testsuite/sh/fmov.s b/sim/testsuite/sh/fmov.s
index 29c51b5..d08fc4d 100644
--- a/sim/testsuite/sh/fmov.s
+++ b/sim/testsuite/sh/fmov.s
@@ -5,6 +5,7 @@
 	.include "testutils.inc"
 
 	.macro init
+	single_prec
 	fldi0	fr0
 	fldi1	fr1
 	fldi1	fr2
diff --git a/sim/testsuite/sh/fmul.s b/sim/testsuite/sh/fmul.s
index 81a2545..4e140b9 100644
--- a/sim/testsuite/sh/fmul.s
+++ b/sim/testsuite/sh/fmul.s
@@ -59,10 +59,10 @@ fmul_single:
 	test_fpr_a5a5	fr15
 
 	.macro dinit
+	single_prec
 	fldi0 fr0
 	fldi1 fr2
 	fldi1 fr4
-	single_prec
 	fadd fr4, fr4
 	double_prec
 	_s2d fr0, dr0
diff --git a/sim/testsuite/sh/fneg.s b/sim/testsuite/sh/fneg.s
index dd5fe5d..1ec56d3 100644
--- a/sim/testsuite/sh/fneg.s
+++ b/sim/testsuite/sh/fneg.s
@@ -56,35 +56,42 @@ fneg_single:
 fneg_double:
 	set_grs_a5a5
 	set_fprs_a5a5
-	double_prec
 	# neg(0.0) = 0.0.
+	single_prec
 	fldi0	fr0
 	fldi0	fr2
+	double_prec
 	_s2d	fr0, dr0
 	_s2d	fr2, dr2
 	fneg	dr0
 	fcmp/eq	dr0, dr2
 	bt	.L10
 	fail
 .L10:
 	# neg(1.0) = fsub(0,1)
+	single_prec
 	fldi1	fr0
+	double_prec
 	_s2d	fr0, dr0
 	fneg	dr0
+	single_prec
 	fldi0	fr2
 	fldi1	fr3
-	single_prec
 	fsub	fr3, fr2
 	double_prec
 	_s2d	fr2, dr2
 	fcmp/eq dr0, dr2
 	bt	.L11
 	fail
 .L11:
 	# neg(neg(1.0)) = 1.0.
+	single_prec
 	fldi1	fr0
+	double_prec
 	_s2d	fr0, dr0
+	single_prec
 	fldi1	fr2
+	double_prec
 	_s2d	fr2, dr2
 	fneg	dr2
 	fneg	dr2
diff --git a/sim/testsuite/sh/fsqrt.s b/sim/testsuite/sh/fsqrt.s
index cb61bcf..5c29c30 100644
--- a/sim/testsuite/sh/fsqrt.s
+++ b/sim/testsuite/sh/fsqrt.s
@@ -57,42 +57,49 @@ fsqrt_single:
 	test_fpr_a5a5	fr15
 
 fsqrt_double:
-	double_prec
 	set_grs_a5a5
 	set_fprs_a5a5
 	# sqrt(0.0) = 0.0.
+	single_prec
 	fldi0	fr0
+	double_prec
 	_s2d	fr0, dr0
 	fsqrt	dr0
+	single_prec
 	fldi0	fr2
+	double_prec
 	_s2d	fr2, dr2
 	fcmp/eq	dr0, dr2
 	bt	.L10
 	fail
 .L10:
 	# sqrt(1.0) = 1.0.
+	single_prec
 	fldi1	fr0
+	double_prec
 	_s2d	fr0, dr0
 	fsqrt	dr0
+	single_prec
 	fldi1	fr2
+	double_prec
 	_s2d	fr2, dr2
 	fcmp/eq	dr0, dr2
 	bt	.L11
 	fail
 .L11:
 	# sqrt(4.0) = 2.0.
+	single_prec
 	fldi1	fr0
 	# Double it.
-	single_prec
 	fadd	fr0, fr0
 	# Double it again.
 	fadd	fr0, fr0
 	double_prec
 	_s2d	fr0, dr0
 	fsqrt	dr0
+	single_prec
 	fldi1	fr2
 	# Double it.
-	single_prec
 	fadd	fr2, fr2
 	double_prec
 	_s2d	fr2, dr2
diff --git a/sim/testsuite/sh/fsub.s b/sim/testsuite/sh/fsub.s
index dfe9172..1d13a63 100644
--- a/sim/testsuite/sh/fsub.s
+++ b/sim/testsuite/sh/fsub.s
@@ -66,51 +66,64 @@ fsub_single:
 fsub_double:
 	set_grs_a5a5
 	set_fprs_a5a5
-	double_prec
 	# 0.0 - 0.0 = 0.0.
+	single_prec
 	fldi0	fr0
 	fldi0	fr2
+	double_prec
 	_s2d	fr0, dr0
 	_s2d	fr2, dr2
 	fsub	dr0, dr2
+	single_prec
 	fldi0	fr4
+	double_prec
 	_s2d	fr4, dr4
 	fcmp/eq	dr2, dr4
 	bt	.L10
 	fail
 .L10:	
 	# 1.0 - 0.0 = 1.0.
+	single_prec
 	fldi0	fr0
 	fldi1	fr2
+	double_prec
 	_s2d	fr0, dr0
 	_s2d	fr2, dr2
 	fsub	dr0, dr2
+	single_prec
 	fldi1	fr4
+	double_prec
 	_s2d	fr4, dr4
 	fcmp/eq	dr2, dr4
 	bt	.L11
 	fail
 .L11:	
 	# 1.0 - 1.0 = 0.0.
+	single_prec
 	fldi1	fr0
 	fldi1	fr2
+	double_prec
 	_s2d	fr0, dr0
 	_s2d	fr2, dr2
 	fsub	dr0, dr2
+	single_prec
 	fldi0	fr4
+	double_prec
 	_s2d	fr4, dr4
 	fcmp/eq	dr2, dr4
 	bt	.L12
 	fail
 .L12:	
 	# 0.0 - 1.0 = -1.0.
+	single_prec
 	fldi1	fr0
 	fldi0	fr2
+	double_prec
 	_s2d	fr0, dr0
 	_s2d	fr2, dr2
 	fsub	dr0, dr2
-	fldi1	fr4
 	single_prec
+	fldi1	fr4
 	fneg	fr4
 	double_prec
 	_s2d	fr4, dr4
diff --git a/sim/testsuite/sh/ftrc.s b/sim/testsuite/sh/ftrc.s
index 25e33be..ac11600 100644
--- a/sim/testsuite/sh/ftrc.s
+++ b/sim/testsuite/sh/ftrc.s
@@ -59,9 +59,10 @@ ftrc_single:
 	fail
 
 ftrc_double:
-	double_prec
 	# ftrc(0.0) = 0.
+	single_prec
 	fldi0	fr0
+	double_prec
 	_s2d	fr0, dr0
 	ftrc	dr0, fpul
 	# check results.
@@ -72,11 +73,11 @@ ftrc_double:
 	fail
 .L10:
 	# ftrc(1.5) = 1.
+	single_prec
 	fldi1	fr0
 	fldi1	fr2
 	fldi1	fr4
 	# double it.
-	single_prec
 	fadd	fr4, fr4
 	# form 0.5.
 	fdiv	fr4, fr2
@@ -97,11 +98,11 @@ ftrc_double:
 	fail
 .L11:
 	# ftrc(-1.5) = -1.
+	single_prec
 	fldi1	fr0
 	fneg	fr0
 	fldi1	fr2
 	fldi1	fr4
-	single_prec
 	# double it.
 	fadd	fr4, fr4
 	# form the fraction.
--
libgit2 1.9.0

Ping^1 Re: [SH] Check FPSCR.PR for fldi0, fldi1 insns in simulator

[Oleg Endo]

Ping

On Sun, 2026-08-02 at 22:42 +0900, Oleg Endo wrote:
> Hi,
> 
> On Tue, 2026-03-17 at 13:50 +0900, Oleg Endo wrote:
> > 
> > On Mon, 2026-03-16 at 21:19 -0400, Simon Marchi wrote:
> > > 
> > > On 2026-03-16 21:18, Oleg Endo wrote:
> > > > On Wed, 2026-03-11 at 10:39 -0400, Simon Marchi wrote:
> > > > > 
> > > > > Ok, well since we're in "undefined behavior" territory we could argue
> > > > > that the current sim behavior is fine.  But I think the patch is still
> > > > > good, traping is a more useful behavior to catch something you don't
> > > > > want to happen.
> > > > 
> > > > Yes, the current sim behavior is not wrong per se.  But like you said,
> > > > having it trap is more useful for sim's main purpose -- pre-verifying code. 
> > > > 
> > > > 
> > > > > > > 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.
> > > > > 
> > > > > I would give it a week for Andrew or Mike to review and approve, but
> > > > > otherwise I would feel comfortable merging it.
> > > > > 
> > > > 
> > > > Alright.  Last time I've checked I had write access.  I can commit & push it
> > > > myself.  Just let me know.
> > > 
> > > Yes, please go ahead.
> > > 
> > > 
> > 
> > Thanks.  Committed & pushed as 17eb89e3c1cc6098f08e77d257468486a5c04ce4.
> > 
> 
> This is a little late, but better than never.
> 
> I've just noticed that running
> 
>    make check RUNTESTFLAGS="sh.exp"
> 
> in the sim build dir throws the following errors:
> 
> FAIL: sh fabs.s (execution)
> FAIL: sh fadd.s (execution)
> FAIL: sh fcmpeq.s (execution)
> FAIL: sh fcmpgt.s (execution)
> FAIL: sh fcnvsd.s (execution)
> FAIL: sh float.s (execution)
> FAIL: sh fmov.s (execution)
> FAIL: sh fmul.s (execution)
> FAIL: sh fneg.s (execution)
> FAIL: sh fsqrt.s (execution)
> FAIL: sh fsub.s (execution)
> FAIL: sh ftrc.s (execution)
> 
> The behavior is correct and as expected.  The test cases need to be adjusted
> to match the fli0/fldi1 behavior.  The attached patch fixes this.
> 
> OK to commit & push?
> 
> Best regards,
> Oleg Endo
> 
>