为什么在arm组装中gcc会分配更多堆栈？

我正在尝试读取用ARM汇编编写的gcc的输出。
以下输出对我来说似乎很奇怪

int succ (int *arr)
{
  return arr[0] + 1;
}

int main (int argc)
{
  int a[1] = { argc };
  return succ (a);
}

通过编译命令gcc-fno inline-O2-S，生成以下汇编程序。 我省略了output about

succ

，因为它与我的问题无关（只是为了停止消除未使用的变量

a

）

这个

main

函数似乎为本地数组

a

（子sp，sp，#12）分配了3个字节。 但是我的C程序只为

a

分配一个int元素
其他时间值似乎不使用堆栈。 为什么这个程序需要比我预期的更多的堆栈容量

我的gcc版本是4.8.5。我在rasberry pi 3中试过raspbian

更新
当我将数组

a

的长度修改为2（

inta[2}={argc，argc}

）时，卷没有改变（只有3个字节）。
对于长度3（

inta[3}={argc，argc，argc}

），堆栈中分配了5个字节

---

这对我来说很奇怪。

前几天我也看到了类似的情况。我怀疑发生的事情是它将lr放在堆栈上。它需要将其与64位边界对齐，这样它就需要在堆栈上再增加4个字节。然后它需要4个字节用于a，并且需要将其对齐，以便在堆栈上添加4个字节，而没有意识到lr加上a就是全部他们需要分配资金

---

我将不得不看看我是否能够以不同的方式再现这一点。

，x86和arm后端是两个独立的东西。

sub-sp，sp，#12

“分配”12个字节，或3个字（arm字=32位=4个字节）。1个字节=8位，几乎是您当前在现实世界中遇到的所有东西（撇开一些博物馆或故意的模糊不谈）。此外，.的确，使

succ

静态会大大改变事情。使它

静态

会给编译器一个提示，它不会调用外部函数，也不需要堆栈框架（保存

lr

）。编译器还会尝试保持数组64位对齐。如果访问从64位开始，则数组的效率更高。如果需要，请使用

-Os

或使用其他代码生成选项进行编译。

main:frame=8

    .global main
    .type   main, %function
main:
    @ args = 0, pretend = 0, frame = 8
    @ frame_needed = 0, uses_anonymous_args = 0
    str     lr, [sp, #-4]!
    sub     sp, sp, #12
    add     r3, sp, #8
    str     r0, [r3, #-4]!
    mov     r0, r3
    bl      succ
    add     sp, sp, #12
    @ sp needed
    ldr     pc, [sp], #4
    .size   main, .-main