[llvm-bugs] [Bug 31347] New: AVR-GCC calling convention mismatch with stack

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=31347

            Bug ID: 31347
           Summary: AVR-GCC calling convention mismatch with stack
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: AVR
          Assignee: unassignedbugs at nondot.org
          Reporter: dylanmckay34 at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

The calling convention for picking registers for arguments is described at
(https://gcc.gnu.org/wiki/avr-gcc).

I've found a mismatch between when AVR-GCC loads arguments from the stack, and
when we do.

AVR-GCC Test case:
avr-gcc -S tmp.c -o tmp.s -O2


#include <stdint.h>

typedef uint8_t i8;
typedef uint16_t i16;
typedef uint32_t i32;
typedef uint64_t i64;

void thing(i64 a, i64 b) {
  *((i64*)0x4) = b;
}

This generates the following assembly to load argument 'b' from the stack

/* prologue: function */
/* frame size = 0 */
/* stack size = 8 */
.L__stack_usage = 8
    ldi r30,lo8(4)
    ldi r31,0
    st Z,r10
    std Z+1,r11
    std Z+2,r12
    std Z+3,r13
    std Z+4,r14
    std Z+5,r15
    std Z+6,r16
    std Z+7,r17

AVR-LLVM example:

define void @ret_void_args_i64_i64(i64 %a, i64 %b) {
  store volatile i64 %b, i64* inttoptr (i64 4 to i64*)
  ret void
}

This generates the following assembly:


        sts     4, r18
        sts     11, r17
        sts     10, r16
        sts     9, r15
        sts     8, r14
        sts     7, r13
        sts     6, r12
        sts     5, r11
        sts     4, r10
        ret

Clearly, we aren't following the calling convention in this case. We should be
loading 'b' from the stack.

This will break programs which take large numbers/big arguments on the stack.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161211/6a8960da/attachment.html>