[Mesa-dev] undefined behaviour in spirv_to_nir.c

[Karol Herbst]

well, the code was required for the old style load_const as we unioned
the arrays. But now that the load_const data is just one 64 bit value
and we 0 out untouched bits I am quite sure we don't have to adjust
the bit size of the shift anymore? Although I would feel better if we
would have some explicit handling about it, even if the compiler just
optimizes it away.

On Fri, May 17, 2019 at 8:55 PM Jason Ekstrand <jason at jlekstrand.net> wrote:
>
> I'm not convinced that code is correct.  In particular, the bit_size value is for the destination and not necessarily that one source.  As Karol points out, it probably is safe to just delete.  However, I'd feel slightly better about it if we figured out the right bit size and just called nir_eval_const_opcode to do a u2u32 on the value.
>
> --Jason
>
> On Fri, May 17, 2019 at 1:24 AM Karol Herbst <kherbst at redhat.com> wrote:
>>
>> ohhh, yeah.. I think we can actually just remove that code, as it
>> shouldn't have any affect on the constants value.
>>
>> On Fri, May 17, 2019 at 4:07 AM Jason Ekstrand <jason at jlekstrand.net> wrote:
>> >
>> > I think it's fine but I'm not at my computer right now.
>> >
>> > --Jason
>> >
>> > On May 16, 2019 20:58:03 Dave Airlie <airlied at gmail.com> wrote:
>> >
>> > > Coverity gave me this:
>> > >
>> > > mesa-19.1.0-rc2/src/compiler/spirv/spirv_to_nir.c:1987:
>> > > overlapping_assignment: Assigning "src[1][i].u8" to "src[1][i].u32",
>> > > which have overlapping memory locations and different types.
>> > >
>> > > and the following lines, I think it's actually undefined behaviour wrt
>> > > the C spec.
>> > >
>> > > Dave.
>> >
>> >
>> >
>> > _______________________________________________
>> > mesa-dev mailing list
>> > mesa-dev at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev