[Bug c/24282] New: Optimizer ignores register changing (STOSL)

[graeter at hydrixos dot org]

I'm working on a AMD-64 gentoo linux system with gcc 3.4. I have this test
program:

#include <stdio.h>
#include <stdlib.h>

void kmem_zero_out(void *page)
{
        asm ("cld\n"
            "rep stosl\n"
            "movl $0, %%eax\n"
            : 
            : "c" (1024), "a" (0), "D" (page)
            : "memory"
           );
}


int main(void)
{
        void* my_test = malloc(1024*1024);

        printf("0x%X\n", (int)my_test);
        kmem_zero_out(my_test);
        printf("0x%X\n", (int)my_test);

        return 0;
}

It will write the number 0 to a buffer using the STOSL instruction within an
inline assembler section. This will be done by the function kmem_zero_out. This
function gets a pointer "my_test" as a parameter. After the call of
"kmem_zero_out" the parameter was modified by kmem_zero_out without any reason.

If I compile the program with this command-line parameters:

~ $ gcc -finline-functions -std=gnu99 -march=i586 -Wall -fno-pack-struct
-fno-strict-aliasing -fno-zero-initialized-in-bss -O3 -m32 t.c -o testprog 

and execute it, i'll get the wrong output:

~ $ ./testprog
0x556A0008
0x556A1008
~ $ 

If I leave out the "-march=i586" the program will work the right way:

~ $ ./testprog
0xAADE8010
0xAADE8010
~ $ 

However, I've found out, that the optimizer seems not to be aware of changings
in the parameter registers of the inline assembler (in this case the EDI
register). If I modify the EDI register with "mov $0, %edi" the value of
my_text will be set to 0 after the return of kmem_zero_out.


-- 
           Summary: Optimizer ignores register changing (STOSL)
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: graeter at hydrixos dot org
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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