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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 > > [email protected] > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
