Shift exponent 32 is too large for 32-bit type 'KUInt32'

[panicsteve]

This may not be an actual problem in the real world (it seems to run fine on all our supported platforms), but I'm reporting it since it was flagged by the Undefined Behavior Sanitizer on macOS.

In line 413 of Emulator/JIT/Generic/TJITGeneric_Macros.h, when amount has the value 32, it attempts to shift the 32-bit KUInt32 theResult right by 32 bits.

The sanitizer flags this as "Invalid shift exponent" with the explanation "Shift exponent 32 is too large for 32-bit type 'KUInt32'".

There's a similar situation in line 389 of Monitor/UDisasm.cp where a 32-bit value is shifted left by 32 bits, when rotate has the value 0, but this line of code is only generating text for the monitor, and is not part of the emulation.

[pguyot]

This is a dangerous bug. Indeed, shifting 32 bits a 32 bit value is an undefined behavior, and I remember there was an issue when supported platforms were 32 bits only, PowerPC and x86 behaved differently. The emulator seemed to work fine (on one platform), however there were little glitches that were not present on the other platform.

[panicsteve]

Although the behavior is officially undefined, is it correct to say that NewtonOS as it is written expects a 32-bit rotate to be effectively a nop? (It seems to be the case?) If so, we should just check if the rotate amount is 32, and do nothing if so, rather than leaving it up to the compiler.

[pguyot]

The code seems to say so and recent ARM documentation confirms indeed that ROR by 32 bits is a NOP (except for the carry).