Open federeghe opened 8 years ago
How so? That's your last printf call, and it's targetting printf; compute doesn't clobber x12
Is it possible that x12 is overwritten by the printf itself? The address in x12 is calculated before the first printf, but it isn't recalculated before the subsequent call to printf, so x12 may contain invalid address if printf uses it.
You're probably right yeah. If x12 is caller-saved, then main is failing to save it around the printf, and if it's callee-saved, then main is failing to save it. Not sure which version of the calling convention LLVM presently implements.
I think it is the last calling convention of RISCV implemented in f4c04eec45a3cf50fd709435cea60ab58c5b95e9. In fact, x12 is caller-saved but it seems that the backend interprets it as callee-saved.
I'm trying to figure out where is the error in the code, but I'm not an expert of LLVM, so it's quite difficult.
I had the same problem.
I found a commit (ce8ac4e) in a different branch (caller-saved-fix) that seems to fix the bug that you and I had.
Not sure why the additional spill slots were added (lib/Target/RISCV/RISCVFrameLowering.cpp) but the rest makes sense.
I don't know also why this branch (caller-saved-fix) was not merged with the riscv-trunk branch.
Note, this repository does not have an active maintainer.
I came here to find a solution for a bug which I found on dhrystone.
...
94 strcpy (Ptr_Glob->variant.var_1.Str_Comp,
95 "DHRYSTONE PROGRAM, SOME STRING");
96 strcpy (Str_1_Loc, "DHRYSTONE PROGRAM, 1'ST STRING");
...
This lines were compiled to; (strcpy(dst, src) is converted to memcpy(dst, src, size))
...
204000e2: 20404337 lui t1,0x20404
204000e6: 7f030593 addi a1,t1,2032 # 204047f0 <__clzsi2+0x66>
204000ea: 01028513 addi a0,t0,16
204000ee: 467d li a2,31 // the 3rd arg, size
204000f0: 386010ef jal ra,20401476 <memcpy> // a2 is overwritten by the callee
204000f4: 204052b7 lui t0,0x20405
204000f8: 80f28593 addi a1,t0,-2033 # 2040480f <__clzsi2+0x85>
204000fc: 06c40513 addi a0,s0,108
20400100 <Ltmp15>:
20400100: 376010ef jal ra,20401476 <memcpy> // a2 should be 31
...
The commit (ce8ac4e) fixed this issue.
Note, this repository does not have an active maintainer.
This is a bad news...
Hi! I think there is a problem in riscv-trunk when compiled with -O1 option. I attached an example in c and the generated assembly.
I compile with:
/.../clang -O1 -target riscv -mriscv=RV32I test.c -S -o test.S /.../riscv32-unknown-elf-gcc test.S -o test.o
I think that the last jalr (line 42) jumps to a wrong address.
test.zip