long long int in va_arg is not passed correctly

[fxcoudert]

$ cat va-arg-8.c 
#include <stdarg.h>
#include <stdio.h>

void
debug(int i1, int i2, int i3, int i4, int i5,
      int i6, int i7, int i8, int i9, ...)
{
  va_list ap;
  int i10;
  long long int ill;

  va_start (ap, i9);

  i10 = va_arg (ap,int);
  ill = va_arg (ap, long long int);
  //printf("%d\n", i10);
  //printf("%llx\n", ill);
  if (i10 != 10)
    __builtin_abort ();
  if (ill != 0x123400005678LL)
    __builtin_abort ();

  va_end (ap);
}

int
main(void)
{
  debug(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 0x123400005678LL);
}
$ ./bin/gcc va-arg-8.c && ./a.out
zsh: abort      ./a.out

i10 gets passed correctly, but the long long int argument is passed as 0x567800000000LL instead of 0x123400005678LL.

[iains]

$ cat va-arg-8.c 
#include <stdarg.h>
#include <stdio.h>

void
debug(int i1, int i2, int i3, int i4, int i5,
      int i6, int i7, int i8, 

^ these will be passed in x0..x7

int i9, ...)

^^^ this will be passed as 4 bytes on the stack (leaving the stack misaligned)

int 10 - should force the stack to be aligned to 8 bytes (since it's unnamed at passing) it should also force the stack slot to be 8 bytes....
(which would mean that we'd expect the literal long long to be in the correct place...)

My guess is that the call is DTRT but the function lowering is failing to force-align the unnamed parts, somehow (but it could be the opposite - this is the messy part of the normal c.f. variadic).

[fxcoudert]

I split caller and callee in two files, but compiling one with GCC and the other one with clang fails both ways:

$ clang caller.c function.c && ./a.out
$ ./bin/gcc caller.c function.c && ./a.out  
zsh: abort      ./a.out
$ ./bin/gcc -c function.c 
$ clang caller.c function.o && ./a.out   
zsh: abort      ./a.out
$ clang -c function.c 
$ ./bin/gcc caller.c function.o && ./a.out
zsh: abort      ./a.out

[iains]

yes, the implementation is broken - failing to pad the packed stack argument when we transition to the 'unnamed regime'. Not sure if it's going to be fixable with the current hacks, might need a proper solution to issue #4

[iains]

should be fixed by 91df520

NOTE: the real fix is to solve #4 - but it's useful to chase down the corner cases.