public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jeff Law <law@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-4368] RISC-V: fix stack access before allocation. Date: Mon, 28 Nov 2022 16:33:42 +0000 (GMT) [thread overview] Message-ID: <20221128163342.C16843853D7C@sourceware.org> (raw) https://gcc.gnu.org/g:f7a41b5cfd7406da1f2e5a0f1f813521d3dc2bb2 commit r13-4368-gf7a41b5cfd7406da1f2e5a0f1f813521d3dc2bb2 Author: Fei Gao <gaofei@eswincomputing.com> Date: Mon Nov 28 11:31:09 2022 -0500 RISC-V: fix stack access before allocation. In current riscv stack frame allocation, 2 steps are used. The first step allocates memories at least for callee saved GPRs and FPRs, and the second step allocates the rest if stack size is greater than signed 12-bit range. But it's observed in some cases, like gcc.target/riscv/stack_frame.c in my patch, callee saved FPRs fail to be included in the first step allocation, so we get generated instructions like this: li t0,-16384 addi sp,sp,-48 addi t0,t0,752 ... fsw fs4,-4(sp) #issue here of accessing before allocation ... add sp,sp,t0 "fsw fs4,-4(sp)" has issue here of accessing stack before allocation. Although "add sp,sp,t0" reserves later the memory for fs4, it exposes a risk when an interrupt comes in between "fsw fs4,-4(sp)" and "add sp,sp,t0", resulting in a corruption in the stack storing fs4 after interrupt context saving and a failure to get the correct value of fs4 later. This patch fixes issue above, adapts testcases identified in regression tests, and add a new testcase for the change. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_first_stack_step): Fix computation of MIN_FIRST_STEP to cover FP save area too. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr93304.c: Adapt testcase for the change, constrain match to assembly instructions only. * gcc.target/riscv/rvv/base/spill-11.c: Adapt testcase for the change. * gcc.target/riscv/stack_frame.c: New test. Diff: --- gcc/config/riscv/riscv.cc | 2 +- gcc/testsuite/gcc.target/riscv/pr93304.c | 2 +- gcc/testsuite/gcc.target/riscv/rvv/base/spill-11.c | 3 +-- gcc/testsuite/gcc.target/riscv/stack_frame.c | 26 ++++++++++++++++++++++ 4 files changed, 29 insertions(+), 4 deletions(-) diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc index 7bfc0e9f595..74612a701b0 100644 --- a/gcc/config/riscv/riscv.cc +++ b/gcc/config/riscv/riscv.cc @@ -4903,7 +4903,7 @@ riscv_first_stack_step (struct riscv_frame_info *frame) return frame_total_constant_size; HOST_WIDE_INT min_first_step = - RISCV_STACK_ALIGN ((frame->total_size - frame->fp_sp_offset).to_constant()); + RISCV_STACK_ALIGN ((frame->total_size - frame->frame_pointer_offset).to_constant()); HOST_WIDE_INT max_first_step = IMM_REACH / 2 - PREFERRED_STACK_BOUNDARY / 8; HOST_WIDE_INT min_second_step = frame_total_constant_size - max_first_step; gcc_assert (min_first_step <= max_first_step); diff --git a/gcc/testsuite/gcc.target/riscv/pr93304.c b/gcc/testsuite/gcc.target/riscv/pr93304.c index ce2dc4d6921..76975ff81c5 100644 --- a/gcc/testsuite/gcc.target/riscv/pr93304.c +++ b/gcc/testsuite/gcc.target/riscv/pr93304.c @@ -16,4 +16,4 @@ foo (void) regradless of the REG_ALLOC_ORDER. In theory, t2 should not used in such small program if regrename not executed incorrectly, because t0-a2 should be enough. */ -/* { dg-final { scan-assembler-not "t2" } } */ +/* { dg-final { scan-assembler-not {\t[a-zA-Z0-9]+\t.*t2} } } */ diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/spill-11.c b/gcc/testsuite/gcc.target/riscv/rvv/base/spill-11.c index c2f68b86d90..f5223491665 100644 --- a/gcc/testsuite/gcc.target/riscv/rvv/base/spill-11.c +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/spill-11.c @@ -21,9 +21,8 @@ void fn3 (char*); ** slli\tt1,t0,1 ** add\tsp,sp,t1 ** li\tt0,8192 -** addi\tt0,t0,-208 +** addi\tt0,t0,-192 ** add\tsp,sp,t0 -** addi\tsp,sp,16 ** tail\t__riscv_restore_2 */ int stack_save_restore_2 (float a1, float a2, float a3, float a4, diff --git a/gcc/testsuite/gcc.target/riscv/stack_frame.c b/gcc/testsuite/gcc.target/riscv/stack_frame.c new file mode 100644 index 00000000000..485a52d5133 --- /dev/null +++ b/gcc/testsuite/gcc.target/riscv/stack_frame.c @@ -0,0 +1,26 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -march=rv32imafc -mabi=ilp32f" } */ +char my_getchar(); +float getf(); + +float foo() +{ + char volatile array[3120]; + float volatile farray[3120]; + float sum = 0; + float f1 = getf(); + float f2 = getf(); + float f3 = getf(); + float f4 = getf(); + + for (int i = 0; i < 3120; i++) + { + array[i] = my_getchar(); + farray[i] = my_getchar() * 1.2; + sum += array[i] + farray[i] + f1 + f2 + f3 + f4; + } + + return sum; +} + +/* { dg-final { scan-assembler-not {,-[0-9]+\(sp\)} } } */
reply other threads:[~2022-11-28 16:33 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20221128163342.C16843853D7C@sourceware.org \ --to=law@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).