[Bug inline-asm/56621] New: Misaligned stack with inline assembly

["auc42 at yahoo dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56621

             Bug #: 56621
           Summary: Misaligned stack with inline assembly
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: auc42@yahoo.com


The following minimal program (compiled merely by "gcc test.c -o test") is
intended to write "test" to standard output using the write system call, and
then exit:

int main() {
    int tmp;
    char message[8] = "test\n";
    int message_size = 5;

    // Comment out this loop and it suddenly works correctly.
    for (tmp = 0; tmp < 1; ++tmp) { }

    __asm__ __volatile__
    (
        "movq $1, %%rax;"       // System call 1 (write)
        "movq $1, %%rdi;"       // File descriptor 1 (stdout)
        "movq %0, %%rsi;"       // %0 is message
        "movq %1, %%rdx;"       // %1 is message_size
        "syscall"
        :
        : "q"(message), "g"(message_size)
        : "%rax", "%rdi", "%rsi", "%rdx", "%rcx", "%r11"
    );

    return(0);
}

This version produces no output, and exits immediately.  If the marked "for"
loop is commented out, the program *does* produce the expected output. 
(Obviously, the original version where I discovered this problem had a loop
that did actual work).

Examining the binary via objdump (or the intermediate test.s file when
preserving temporary files), I find that it uses an instruction of "movq
-8(%rbp), %rdx" in the non-working version, as compared to "movq -4(%rbp,
%rdx)" in the working version.  Similarly, the initial assignment is done by an
offset of -8 or -4 in the stack, respectively.  If I directly edit the binary
file to change the instruction to the correct offset, the non-working version
then starts working as expected.

This problem is present in the default Debian "wheezy" gcc version 4.7.2
(output of gcc -v below); it is also present in the latest development version
as of the time of this bug report, which I downloaded and compiled in order to
test the problem.  The bug is *not* present in the Debian "squeeze" version
4.4.5 of gcc, so I can only conclude that this became an issue somewhere in an
intervening version.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)