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