https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124492
Bug ID: 124492
Summary: arm _BitInt(N > 65) not extended into stack
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Arm _BitInt support has known issues around stack variables where the limb mode
is smaller than the ABI mode. This shows up as failures in the testsuite for
the following tests:
dg/torture/bitint-82.c -O0 execution test
dg/torture/bitint-82.c -O2 execution test
dg/torture/bitint-83.c -O0 execution test
dg/torture/bitint-83.c -O2 execution test
dg/bitint-28.c execution test
dg/bitint-29.c execution test
dg/bitint-30.c execution test
dg/bitint-31.c execution test
This issue can be shown by a smaller testcase like:
#include "bitintext.h"
int main ()
{
_BitInt(65) g = -147090211948845388976606115811401318743wb;
BEXTC (g);
return 0;
}
using the BEXTC definition in bitintext.h in the testsuite. when compiled for a
-mcpu=cortex-m3 target you'll see:
movs r2, #16 <--- size argument 16-bytes
aka 128 bits
mov r3, #-1 <--- if we treat g as an
array of 32-bit limbs then this is prepping the value that goes into g[2]
push {fp, lr}
adr ip, .L15
ldrd fp, [ip] <---- loads the
constants for g[0] and g[1]
sub sp, sp, #32
add r0, sp, r2
mov r1, sp
str r3, [sp, #8] <--- stores the -1 for
g[2] onto the stack
strd fp, [sp] <--- stores the
constants for g[0], g[1] onto the stack which the address for g[0] is
passed in r1
bl do_copy
you see here we never populate the last 32-bits of the stack that is
meant to represent g[3]
I suspect this needs some changes to stor-layout.cc to make sure we use the ABI
mode for _BitInt variables on the stack.
