The probe_stack pattern uses r0 as a fixed register. This can cause
issues if we have auto-increment instructions coming out that have r0 as
the base register.
Tested with a bootstrap and regression run. richi reports that the
original issue was fixed in the run. I did consider whether
probe_stack_range was affected but it all comes back to probe_stack
pattern so I think we are ok.
I don't have a testcase that seems to provoke this but it seems to be
default on most distributions so I'm expecting the testcoverage to come
from there.
Applied to trunk.
Ramana
PR target/82248
* config/arm/arm.md (probe_stack) : Change to using the 'o' constraint.
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 545ee257699..d60c5af551c 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -8612,8 +8612,11 @@
(set_attr "type" "block")]
)
+;; Since we hard code r0 here use the 'o' constraint to prevent
+;; provoking undefined behaviour in the hardware with putting out
+;; auto-increment operations with potentially r0 as the base register.
(define_insn "probe_stack"
- [(set (match_operand:SI 0 "memory_operand" "=m")
+ [(set (match_operand:SI 0 "memory_operand" "=o")
(unspec:SI [(const_int 0)] UNSPEC_PROBE_STACK))]
"TARGET_32BIT"
"str%?\\tr0, %0"
