[Bug target/24675] Stack corruption in ARM arch. if 64bit variable is passed to a function of which the low 32 use the register and the up 32 use the stack

[armcc2000 at yahoo dot com]

------- Comment #7 from armcc2000 at yahoo dot com  2005-11-09 23:32 -------
(In reply to comment #4)
>
> I think this is a dup of bug 23150 which was fixed in 4.1.0.
> 

Something has certainly changed in 4.1 - the stack corruption is gone.
With -Os, the good() and bad() testcases compile to:

------------------------------------------------------------

bad:
        @ args = 8, pretend = 4, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        sub     sp, sp, #4
        str     lr, [sp, #-4]!
        mov     ip, #0
        sub     sp, sp, #8
        str     r3, [sp, #12]
        mov     r0, ip
        mov     r1, ip
        mov     r2, ip
        mov     r3, ip
        str     ip, [sp, #0]
        str     ip, [sp, #4]
        bl      foo
        add     sp, sp, #8
        ldr     lr, [sp], #4
        add     sp, sp, #4
        bx      lr

good:
        @ args = 4, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        str     lr, [sp, #-4]!
        mov     ip, #0
        sub     sp, sp, #8
        mov     r0, ip
        mov     r1, ip
        mov     r2, ip
        mov     r3, ip
        str     ip, [sp, #0]
        str     ip, [sp, #4]
        bl      foo
        add     sp, sp, #8
        ldmfd   sp!, {pc}

        .ident  "GCC: (GNU) 4.1.0 20051105 (experimental)"

------------------------------------------------------------

The bug with previous compilers seems to be that the amount of stack space
already allocated by the caller was over estimated by the callee (ie
incorrectly calculated to be 8 bytes instead of 4 - as if the entire long long
param is passed on the stack when in fact only half of it has been).

However with 4.1, neither good() or bad() make any use of the 4 bytes of stack
already allocated for them by their caller ??. They both assume they start off
with 0 bytes allocated to them and then correctly allocate as required.

Therefore it seems that 4.1 is generating correct code because of a missing
optimisation that was present in previous versions ??

------------------------------------------------------------

As an aside, if gcc were smart enough, I believe good() and bad() should
compile to exactly the same assembler, so there's still some optimisation
tweaks that could be done... ;-)

------------------------------------------------------------


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24675