Hi,
As PR113100 shows, the unbiasing introduced by r14-6737 can
cause the scrubbing to overrun and screw some critical data
on stack like saved toc base consequently cause segfault on
Power.
By checking PR112917, IMHO we should keep this unbiasing
guarded under SPARC_STACK_BOUNDARY_HACK (TARGET_ARCH64 &&
TARGET_STACK_BIAS), similar to some existing code special
treating SPARC stack bias.
Bootstrapped and regtested on x86_64-redhat-linux and
powerpc64{,le}-linux-gnu. All reported failures in
PR113100 are gone. I also expect the culprit commit can
affect those ports with nonzero STACK_POINTER_OFFSET.
Is it ok for trunk?
BR,
Kewen
-----
PR middle-end/113100
gcc/ChangeLog:
* builtins.cc (expand_builtin_stack_address): Guard stack point
adjustment with SPARC_STACK_BOUNDARY_HACK.
---
gcc/builtins.cc | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 125ea158ebf..9bad1e962b4 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -5450,6 +5450,7 @@ expand_builtin_stack_address ()
rtx ret = convert_to_mode (ptr_mode, copy_to_reg (stack_pointer_rtx),
STACK_UNSIGNED);
+#ifdef SPARC_STACK_BOUNDARY_HACK
/* Unbias the stack pointer, bringing it to the boundary between the
stack area claimed by the active function calling this builtin,
and stack ranges that could get clobbered if it called another
@@ -5476,7 +5477,9 @@ expand_builtin_stack_address ()
(caller) function's active area as well, whereas those pushed or
allocated temporarily for a call are regarded as part of the
callee's stack range, rather than the caller's. */
- ret = plus_constant (ptr_mode, ret, STACK_POINTER_OFFSET);
+ if (SPARC_STACK_BOUNDARY_HACK)
+ ret = plus_constant (ptr_mode, ret, STACK_POINTER_OFFSET);
+#endif
return force_reg (ptr_mode, ret);
}
--
2.39.3
