All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
To: qemu-devel@nongnu.org
Subject: [Bug 1841990] Re: instruction 'denbcdq' misbehaving
Date: Wed, 25 Sep 2019 19:09:59 -0000	[thread overview]
Message-ID: <156943859931.425.1301371420457105353.malone@wampee.canonical.com> (raw)
In-Reply-To: 156711057074.6835.13599471410604217618.malonedeb@soybean.canonical.com

That certainly sounds like progress. Did you see the follow up email
indicating the typo that I found in patch 6? It can be fixed by applying
the following diff on top:

diff --git a/target/ppc/dfp_helper.c b/target/ppc/dfp_helper.c
index c2d335e928..b801acbedc 100644
--- a/target/ppc/dfp_helper.c
+++ b/target/ppc/dfp_helper.c
@@ -1054,7 +1054,7 @@ static inline void dfp_set_sign_64(ppc_vsr_t *t, uint8_t sgn)
 static inline void dfp_set_sign_128(ppc_vsr_t *t, uint8_t sgn)
 {
     t->VsrD(0) <<= 4;
-    t->VsrD(0) |= (t->VsrD(0) >> 60);
+    t->VsrD(0) |= (t->VsrD(1) >> 60);
     t->VsrD(1) <<= 4;
     t->VsrD(1) |= (sgn & 0xF);
 }

Does that help any more tests to pass? Also the changes to the FP
register layout were made in QEMU 4.0 and so it seems to me that even if
some tests fail, if the results between QEMU 3.1 and QEMU git master
with the patchset applied are equivalent then we can assume that the
patchset functionality is correct.

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

Title:
  instruction 'denbcdq' misbehaving

Status in QEMU:
  New

Bug description:
  Instruction 'denbcdq' appears to have no effect.  Test case attached.

  On ppc64le native:
  --
  gcc -g -O -mcpu=power9 bcdcfsq.c test-denbcdq.c -o test-denbcdq
  $ ./test-denbcdq
  0x00000000000000000000000000000000
  0x0000000000000000000000000000000c
  0x22080000000000000000000000000000
  $ ./test-denbcdq 1
  0x00000000000000000000000000000001
  0x0000000000000000000000000000001c
  0x22080000000000000000000000000001
  $ ./test-denbcdq $(seq 0 99)
  0x00000000000000000000000000000064
  0x0000000000000000000000000000100c
  0x22080000000000000000000000000080
  --

  With "qemu-ppc64le -cpu power9"
  --
  $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq
  0x00000000000000000000000000000000
  0x0000000000000000000000000000000c
  0x0000000000000000000000000000000c
  $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1
  0x00000000000000000000000000000001
  0x0000000000000000000000000000001c
  0x0000000000000000000000000000001c
  $ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100)
  0x00000000000000000000000000000064
  0x0000000000000000000000000000100c
  0x0000000000000000000000000000100c
  --

  I started looking at the code, but I got confused rather quickly.
  Could be related to endianness? I think denbcdq arrived on the scene
  before little-endian was a big deal.  Maybe something to do with
  utilizing implicit floating-point register pairs...  I don't think the
  right data is getting to helper_denbcdq, which would point back to the
  gen_fprp_ptr uses in dfp-impl.inc.c (GEN_DFP_T_FPR_I32_Rc).  (Maybe?)

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


  parent reply	other threads:[~2019-09-25 19:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29 20:29 [Qemu-devel] [Bug 1841990] [NEW] instruction 'denbcdq' misbehaving Paul Clarke
2019-08-30  6:29 ` [Qemu-devel] [Bug 1841990] " Alex Bennée
2019-08-30  7:32 ` Philippe Mathieu-Daudé
2019-08-30  8:12 ` Philippe Mathieu-Daudé
2019-08-30 13:14 ` Paul Clarke
2019-08-30 17:40 ` Philippe Mathieu-Daudé
2019-08-31 17:52 ` Mark Cave-Ayland
2019-08-31 21:16 ` Paul Clarke
2019-09-24 15:54 ` Mark Cave-Ayland
2019-09-25 17:51 ` Paul Clarke
2019-09-25 19:09 ` Mark Cave-Ayland [this message]
2019-09-25 21:21 ` Paul Clarke
2019-09-26  5:47 ` Mark Cave-Ayland
2019-09-26 14:08 ` Paul Clarke
2019-09-26 16:00 ` Mark Cave-Ayland
2019-09-26 16:26 ` Paul Clarke
2019-09-26 16:43 ` Paul Clarke
2019-09-26 16:59 ` Mark Cave-Ayland
2019-09-26 17:31 ` Paul Clarke
2019-09-26 17:57 ` Mark Cave-Ayland
2021-05-02 18:09 ` Thomas Huth

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=156943859931.425.1301371420457105353.malone@wampee.canonical.com \
    --to=mark.cave-ayland@ilande.co.uk \
    --cc=1841990@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.