For example, in the final test from trigonometry.shader_test, we have:
sincos r1.x <v4:float>, null <float>, l(3.00000000e+01) <s:float>
which currently gets turned into
mov sr0.xyzw <v4:float>, l(3.00000000e+01) <s:float>
sin r1.x <v4:float>, sr0.xyzw <v4:float>
That doesn't seem ideal, and should possibly be rejected by the
validator, but ends up working out well enough for the SPIR-V backend.
It's a bit more problematic to deal with for the GLSL backend.
The following warning appears during compilation with
gcc 15.1.1 20250425:
In function 'vsir_block_list_init',
inlined from 'vsir_block_init' at vkd3d/libs/vkd3d-shader/ir.c:3821:5,
inlined from 'vsir_cfg_init' at vkd3d/libs/vkd3d-shader/ir.c:4285:28:
vkd3d/libs/vkd3d-shader/ir.c:3758:5: warning: 'memset' writing 24 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
3758 | memset(list, 0, sizeof(*list));
| ^
In function 'vsir_cfg_init':
lto1: note: destination object is likely at address zero
looking at the code in vsir_cfg_init() this seems like an spurious
warning. Looking on the internet, these bogus warnings with memset()
seem to be a common occurrence.
memset() is replaced with a zero value assignment to avoid this.
When a heap was released at the same time as the last resource on that
heap, it was possible for both to see each other's
refcount/resource_count as 0 and both would try to destroy the heap.
Avoid that by converting "resource_count" to an internal refcount, which
holds an extra +1 if the main refcount is nonzero. The final release
will then be synchronized between the two since both will operate on
"internal_refcount".
