title: Why does GCC subtract the wrong value to the stack pointer when allocating a big array with no subsequent function calls?
body: <p>Really bizarre gcc quirk. Check this out:</p>
  
  <pre><code>main() { int a[100]; a[0]=1; }
  </code></pre>
  
  <p>produces this assembly:</p>
  
  <pre><code>   0:   55                      push   %rbp
     1:   48 89 e5                mov    %rsp,%rbp
     4:   48 81 ec 18 01 00 00    sub    $0x118,%rsp
     b:   c7 85 70 fe ff ff 01    movl   $0x1,-0x190(%rbp)
    12:   00 00 00 
    15:   c9                      leaveq 
    16:   c3                      retq
  </code></pre>
  
  <p>The top of the stack is clearly 400, since its a 100 * 4 array. So when it writes to the first entry, it does rbp - 400 (line 'b'). Good. But why does it subtract 280 from the stack (line '4') pointer? Doesn't that point to the middle of the array?</p>
  
  <p>If we add a function call afterward, gcc does the right thing:</p>
  
  <pre><code>b() {}
  main() { int a[100]; a[0]=1; b(); }
  </code></pre>
  
  <p>produces this assembly:</p>
  
  <pre><code>0000000000000000 &lt;b&gt;:
     0:   55                      push   %rbp
     1:   48 89 e5                mov    %rsp,%rbp
     4:   c9                      leaveq 
     5:   c3                      retq   
  
  0000000000000006 &lt;main&gt;:
     6:   55                      push   %rbp
     7:   48 89 e5                mov    %rsp,%rbp
     a:   48 81 ec 90 01 00 00    sub    $0x190,%rsp
    11:   c7 85 70 fe ff ff 01    movl   $0x1,-0x190(%rbp)
    18:   00 00 00 
    1b:   b8 00 00 00 00          mov    $0x0,%eax
    20:   e8 00 00 00 00          callq  25 &lt;main+0x1f&gt;
    25:   c9                      leaveq 
    26:   c3                      retq 
  </code></pre>
  
  <p>Here, it properly subtracts 400 (line 'a').</p>
  
  <p>Why the change when you add a function call? Is gcc just lazy, and doesn't do it right because it doesn't matter? What's happening? Evidently this only happens when compiling for x86_64, but not for plain x86. Does this have something odd to do with x86_64's "redzone"? What's happening precisely?</p>