On 11/13/19 10:30 PM, Peter Maydell wrote:
> 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.
Yeah, that makes more sense.
I think we can make the fallback
On Wed, 13 Nov 2019 at 20:17, Richard Henderson
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,
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
>
On Fri, 1 Nov 2019 at 08:51, Peter Maydell wrote:
>
> From: Andrew Jones
>
> Introduce cpu properties to give fine control over SVE vector lengths.
> We introduce a property for each valid length up to the current
> maximum supported, which is 2048-bits. The properties are named, e.g.
> sve128,
From: Andrew Jones
Introduce cpu properties to give fine control over SVE vector lengths.
We introduce a property for each valid length up to the current
maximum supported, which is 2048-bits. The properties are named, e.g.
sve128, sve256, sve384, sve512, ..., where the number is the number of
