[PATCH] PR target/109402: v850 (not v850e) variant of __muldi3() moves sp in reversed direction [PR109402]

[PATCH] PR target/109402: v850 (not v850e) variant of __muldi3() moves sp in reversed direction [PR109402]

[ポニー電機(株) 星野]

Where I talk about is: /libgcc/config/v850/lib1funcs.S L2214, L2259 - in a commit 8b1204d7.

There are stack-pointer operations.
I think these operations: shrink before, grow after --- may reversed way.
There is one more consideration; this version of __muldi3() does not use
local storage in stack. So the problem will be resolved simply to remove sp-operations.

I have no idea to show a reproduce way in shortly.
Because a problem happens with inter-procedure such as interrupt service routines which use storage in stack.

In my environment, the next patch works well.

---

diff --git a/libgcc/config/v850/lib1funcs.S b/libgcc/config/v850/lib1funcs.S
index 00dd61d..99e79bf 100644
--- a/libgcc/config/v850/lib1funcs.S
+++ b/libgcc/config/v850/lib1funcs.S
@@ -2211,7 +2211,6 @@
 ___muldi3:
 #ifdef __v850__
         jarl  __save_r26_r31, r10
-        addi  16,  sp, sp
         mov   r6,  r28
         shr   15,  r28
         movea lo(32767), r0, r14
@@ -2256,7 +2255,6 @@
         mulh  r12, r6
         mov   r28,  r17
         mulh  r10, r17
-        add   -16, sp
         mov   r28,  r12
         mulh  r8,  r12
         add   r17, r18

Re: [PATCH] PR target/109402: v850 (not v850e) variant of __muldi3() moves sp in reversed direction [PR109402]

[Jeff Law]

On 4/6/23 23:25, ポニー電機(株) 星野 wrote:
> Where I talk about is: /libgcc/config/v850/lib1funcs.S L2214, L2259 - in a commit 8b1204d7.
> 
> There are stack-pointer operations.
> I think these operations: shrink before, grow after --- may reversed way.
> There is one more consideration; this version of __muldi3() does not use
> local storage in stack. So the problem will be resolved simply to remove sp-operations.
> 
> I have no idea to show a reproduce way in shortly.
> Because a problem happens with inter-procedure such as interrupt service routines which use storage in stack.
> 
> In my environment, the next patch works well.
[ ... ]
Thanks for tracking this down!  Presumably when the interrupt occurred 
in that window of instructions you'd end up clobbering saved data on the 
stack.

These kinds of bugs are often difficult to track down.  Thanks for 
taking the time to do so.

I've pushed your patch to the trunk,
Jeff