[cfe-commits] Alignment of return from __builtin_alloca

[Chandler Carruth]

On Thu, Jun 7, 2012 at 3:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Thu, Jun 7, 2012 at 3:20 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> > On Thu, Jun 7, 2012 at 3:08 PM, David Sehr <sehr at google.com> wrote:
> >>
> >> Please disregard my last comment.  Implementing that will be a bit
> >> challenging, as stackAlign is a back end value rather than a clang
> >> TargetInfo value. Are there targets where stackAlign < SuitableAlign?
> >
> >
> > I suspect so, and that's worrisome...
> >
> > I'm not intimately familiar with stack alignment and Joerg's concerns,
> but
> > it seems like a *more* aligned alloca would be fine, but a less aligned
> > alloca would be bad. Why is it a bad thing to increase the alignment to
> > SuitableAlign?
>
> It would probably be surprising if __builtin_alloca triggered stack
> realignment...
>

I see the surprise, but the alternative shouldn't be to return
under-aligned pointers from __builtin_alloca. Trivial program demonstrating
the behavior of GCC that is likely depended on:

% cat alloca_test.c#include <stdio.h>

int main() {
  char a;
  printf("%p\n", __builtin_alloca(1));
  int arr1[16];
  char b;
  printf("%p\n", __builtin_alloca(2));
  int arr2[16];
  char c;
  printf("%p\n", __builtin_alloca(4));
  int arr3[16];
  char d;
  printf("%p\n", __builtin_alloca(8));
  int arr4[16];
  char e;
  printf("%p\n", __builtin_alloca(16));
  int arr5[16];
  char f;
  printf("%p\n", __builtin_alloca(32));
}
% ./bin/clang -o alloca_test alloca_test.c -m32 &&
./alloca_test0xffdfe5220xffdfe5200xffdfe51c0xffdfe5140xffdfe5040xffdfe4e4
% gcc -o alloca_test alloca_test.c -m32 &&
./alloca_test0xffa897700xffa897500xffa897300xffa897100xffa896f00xffa896c0


I think we either need to realign the stack or over-allocate the alloca and
adjust the pointer to the desired alignment...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120607/22093efb/attachment.html>