Non-32-bit integer overflow should be well-defined in Naga-enhanced WGSL, but Naga generates HLSL with UB

[jimblandy]

#7012 ensures that 32-bit signed integer overflow cannot cause UB in HLSL, but it doesn't address other integer bit widths. Official WGSL only has 32-bit integers anyway, but Naga has a 64-bit integer extension, and you could imagine a 16-bit integer extension as well. These should all work the same way as official WGSL integers do.

[cwfitzgerald]

I will note that it's IB not UB. https://microsoft.github.io/hlsl-specs/specs/hlsl.html#Conv.iconv

[jamienicol]

You both beat me to the punch, for filing the issue in the first place and then explaining that it's implementation-defined 😄

To clarify for future readers: as things stand we don't do any conversion, we just operate on signed types, for which we believe overflow is undefined behaviour.

For 32-bit signed integers we avoid this by using asint()/asuint() to perform the arithmetic on unsigned types and cast back to signed. But those functions only exist for 32 bit types. For other bit widths we could explicitly convert using constructors or C-style casts, eg int64_t2(uint64t_2(x) * uint64_t2(y)). The conversion from unsigned to signed is implementation defined. Maybe that's fine.

Or if we want to be fully above board we could do something like this:

int64_t to_signed(uint64_t u) {
    return u <= INT64_MAX ? int64_t(u) : -int64_t(-u);
}

I checked on godbolt and DXC seems to be smart enough to optimize that away

[jamienicol]

Actually I think that's still UB if u == INT64_MAX + 1

[jamienicol]

Maybe

int64_t to_signed(uint64_t u) {
    return u <= INT64_MAX ? int64_t(u) : int64_t(u - uint64_t(INT64_MIN)) + INT64_MIN;
}

From https://stackoverflow.com/questions/13150449/efficient-unsigned-to-signed-cast-avoiding-implementation-defined-behavior

[jamienicol]

I reverted the title, as the current situation (signed overflow) is indeed UB 🙂

[cwfitzgerald]

I hate all of this.