qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/3] target/s390x: fix handling of zeroes in vfmin/vfmax


From: David Hildenbrand
Subject: Re: [PATCH 1/3] target/s390x: fix handling of zeroes in vfmin/vfmax
Date: Tue, 12 Jul 2022 09:16:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 12.07.22 03:57, Ilya Leoshkevich wrote:
> vfmin_res() / vfmax_res() are trying to check whether a and b are both
> zeroes, but in reality they check that they are the same kind of zero.
> This causes incorrect results when comparing positive and negative
> zeroes.
> 
> Fixes: da4807527f3b ("s390x/tcg: Implement VECTOR FP (MAXIMUM|MINIMUM)")
> Co-developed-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
>  target/s390x/tcg/vec_fpu_helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target/s390x/tcg/vec_fpu_helper.c 
> b/target/s390x/tcg/vec_fpu_helper.c
> index 2a618a1093..75cf605b9f 100644
> --- a/target/s390x/tcg/vec_fpu_helper.c
> +++ b/target/s390x/tcg/vec_fpu_helper.c
> @@ -824,7 +824,7 @@ static S390MinMaxRes vfmin_res(uint16_t dcmask_a, 
> uint16_t dcmask_b,
>          default:
>              g_assert_not_reached();
>          }
> -    } else if (unlikely(dcmask_a & dcmask_b & DCMASK_ZERO)) {
> +    } else if (unlikely((dcmask_a & DCMASK_ZERO) && (dcmask_b & 
> DCMASK_ZERO))) {
>          switch (type) {
>          case S390_MINMAX_TYPE_JAVA:
>              return neg_a ? S390_MINMAX_RES_A : S390_MINMAX_RES_B;
> @@ -874,7 +874,7 @@ static S390MinMaxRes vfmax_res(uint16_t dcmask_a, 
> uint16_t dcmask_b,
>          default:
>              g_assert_not_reached();
>          }
> -    } else if (unlikely(dcmask_a & dcmask_b & DCMASK_ZERO)) {
> +    } else if (unlikely((dcmask_a & DCMASK_ZERO) && (dcmask_b & 
> DCMASK_ZERO))) {
>          const bool neg_a = dcmask_a & DCMASK_NEGATIVE;
>  
>          switch (type) {

Thanks!

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]