By the way, having a RISC-V machine handy:
Linux orangepirv2 6.6.63-ky #1.0.0 SMP PREEMPT Wed Mar 12 09:04:00 CST 2025 riscv64 riscv64 riscv64 GNU/Linux
I've tried:
SELECT int4shl(1, 100);
int4shl
---------
16
(1 row)

Yes, my mistake, I rechecked the manual this instruction should not cause a trap.

FWIW, I don't agree with the premise of this patch, even a little bit.
To my mind, the purpose of these functions and their siblings is to
provide access to the C-level bitwise operators, which will do
whatever they do on your platform. There is no contract to restrict
them to some guaranteed-portable functionality subset, and I think
trying to do that would accomplish little except to break code that
had been working fine in the context it's used in.

Ok, I understand that compatible behavior is not a priority in this case.

Still an UB can be optimized and exploited by compiler in any way it decides,

so we don't have a guarantee that current platform behavior will stay.

What is a general postgres community policy about UBs?

Regards,
Egor Ivkov