Bug 30855 - gcc changes code order
gcc changes code order
Status: RESOLVED DUPLICATE of bug 21920
Product: gcc
Classification: Unclassified
Component: c
4.1.1
: P3 major
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-19 01:55 UTC by Mihai Donțu
Modified: 2007-02-19 09:05 UTC (History)
11 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mihai Donțu 2007-02-19 01:55:06 UTC
gcc changes the logical order of the code.
I have a 16 byte structure on which I use a macro version of bzero() that looks like this:

#define lipc_bzero( __buf, __size )                                     \
        {                                                               \
                size_t __i = ( ( __size ) >> ( sizeof( long ) >> 1 ) ); \
                while ( ( __i-- ) > 0 ) {                               \
                        ( ( long * )__buf )[__i] = ( long )0;           \
                }                                                       \
        }

and I use it like this:

/* > code */

struct header_t a;
my_bzero( &a, sizeof( a ) );
a.id = 0x4350494c;
a.rid = handle->rid; /* a 32bit random number */
a.st_size = sizeof( a );
a.size = 1024;
lipc_send( s, &a, sizeof( a ), MSG_NOSIGNAL, -1 );

/* < code */

if I compile the code with: "-c -ansi -g -std=gnu99 -fPIC -DPIC -D_REENTRANT -Os -ffast-math" the asm code is:


;; [snip]-------------------------------------------
        .loc 1 469 0
        leal    -28(%ebp), %ecx
        movl    $0, -4(%ecx,%eax,4)
        decl    %eax
        jne     .L46
.LBE9:
        .loc 1 470 0
        movl    $1129335116, -28(%ebp)
        .loc 1 477 0
        subl    $12, %esp
        .loc 1 471 0
        movl    8(%esi), %eax
        .loc 1 472 0
        movl    $16, -20(%ebp)
        .loc 1 473 0
        movl    %edi, -16(%ebp)
        .loc 1 471 0
        movl    %eax, -24(%ebp)
        .loc 1 477 0
        leal    24(%ebp), %eax
        movl    44(%esi), %edx
        pushl   %eax
        movl    $16, %eax
        pushl   $16384
        subl    %edx, %eax
        pushl   %eax
        leal    (%ecx,%edx), %edx
        pushl   %edx
        pushl   (%esi)
.LCFI23:
        call    lipc_send@PLT
;; [snip] ---------------------------------

and works as a charm, but if add "-funroll-loops" (to unroll the lipc_bzero()), the asm is:

;; [snip]----------------------------
.LBB10:
        .loc 1 470 0
        movl    $1129335116, -28(%ebp)
        .loc 1 477 0
        subl    $12, %esp
        .loc 1 471 0
        movl    8(%esi), %ecx
        .loc 1 477 0
        leal    24(%ebp), %eax
.LVL26:
        pushl   %eax
        pushl   $16384
        leal    -28(%ebp,%edx), %eax
        .loc 1 471 0
        movl    %ecx, -24(%ebp)
        .loc 1 477 0
        movl    $16, %ecx
        subl    %edx, %ecx
        pushl   %ecx
        pushl   %eax
        .loc 1 472 0
        movl    $16, -20(%ebp)
        .loc 1 473 0
        movl    %edi, -16(%ebp)
        .loc 1 477 0
        pushl   (%esi)
.LBB11:
        .loc 1 469 0
        movl    $0, -16(%ebp)
        movl    $0, -20(%ebp)
        movl    $0, -24(%ebp)
        movl    $0, -28(%ebp)
.LBE11:
        .loc 1 477 0
.LCFI23:
        call    lipc_send@PLT
;; [snip]----------------------------------------
 
In other words, the code became:

struct header_t a;
a.id = 0x4350494c;
a.rid = handle->rid; /* a 32bit random number */
a.st_size = sizeof( a );
a.size = 1024;
my_bzero( &a, sizeof( a ) );
lipc_send( s, &a, sizeof( a ), MSG_NOSIGNAL, -1 );

I did not read every bug in the database, but I think this is new (or not :)).
I'm sorry I can't give you the whole code, but I will try to help in any other way.

Regards,
Mihai
Comment 1 Andrew Pinski 2007-02-19 02:12:33 UTC
You are violating C aliasing rules, use -fno-strict-aliasing or fix the code so you don't violate the rules.

*** This bug has been marked as a duplicate of 21920 ***
Comment 2 Mihai Don&#539;u 2007-02-19 09:05:43 UTC
Oh. I never gave much thought to these aliasing rules so I guess it was about time one of them slapped me in the face :)

Thanks,

Mihai