gcc x64 linux code generation (passing pointer var-args) bug

[Reuben Hawkins <reubenhwk@gmail.com>]

Hi Overseers,

I ran into an issue with all versions of gcc which support x64 which
*could* be considered a bug.  At the very least, it's a pitfall.  I'm
not really sure to whom I should bring this problem to.  Bugzilla?
Mailing list?  Not sure...

Anyway, the gist of the bug is this...

printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, 0);

The first 5 zero ints are copied into the esi, edx, ecx, r8d and r9d,
(as the linux x64 calling convention mandates) with the movl
instruction.  The movl instruction will zero out the upper 32-bits of
those registers.  The last zero int, however is copied to (%rsp) with
movl, which does *not* zero out the upper 32 bits because (%rsp) is
not a register, so the last 0 is not promoted to a 64-bit zero, but
the rest of the zeros are.  If I were to add another zero, that zero
would be copied to 8(%rsp), so the upper 32-bits of (%rsp) are skipped
and whatever garbage happens to be there is passed to the called
function.

printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, (void*)0);

...works because the (void*) causes gcc to emit a movq instruction.

I'm wondering if there's a possibility to change this unexpected
behavior in gcc such that it always uses movq on stack args.

I realize all the zeros are technically wrong, they should be either
NULL or (void*) casts, but it's a huge pain that '0' works for the
first 6 args, then doesn't on the 7th when the args start going on the
stack.

Thanks in advance,
Reuben Hawkins