[Converted from Gnats 1258] Hi, Attached is a preliminary patch to fix cmp.w. The following testcase, derived from gcc.c-torture/execute/20020307-1.c, fails. .h8300h .section .text .align 1 .global _main _main: sub.l er0,er0 cmp.w #0x8000,r0 bls .L1 jsr @_abort L1: jsr @_exit .end This is equivalent to if ((unsigned short) 0x8000 >= (unsigned short) 0) exit (); else abort (); Inside the simulator, 0x8000 is somehow sign-extended to 0xffff8000, and cmp.w computes the difference like so. 0 - 0xffff8000 = 0x00008000 This result won't set the carry flag, so bls jumps in the wrong way. I am trying to track down where this strange sign extension occurs, but I thought it may be a good idea to share the problem early. Any thought? Kazu Hirata 2003-06-24 Kazu Hirata <kazu@cs.umass.edu> * compile.c (sim_resume): Mask the upper half of operands when simulating cmp.w. Index: compile.c =================================================================== RCS file: /cvs/src/src/sim/h8300/compile.c,v retrieving revision 1.31 diff -u -r1.31 compile.c --- compile.c 19 Jun 2003 02:14:14 -0000 1.31 +++ compile.c 24 Jun 2003 14:29:51 -0000 @@ -2355,6 +2355,8 @@ goto end; if (fetch (sd, &code->src, &ea)) goto end; + rd &= 0xffff; + ea &= 0xffff; ea = -ea; res = rd + ea; goto just_flags_alu16; Release: unknown
patch seems fine, but i'm not an h8/300 expert, and we don't seem to have active h8/300 maintainers. so i guess send the patch to the mailing list ?
I'm pretty sure Michael fixed this eons ago. Most likely: commit 0f42aa719da7ba1e3fa6d093f3ea8cda2c25b3f9 Author: Michael Snyder <msnyder@vmware.com> Date: Fri Jul 18 00:08:23 2003 +0000 2003-07-17 Michael Snyder <msnyder@redhat.com> * compile.c (decode): IMM16 is always zero-extended.
sounds great to me :)