Re: [3.1.1] Re: GCC performance regression - its memset!

[Glen Nakamura <glen at imodulo dot com>]

> This looks to be an endian issue.
> 
> Some code:
> ------------- CUT ----------------
> #include <stdio.h>
> 
> void foo(void *x, int y)
>    {
>    __builtin_memset(x, 0, y);
>    }
> 
> int main()
>    {
>    int x[2] = { 0x5a5a5a5a, 0x5a5a5a5a };
>    printf("%08X %08X\n", x[0], x[1]);
>    foo(x, 5);
>    printf("%08X %08X\n", x[0], x[1]);
>    return 0;
>    }
> ------------- CUT ----------------
> 
> Let's try this on x86:
> 
> 5A5A5A5A 5A5A5A5A
> 00000000 5A5A5A00
> 
> And again on SPARC:
> 
> 5A5A5A5A 5A5A5A5A
> 00000000 005A5A5A
> 
> where it comes out what you expect, at least if you expect what I expect
> (or something...)
> 
> And, honestly, I'm not sure if this is how it's supposed to be or not.
> What are the rules for doing a memset across part of an object? Certainly,
> in both cases it sets 5 bytes to zero, and those bytes are contiguous in
> memory. The thing is, I can't imagine how you could actually change this on
> x86 to work like it does on a big-endian machine, because you would have to
> know the size of the type involved.
> 
> HTH,
>   -Jack
> 

Actually, the failure occurs with gcc-3.1 on x86 when compiling with -O2.
I would expect the following output from your example:

5A5A5A5A 5A5A5A5A
00000000 5A5A5A5A

Only the first 4 bytes are set...

- Glen Nakamura