https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123781
Bug ID: 123781
Summary: Possible off-by-one error in
gcc/gimple-lower-bitint.cc
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.bellebaum at aisec dot fraunhofer.de
Target Milestone: ---
Multiplication/Division of `__BitInt(n)` is supposed to generate inline code
for "small" to "large" precisions `n`, and calls to a compiler support routine
for "huge" values of `n`. The minimum `n` to count as "huge" is determined in
`gcc/gimple-lower-bitint.cc:117` as follows:
if (4 * limb_prec >= MAX_FIXED_MODE_SIZE)
huge_min_prec = 4 * limb_prec;
else
huge_min_prec = MAX_FIXED_MODE_SIZE + 1;
This code presumably wants to use max(MAX_FIXED_MODE_SIZE, 4 * limb_prec) as
the maximum precision to inline code, so one more than that should be the
minimum precision to count as "huge". However, this intuition requires a `+1`
in the second line, just like in the fourth.
The current implementation is weird for at least two reasons:
- lowering the limb precision from MAX_FIXED_MODE_SIZE/4 to something lower can
actually increase the precision for which inline code is generated
- four partially used limbs will generate inline code, while four fully used
limbs may call the compiler support routine, despite the required code being
simpler for most architectures.
In my case, this is especially bad, because I require constant time code and
`__mulbitint3` is not constant time, which is surprising for a "simple" builtin
language operator. (This is probably a separate issue.)
