Error when a jump instruction jumps to a very distant location within a function

[shioyadan]

Hello,

Compiling a very large function with gcc causes an error. It appears that overflow occurs when a jump target in a function is beyond the range that can be represented by the displacement of the jump instruction.

The following is the code to reproduce this error:

// test.c
int main() {
    volatile int i = 0;
    for (int j = 0; j < 10; j++) {
        #define X10(x) x; x; x; x; x; x; x; x; x; x; 
        X10(X10(X10(X10(X10(i++)))));
    }
    return i;
}

The following error occurs.

$ ~/opt/gcc/riscv64-linux/11.1/bin/riscv64-unknown-linux-gnu-gcc test.c
/tmp/ccrQPqo1.o: in function `main':
test.c:(.text+0x14): relocation truncated to fit: R_RISCV_JAL against `.L2'
collect2: error: ld returned 1 exit status

When the compiled object file is disassembled, it appears that the jump target is broken.

0000000000000010 <.LBB2>:
    for (int j = 0; j < 10; j++) {
      10:	fe042623          	sw	zero,-20(s0)
      14:	c90e806f          	j	fffffffffffe84a4 <.LFE0+0xffffffffffdfffd4>

I have confirmed that this error occurs with various versions of gcc including riscv64/riscv32 version 11.1 (refs/tags/2021.09.21). It also occurs with the cross-compiler in apt on Ubuntu 20.04. The same problem occurred not only in C, but also in C++ and Fortran.

[cmuellner]

Note, that RISC-V currently has two code models (medlow, medany; see [1]) plus the awareness of at least one missing code model (large?). medany allows you to address code in the range from -2 GiB up to +2 GiB. If you need more, then you are currently out of luck, because there is no standardized solution available (however, there has been a proposal (see [2]) provided earlier this year, so there is some movement) and therefore no upstream support in the toolchain.

[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc
[2] riscv-non-isa/riscv-elf-psabi-doc#254

[jim-wilson]

This is a known problem. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062
There might also be an older bug somewhere in here or riscv-gcc that complains about the same problem.

Unfortunately, fixing the problem requires allocating an extra register for out-of-range branches, which would affect performance and code size, so it not something we really want to do. At one point I had a proposed patch that modified gcc to emit an error for an out-of-range branch that suggested using -mreserve-compiler-temp to work around the problem. The option -mreserve-compiler-temp would take one register away from the register allocator, which we could then use to fix out-of-range branches, resulting in slightly larger and slower code, but at least unusually written code could be compiled. I unfortunately never had time to finish that patch.

[shioyadan]

Thank you for your detailed explanation of the error.

I believe that this error occurs regardless of the code model and is caused by the code generator's inability to support out-of-range branches. Is my understanding correct?

I am convinced that it is not as simple as it sounds, as additional registers are needed to solve this problem as you describe. I am also convinced why such a problem, which someone would have discovered, has not been solved.

I don't know enough about compilers to know if this is possible, but in principle, the problem could be solved by generating code that would save the value to the stack and return it from the stack after a jump, just like a normal spill. But it certainly may not be that simple.

Although humans do not normally write functions large enough to cause out-of-range branches to appear, such code sometimes appears in auto-generated programs.

For example, I encountered this error when compiling the WRF included in the SPEC CPU 2017 benchmark (https://www.spec.org/cpu2017/Docs/benchmarks/621.wrf_s.html). Some of the source code in WRF is auto-generated and has very large functions resulting from the expansion of many lines. Up to version 8, gcc was able to compile this code correctly, but later versions have started to generate that error, probably due to the increased code size. Performance evaluations using SPEC CPUs have been widely conducted, and the fact that the code does not compile in RISC-V will have an impact on many people, including us.

Also, some interpreters have functions that contain very large switch-case or goto-linked blocks, and I believe that the same kind of errors can occur in these functions.

While this problem may indeed only occur in rare cases, it does actually appear in widely used programs, and I believe it is worth addressing.

[jim-wilson]

Yes, the problem is independent of code models.

There has been a severe lack of RISC-V GNU toolchain developers for a long time, so there are a lot of known issues that never got fixed because there was no one available to fix them. We were forced to make value judgments and fix the important issues and leave the less important issues unfixed. Note that RISC-V International owns the RISC-V ISA, but doesn't have technical staff, so we rely on volunteers to fix issues. Volunteers aren't always available when we need them. Things are starting to get better now with some contributions from Rivos, but it may be a while before the backlog of known issues can be addressed. Rivos is working on a fix for one of the major pending items, subword atomic support.

If we need this fixed for SPEC CPU 2017 then that will certainly make the issue more important to fix. I haven't heard anyone else complain about SPEC CPU 2017 issues yet though.

I would suggest adding comments to the FSF GCC bug. The GNU toolchain developers are at gcc.gnu.org not here, so putting stuff here isn't the best way to get attention to a bug that needs fixing.

[shioyadan]

I think the reason why no one else has reported this issue is because not many people have tried it. The people who are compiling and actively evaluating SPEC CPU 2017 on RISC-V may be mainly researchers like me at the moment, and I believe the number is very small. SPEC CPU are not open, so testing them is likely not easy for someone not in a research institute or company. Also, while there is the open implementation of WRF, not many people try to compile a program written in Fortran on RISC-V.

I mistakenly thought that many people were developing the toolchains, but I didn't realize there is such a shortage of developers. I'm sorry for the lack of consideration.

I will follow your suggestion and add my comments to the FSF GCC bug report. I reported the problem here because I saw that several RISC-V cross-compiler problems had been reported here and had been resolved.

I know that it is difficult, but if it is possible, I would even attempt to make a patch myself.

Thank you for your detailed explanation.

[TommyMurphyTM1234]

This is a known problem. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062

Since the problem is already logged upstream I propose the closure of this issue.

[shioyadan]

I agree with you and will close this issue.
Thank you.

[TommyMurphyTM1234]

Thanks @shioyadan.