Re: [PATCH] intXshr, intXshl: return error on shift count out of range - Mailing list pgsql-hackers

From David Rowley
Subject Re: [PATCH] intXshr, intXshl: return error on shift count out of range
Date
Msg-id CAApHDvrKqb+0sJhVX872JejXcAPoP7Av-9NLjwV+fP8Mu6tpvw@mail.gmail.com
Whole thread
Responses Re: [PATCH] intXshr, intXshl: return error on shift count out of range
List pgsql-hackers
On Wed, 30 Sept 2026 at 10:47, Egor Ivkov <e.ivkov@arenadata.io> wrote:
> x86 handled this by applying a mask (e.g. & 31) while ARM will produce 0 and RISC-V will crash. So besides being an
UBit is inconsistent across platforms.
 

Can you share more details about this claimed crash behaviour for
RISC-V? Going by [1], I see:

"SLL, SRL, and SRA perform logical left, logical right, and arithmetic
right shifts on the value in register rs1 by the shift amount held in
register rs2. In RV64I, only the low 6 bits of rs2 are considered for
the shift amount."

I don't have access to RISC-V hardware, so I tried [2] to see what the
compiler emits with constant inputs. I see it optimises the shift into
a constant-zero when asked to shift left by more than the type's
width. I'm unsure if that's a misoptimisation or not as it's not using
the lower 6 bits rule that I interpret from the standard.

Have you actually tested this on RISC-V?  Can you share the results of:

SELECT 1::bigint << 255, 1::bigint << 63;

Does it actually crash?

David

[1] https://docs.riscv.org/reference/isa/v20260120/unpriv/rv64.html
[2] https://godbolt.org/z/3MfTze6rj



pgsql-hackers by date:

Previous
From: Paul A Jungwirth
Date:
Subject: WITHOUT OVERLAPS foreign key allows referencing EXCLUDE constraint
Next
From: David Rowley
Date:
Subject: Re: [PATCH] intXshr, intXshl: return error on shift count out of range