Open yumkam opened 5 years ago
If we really care, then they can be amended to
static INLINE int32_t _adds(int32_t x, int32_t y)
{
return (y > 0) ? (((INT_MAX - y) < x) ? INT_MAX : x+y) : (((INT_MIN - y) > x) ? INT_MIN : x+y);
}
static INLINE int32_t _subs(int32_t x, int32_t y)
{
return (y > 0) ? (((INT_MIN + y) > x) ? INT_MIN : x-y) : (((INT_MAX + y) < x) ? INT_MAX : x-y);
}
(I think I've verified all combinations of saturation). Obviously they're more complex computationally, so performance may be affected.
This is part of the firmware based GLES driver which will hopefully be deprecated sometime soon in favour of the kernel vc4 driver and mesa. The fact that it gives the correct numbers on the assumption that it overflows in the normal manner (ie without signed overflow) makes me not overly fussed by the warning. I don't know what others think.
On debian/stretch:i386 using distro-provided cross-compiler (
g++-6-arm-linux-gnueabihf (6.3.0-18cross1)
)Looks like 1) warning is correct: code relies on undefined behavior; 2) despite warning, gcc (as of 6.3.0) generates correct code (that is, it does not actually assume that signed overflow does not occur), but this is fragile and can break anytime (I've also checked raspbian-provided
libEGL_static.a
, affected generated asm code looks correct).