On 10/25/25 7:12 PM, Alexandre Oliva wrote:
When computing an address plus a large offset on riscv64 with a
PC-relative sequence, we may hit the range limit for auipc and get a
relocation overflow, where on riscv32 the computation wraps around.
Since -mcmodel=medany requires the entire program to fit in a 2GiB
address range, a +/-1GiB+ offset added to an in-range symbol in a
barely-fitting program is more likely than not to be out-of-range.
Since such large constants are unlikely to come up by chance, separate
them from the symbol so as to avoid the relocation overflow.
Tested on riscv64-elf and riscv32-elf with gcc-14; now testing on trunk.
Ok to install, or should we go for some more flexible alternative, say
with a --param to customize the offset range limit?
for gcc/ChangeLog
PR target/91420
* config/riscv/riscv.cc (riscv_symbolic_constant_p): Require
offsets smaller than +/- 1GiB for PCREL symbols.
for gcc/testsuite/ChangeLog
PR target/91420
* gcc.target/riscv/pr91420.c: New.
Fundamentally we can't know if things work until link time, right,
except for perhaps some cases like a local literal pool? We could (for
example) be near the beginning of the address space and adding 1G should
be fine from an address space standpoint.
I'd be inclined say these things aren't well defined in the smaller code
models. If we can do something that works reliably and is efficient,
then great, otherwise I'd be inclined to punt.
Is there a compelling case outside the BZ that's got you digging around
in here ;-) ?
Jeff
