On Friday, June 3, 2016 10:28:34 AM PDT Jason Ekstrand wrote: > On Jun 3, 2016 8:43 AM, <[email protected]> wrote: > > > > From: Robert Foss <[email protected]> > > > > Avoid out of bounds access of the array 'src'. > > > > 'src' is passed along: > > nir_eval_const_opcode() > > evaluate_bitfield_insert() > > > > In evaluate_bitfield_insert() an access to src[3] is made > > if bit_size==32 wich it always will be due to the > > assert(bit_size == 32) on spirv_to_nir.c:1045. > > > > Since 'src' is of length 3, this is out of bounds. > > > > Coverity id: 1358582 > > > > Signed-off-by: Robert Foss <[email protected]> > > --- > > src/compiler/spirv/spirv_to_nir.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/compiler/spirv/spirv_to_nir.c > b/src/compiler/spirv/spirv_to_nir.c > > index 99514b4..46ede6a 100644 > > --- a/src/compiler/spirv/spirv_to_nir.c > > +++ b/src/compiler/spirv/spirv_to_nir.c > > @@ -1035,7 +1035,7 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp > opcode, > > unsigned bit_size = > > glsl_get_bit_size(glsl_get_base_type(val->const_type)); > > > > - nir_const_value src[3]; > > + nir_const_value src[4]; > > None of the Opcode's evaluated as specialization constants have four > sources so this will never be a problem. Hence the assert on the next > line. I think we should just mark this as a false positive. > > > assert(count <= 7); > > for (unsigned i = 0; i < count - 4; i++) { > > nir_constant *c =
Would promoting assert(count <= 7) to assume(count <= 7) make Coverity happy? (CC'd Matt, he'd probably know...) --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
