On Jun 3, 2016 11:29 AM, "Kenneth Graunke" wrote:
>
> On Friday, June 3, 2016 10:28:34 AM PDT Jason Ekstrand wrote:
> > On Jun 3, 2016 8:43 AM, wrote:
> > >
> > > From: Robert Foss
> > >
> > > Avoid out of bounds access of the array 'src'.
> > >
> > > 'src' is passed along:
> > > nir_eval_co
On Friday, June 3, 2016 10:28:34 AM PDT Jason Ekstrand wrote:
> On Jun 3, 2016 8:43 AM, wrote:
> >
> > From: Robert Foss
> >
> > Avoid out of bounds access of the array 'src'.
> >
> > 'src' is passed along:
> > nir_eval_const_opcode()
> > evaluate_bitfield_insert()
> >
> > In evaluate_bit
Alright, I'll mark this as rejected in patchwork.
On 2016-06-03 01:28 PM, Jason Ekstrand wrote:
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.
On Jun 3, 2016 8:43 AM, wrote:
>
> From: Robert Foss
>
> 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
From: Robert Foss
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