[Bug 1923629] [NEW] RISC-V Vector Instruction vssub.vv not saturating

[Bug 1923629] [NEW] RISC-V Vector Instruction vssub.vv not saturating

[Tony Cole]

Public bug reported:

I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).

Here is the bit of the code:

		vmv.v.i		v16, 0
		…
8f040457	vssub.vv	v8,v16,v8

I believe the instruction encoding is correct (vssub.vv with vd = v8,
vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.

I’ve just tested with what I think is the latest branch (
https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
exists.

** Affects: qemu
     Importance: Undecided
         Status: New


** Tags: riscv vector

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

Title:
  RISC-V Vector Instruction vssub.vv not saturating

Status in QEMU:
  New

Bug description:
  I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
  incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).

  Here is the bit of the code:

  		vmv.v.i		v16, 0
  		…
  8f040457	vssub.vv	v8,v16,v8

  I believe the instruction encoding is correct (vssub.vv with vd = v8,
  vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.

  I’ve just tested with what I think is the latest branch (
  https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
  2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
  exists.

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

Re: [Bug 1923629] [NEW] RISC-V Vector Instruction vssub.vv not saturating

[Alistair Francis]

+ LIU Zhiwei and Kito Cheng

Alistair

On Wed, Apr 14, 2021 at 1:31 AM Tony Cole <1923629@bugs.launchpad.net> wrote:
>
> Public bug reported:
>
> I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
> incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).
>
> Here is the bit of the code:
>
>                 vmv.v.i         v16, 0
>                 …
> 8f040457        vssub.vv        v8,v16,v8
>
> I believe the instruction encoding is correct (vssub.vv with vd = v8,
> vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.
>
> I’ve just tested with what I think is the latest branch (
> https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
> 2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
> exists.
>
> ** Affects: qemu
>      Importance: Undecided
>          Status: New
>
>
> ** Tags: riscv vector
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1923629
>
> Title:
>   RISC-V Vector Instruction vssub.vv not saturating
>
> Status in QEMU:
>   New
>
> Bug description:
>   I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
>   incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).
>
>   Here is the bit of the code:
>
>                 vmv.v.i         v16, 0
>                 …
>   8f040457      vssub.vv        v8,v16,v8
>
>   I believe the instruction encoding is correct (vssub.vv with vd = v8,
>   vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.
>
>   I’ve just tested with what I think is the latest branch (
>   https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
>   2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
>   exists.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1923629/+subscriptions
>

Re: [Bug 1923629] [NEW] RISC-V Vector Instruction vssub.vv not saturating

[Kito Cheng]

Add Frank, he is the SiFive's qemu maintainer.

On Thu, Apr 15, 2021 at 11:57 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> + LIU Zhiwei and Kito Cheng
>
> Alistair
>
> On Wed, Apr 14, 2021 at 1:31 AM Tony Cole <1923629@bugs.launchpad.net> wrote:
> >
> > Public bug reported:
> >
> > I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
> > incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).
> >
> > Here is the bit of the code:
> >
> >                 vmv.v.i         v16, 0
> >                 …
> > 8f040457        vssub.vv        v8,v16,v8
> >
> > I believe the instruction encoding is correct (vssub.vv with vd = v8,
> > vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.
> >
> > I’ve just tested with what I think is the latest branch (
> > https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
> > 2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
> > exists.
> >
> > ** Affects: qemu
> >      Importance: Undecided
> >          Status: New
> >
> >
> > ** Tags: riscv vector
> >
> > --
> > You received this bug notification because you are a member of qemu-
> > devel-ml, which is subscribed to QEMU.
> > https://bugs.launchpad.net/bugs/1923629
> >
> > Title:
> >   RISC-V Vector Instruction vssub.vv not saturating
> >
> > Status in QEMU:
> >   New
> >
> > Bug description:
> >   I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
> >   incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).
> >
> >   Here is the bit of the code:
> >
> >                 vmv.v.i         v16, 0
> >                 …
> >   8f040457      vssub.vv        v8,v16,v8
> >
> >   I believe the instruction encoding is correct (vssub.vv with vd = v8,
> >   vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.
> >
> >   I’ve just tested with what I think is the latest branch (
> >   https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
> >   2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
> >   exists.
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/qemu/+bug/1923629/+subscriptions
> >

Re: [Bug 1923629] [NEW] RISC-V Vector Instruction vssub.vv not saturating

[LIU Zhiwei]

Hi Alistair,

I think that this bug has been resolved in my packed-extension patch set[1].

Would you mind to have a test and merge it before the whole patch set?

Thanks.


Best Regards,

Zhiwei

[1]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg782125.html



On 2021/4/15 上午11:57, Alistair Francis wrote:
> + LIU Zhiwei and Kito Cheng
>
> Alistair
>
> On Wed, Apr 14, 2021 at 1:31 AM Tony Cole <1923629@bugs.launchpad.net> wrote:
>> Public bug reported:
>>
>> I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
>> incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).
>>
>> Here is the bit of the code:
>>
>>                  vmv.v.i         v16, 0
>>                  …
>> 8f040457        vssub.vv        v8,v16,v8
>>
>> I believe the instruction encoding is correct (vssub.vv with vd = v8,
>> vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.
>>
>> I’ve just tested with what I think is the latest branch (
>> https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
>> 2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
>> exists.
>>
>> ** Affects: qemu
>>       Importance: Undecided
>>           Status: New
>>
>>
>> ** Tags: riscv vector
>>
>> --
>> You received this bug notification because you are a member of qemu-
>> devel-ml, which is subscribed to QEMU.
>> https://bugs.launchpad.net/bugs/1923629
>>
>> Title:
>>    RISC-V Vector Instruction vssub.vv not saturating
>>
>> Status in QEMU:
>>    New
>>
>> Bug description:
>>    I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
>>    incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).
>>
>>    Here is the bit of the code:
>>
>>                  vmv.v.i         v16, 0
>>                  …
>>    8f040457      vssub.vv        v8,v16,v8
>>
>>    I believe the instruction encoding is correct (vssub.vv with vd = v8,
>>    vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.
>>
>>    I’ve just tested with what I think is the latest branch (
>>    https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
>>    2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
>>    exists.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/qemu/+bug/1923629/+subscriptions
>>

[Bug 1923629] Re: RISC-V Vector Instruction vssub.vv not saturating

[Alistair Francis]

Thanks for raising this bug case. A fix should be available soon.

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

Title:
  RISC-V Vector Instruction vssub.vv not saturating

Status in QEMU:
  New

Bug description:
  I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
  incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).

  Here is the bit of the code:

  		vmv.v.i		v16, 0
  		…
  8f040457	vssub.vv	v8,v16,v8

  I believe the instruction encoding is correct (vssub.vv with vd = v8,
  vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.

  I’ve just tested with what I think is the latest branch (
  https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
  2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
  exists.

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

Re: [Bug 1923629] [NEW] RISC-V Vector Instruction vssub.vv not saturating

[Alistair Francis]

On Thu, Apr 15, 2021 at 2:18 PM LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:
>
> Hi Alistair,
>
> I think that this bug has been resolved in my packed-extension patch set[1].
>
> Would you mind to have a test and merge it before the whole patch set?

Great! Thanks

I have applied patch 3 for the next PR.

Alistair

>
> Thanks.
>
>
> Best Regards,
>
> Zhiwei
>
> [1]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg782125.html
>
>
>
> On 2021/4/15 上午11:57, Alistair Francis wrote:
> > + LIU Zhiwei and Kito Cheng
> >
> > Alistair
> >
> > On Wed, Apr 14, 2021 at 1:31 AM Tony Cole <1923629@bugs.launchpad.net> wrote:
> >> Public bug reported:
> >>
> >> I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
> >> incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).
> >>
> >> Here is the bit of the code:
> >>
> >>                  vmv.v.i         v16, 0
> >>                  …
> >> 8f040457        vssub.vv        v8,v16,v8
> >>
> >> I believe the instruction encoding is correct (vssub.vv with vd = v8,
> >> vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.
> >>
> >> I’ve just tested with what I think is the latest branch (
> >> https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
> >> 2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
> >> exists.
> >>
> >> ** Affects: qemu
> >>       Importance: Undecided
> >>           Status: New
> >>
> >>
> >> ** Tags: riscv vector
> >>
> >> --
> >> You received this bug notification because you are a member of qemu-
> >> devel-ml, which is subscribed to QEMU.
> >> https://bugs.launchpad.net/bugs/1923629
> >>
> >> Title:
> >>    RISC-V Vector Instruction vssub.vv not saturating
> >>
> >> Status in QEMU:
> >>    New
> >>
> >> Bug description:
> >>    I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
> >>    incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).
> >>
> >>    Here is the bit of the code:
> >>
> >>                  vmv.v.i         v16, 0
> >>                  …
> >>    8f040457      vssub.vv        v8,v16,v8
> >>
> >>    I believe the instruction encoding is correct (vssub.vv with vd = v8,
> >>    vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.
> >>
> >>    I’ve just tested with what I think is the latest branch (
> >>    https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
> >>    2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
> >>    exists.
> >>
> >> To manage notifications about this bug go to:
> >> https://bugs.launchpad.net/qemu/+bug/1923629/+subscriptions
> >>

[Bug 1923629] Re: RISC-V Vector Instruction vssub.vv not saturating

[Frank Chang]

This should be a quick fix, we will run couple tests again to ensure the
fix doesn't break anything. Thanks~

** Changed in: qemu
     Assignee: (unassigned) => Frank Chang (frankchang0125)

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

Title:
  RISC-V Vector Instruction vssub.vv not saturating

Status in QEMU:
  New

Bug description:
  I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
  incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).

  Here is the bit of the code:

  		vmv.v.i		v16, 0
  		…
  8f040457	vssub.vv	v8,v16,v8

  I believe the instruction encoding is correct (vssub.vv with vd = v8,
  vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.

  I’ve just tested with what I think is the latest branch (
  https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
  2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
  exists.

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

[Bug 1923629] Re: RISC-V Vector Instruction vssub.vv not saturating

[Alistair Francis]

This was fixed by commit:

commit 65606f21243a796537bfe4708720a9bf4bb50169
Author: LIU Zhiwei <zhiwei_liu@c-sky.com>
Date:   Fri Feb 12 23:02:21 2021 +0800

    target/riscv: Fixup saturate subtract function
    
    The overflow predication ((a - b) ^ a) & (a ^ b) & INT64_MIN is right.
    However, when the predication is ture and a is 0, it should return maximum.
    
    Signed-off-by: LIU Zhiwei <zhiwei_liu@c-sky.com>
    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
    Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
    Message-id: 20210212150256.885-4-zhiwei_liu@c-sky.com
    Signed-off-by: Alistair Francis <alistair.francis@wdc.com>


The fix will be in the QEMU 6.1 release.

** Changed in: qemu
       Status: New => Fix Committed

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

Title:
  RISC-V Vector Instruction vssub.vv not saturating

Status in QEMU:
  Fix Committed

Bug description:
  I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
  incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).

  Here is the bit of the code:

  		vmv.v.i		v16, 0
  		…
  8f040457	vssub.vv	v8,v16,v8

  I believe the instruction encoding is correct (vssub.vv with vd = v8,
  vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.

  I’ve just tested with what I think is the latest branch (
  https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
  2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
  exists.

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

[Bug 1923629] Re: RISC-V Vector Instruction vssub.vv not saturating

[Thomas Huth]

** Changed in: qemu
       Status: Fix Committed => Fix Released

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

Title:
  RISC-V Vector Instruction vssub.vv not saturating

Status in QEMU:
  Fix Released

Bug description:
  I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an
  incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).

  Here is the bit of the code:

  		vmv.v.i		v16, 0
  		…
  8f040457	vssub.vv	v8,v16,v8

  I believe the instruction encoding is correct (vssub.vv with vd = v8,
  vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.

  I’ve just tested with what I think is the latest branch (
  https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb
  2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still
  exists.

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