qemu-devel
[Top][All Lists]
Advanced

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

Re: [PULL 04/11] target/arm/cpu64: max cpu: Introduce sve<N> properties


From: Peter Maydell
Subject: Re: [PULL 04/11] target/arm/cpu64: max cpu: Introduce sve<N> properties
Date: Wed, 13 Nov 2019 21:30:41 +0000

On Wed, 13 Nov 2019 at 20:17, Richard Henderson
<address@hidden> wrote:
>
> On 11/12/19 11:23 AM, Peter Maydell wrote:
> >> +static uint32_t sve_zcr_get_valid_len(ARMCPU *cpu, uint32_t start_len)
> >> +{
> >> +    uint32_t start_vq = (start_len & 0xf) + 1;
> >> +
> >> +    return arm_cpu_vq_map_next_smaller(cpu, start_vq + 1) - 1;
> >
> > "Subtract operation overflows on operands
> > arm_cpu_vq_map_next_smaller(cpu, start_vq + 1U) and 1U"
> >
> > Certainly it looks as if arm_cpu_vq_map_next_smaller() can
> > return 0, and claiming the valid length to be UINT_MAX
> > seems a bit odd in that case.
>
> The lsb is always set in the map, the minimum number we send to next_smaller 
> is
> 2 -> so the minimum number returned from next_smaller is 1.
>
> We should never return UINT_MAX.
>
> >     return bitnum == vq - 1 ? 0 : bitnum + 1;
>
> But yes, this computation doesn't seem right.
>
> The beginning assert should probably be (vq >= 2 ...)
> and here we should assert bitnum != vq - 1.

Coverity may also be looking at the case where
TARGET_AARCH64 is not defined. The fallback definition
of arm_cpu_vq_map_next_smaller() for that situation
always returns 0.

thanks
-- PMM



reply via email to

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