https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117589
Bug ID: 117589
Summary: hppa support for BitInt
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ABI
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
CC: danglin at gcc dot gnu.org, law at gcc dot gnu.org
Blocks: 117580
Target Milestone: ---
Target: hppa
hppa does not define a BitInt ABI nor have an implementation.
Once the psABI change is figured out, little-endian support will be easiest.
The current _BitInt middle-end support likes ABIs similar to what x86-64, ia32
and aarch64 have, can accomodate different limb sizes between what the psABI
says and what libgcc uses (on aarch64 psABI says 128-bit limbs, but libgcc uses
64-bit limbs and that works well as long as the endianity of the limbs matches
ordering of limbs inside of the arrays). Similarly, more generic work would be
needed if psABI says that the in-memory or passed _BitInt always need to be
sign/zero extended to the limb size (that is what currently blocks arm support
which chose that, x86-64, ia32 and aarch64 have the padding bits undefined).
As for big-endian support, the libgcc side and non-gimple-lower-bitint.cc
middle-end code has theoretical big-endian support of _BitInts, but
gimple-lower-bitint.cc doesn't (as I didn't want to write it without being able
to test somewhere).
If psABI chooses PDP-ish endianity for _BitInt (big endian limbs ordered from
lowest to highest in the array), it might be a nightmare to support it.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117580
[Bug 117580] [meta-bug] Tagets should have a defined _BitInt ABI and implement
that ABI
