[Bug 1918026] Re: RISCV64 32-bit AMOs incorrectly simulated

[Richard Henderson]

Not as simple as _tl vs _i32.  That suffix should be taking
care of the sign-extension to _tl that happens after the
operation.  The size of the operation should be in the MO_TESL,
which specifies target-endian signed "long" (32-bit).

Will investigate further.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1918026

Title:
  RISCV64 32-bit AMOs incorrectly simulated

Status in QEMU:
  New

Bug description:
  Version: qemu-riscv64 version 4.2.1 (Debian 1:4.2-3ubuntu6.14)

  test:
    amomaxu.w a0, a1, (a0)
    ret

  int32_t* value = -7;
  EXPECT_EQ(-7, test(&value, -11));
  EXPECT_EQ(-7, value);  // FAIL, saw -11
  EXPECT_EQ(-7, test(&value, -7));
  EXPECT_EQ(-7, value);  // FAIL, raw -11
  EXPECT_EQ(-7, test(&value, -4));
  EXPECT_EQ(-4, value);

  test:
    amomax.w a0, a1, (a0)
    ret

  int32_t* value = -7;
  EXPECT_EQ(-7, test(&value, -11));
  EXPECT_EQ(-7, value);
  EXPECT_EQ(-7, test(&value, -7));
  EXPECT_EQ(-7, value);
  EXPECT_EQ(-7, test(&value, -4));
  EXPECT_EQ(-4, value);  // FAIL, saw -7

  I suspect that trans_amo<op>_w should be using
  tcg_gen_atomic_fetch_<op>_i32 instead of tcg_gen_atomic_fetch_<op>_tl.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1918026/+subscriptions