[Bug debug/111680] DWARF information inconsistent with the generated RISC-V Binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111680 --- Comment #9 from Andrew Pinski --- (In reply to King Lok Chung from comment #8) > It also looks like to me that the compiler is trying to be smart and save > one register use by reusing the SP, resulting in two SP offsets. In reality, > it could have used a6 or a7 easily. Kinda of, the issue is `addisp,sp,` has a limit for its immediate for the add (you can't just add -2080 to sp). So the backend decides to 2 `addi` and that confuses the rest of the middle-end. Note other backends do is rather: Create the immediate in a register and then does the add to the sp to get the increment. That is how MIPS, AARCH64, rs6000, etc. implement the big stack increments and does not confuse the rest of the GCC. Anyways this should be fixed either by changing the riscv backend or fixing the dwarf2 pass to do the correct thing (or maybe both).
[Bug debug/111680] DWARF information inconsistent with the generated RISC-V Binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111680 --- Comment #8 from King Lok Chung --- It also looks like to me that the compiler is trying to be smart and save one register use by reusing the SP, resulting in two SP offsets. In reality, it could have used a6 or a7 easily. Or might be the SP value is similar to the pointer address, which the compiler trying take advantage of? This is just pure guessing.
[Bug debug/111680] DWARF information inconsistent with the generated RISC-V Binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111680 --- Comment #7 from Andrew Pinski --- Note I think most other targets create the stack offset in a register and then do the add to the sp rather than having 2 add to sp which might be the reason why this has not been seen until now too ...
