Problem with gcc -O3 please help

[forceael]

Hi everyone,
I ran across a really strange problem with the -O3 optimization of gcc, and I would appreciate any help because I really have a hard time understanding the problem. I have boiled down my considerably longer code to a simple example that shows the behaviour. What it does is simply allocating an array, setting its 0-element to 0 and then setting it to one in a loop that is executed only once. The code

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

int main() {

  int i;
  double R4 = 0;
  int *activedirections;
  int nactive=0;
  int holder;
  activedirections = malloc((2*3+1) *sizeof(int));
  activedirections[0] = 0;
  for (i=1; i<=1; i++) {
      activedirections[nactive] = i;
      nactive++;
  }
  holder = activedirections[0];
  printf("activedirections[0] = %i\n",activedirections[0]);
  printf("activedirections[0] = %i\n",activedirections[0]);
  printf("holder              = %i\n",holder);
  free(activedirections);
}

when compiled with gcc and no options produces:

activedirections[0] = 1
activedirections[0] = 1
holder              = 1

as expected. Compiling with -O3 however yields:

activedirections[0] = 0
activedirections[0] = 1
holder              = 0

I have no idea how a value can change in between two identical printf's

Any help would be great.

Thanks

[sganesh]

I also executed your program using gcc compiler only.

I got same output for both gcc, gcc -O3.
activedirections[0] = 1
activedirections[0] = 1
holder = 1

-O is for optimizing the C code. Which version you are using and Which OS you are using can you explain that.

I am using gcc in Linux OS.

[forceael]

Hey, thank you for trying it out

my /proc/version reads

Linux version 2.6.27.4-X86_64-SMP (root@xxxx) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Tue Oct 28 16:31:30 CET 2008

and gcc -dumpversion outputs
4.3.2


Also the problem also accurs with -O2 but not with -O1

[zacs7]

Most likely "-O3" just unrolled the loop. But it seems to have stuffed it up.

This seems to be a bug in gcc. What does the assembly look like? Which version of gcc?

[Alexander jack]

-O3 is the highest level optimization , first of all we need to find how your code changed after
optimization

[forceael]

What does the assembly look like?

How do I find that out?

I also found that the -Os option produces the strange results.

[sganesh]

I am using 4.1.2 Gcc version.

Actually, for all the optimization level I got only the same results. you are using improvised GCC version. so that only you got some different output I think so.

But I need to work with 4.3.2 or read about that.Then only I can reply.

And If it is possible you can also try with 4.1.2 version and check the difference.

[forceael]

I think this is the assembly:

prog.s

        .file   "prog.c"
        .section        .rodata.str1.1,"aMS",@progbits,1
.LC0:
        .string "activedirections[0] = %i\n"
.LC1:
        .string "holder              = %i\n"
        .text
.globl main
        .type   main, @function
main:
.LFB2:
        pushq   %rbx
.LCFI0:
        movl    $4, %edi
        call    malloc
        xorl    %esi, %esi
        movq    %rax, %rbx
        movl    $1, (%rax)
        movl    $.LC0, %edi
        xorl    %eax, %eax
        call    printf
        movl    (%rbx), %esi
        movl    $.LC0, %edi
        xorl    %eax, %eax
        call    printf
        xorl    %esi, %esi
        movl    $.LC1, %edi
        xorl    %eax, %eax
        call    printf
        movq    %rbx, %rdi
        call    free
        popq    %rbx
        ret
.LFE2:
        .size   main, .-main
        .section        .eh_frame,"a",@progbits
.Lframe1:
        .long   .LECIE1-.LSCIE1
.LSCIE1:
        .long   0x0
        .byte   0x1
        .string "zR"
        .uleb128 0x1
        .sleb128 -8
        .byte   0x10
        .uleb128 0x1
        .byte   0x3
        .byte   0xc
        .uleb128 0x7
        .uleb128 0x8
        .byte   0x90
        .uleb128 0x1
        .align 8
.LECIE1:
.LSFDE1:
        .long   .LEFDE1-.LASFDE1
.LASFDE1:
        .long   .LASFDE1-.Lframe1
        .long   .LFB2
        .long   .LFE2-.LFB2
        .uleb128 0x0
        .byte   0x4
        .long   .LCFI0-.LFB2
        .byte   0xe
        .uleb128 0x10
        .byte   0x83
        .uleb128 0x2
        .align 8
.LEFDE1:
        .ident  "GCC: (Debian 4.3.2-1.1) 4.3.2"
        .section        .note.GNU-stack,"",@progbits

[forceael]

I tried with gcc 4.1.3 and 4.2.4 and both worked fine.
Is there some place I should post it to make the right people aware of it?
I guess this resolves my problem, i will switch to gcc-4.2 and hope nothing else will change...

Thanks for all your help so far

[zacs7]

GCC Bugs - GNU Project - Free Software Foundation (FSF)

[forceael]

I added it to the gcc bug library


Bug 43219 - O2, O3 and Os produce wrong code

see what happens...

[brewbuck]

Hmm.

.LCFI0:
        movl    $4, %edi
        call    malloc
        xorl    %esi, %esi
        movq    %rax, %rbx
        movl    $1, (%rax)
        movl    $.LC0, %edi
        xorl    %eax, %eax
        call    printf
        movl    (%rbx), %esi
        movl    $.LC0, %edi
        xorl    %eax, %eax
        call    printf
        xorl    %esi, %esi
        movl    $.LC1, %edi
        xorl    %eax, %eax
        call    printf
        movq    %rbx, %rdi
        call    free
        popq    %rbx
        ret

Apparently, the second argument is getting passed in %esi. It's obvious from the above that on the first call to printf(), %esi is not getting set to the correct value -- look at the blue line, which is loading the value "1" into the second argument during the second call. The compiler did not do this for the first call.

Bona fide compiler bug, assuming the code you posted is the actual code. These are actually quite rare. Congrats on finding one.

This bug is either in the data-flow analysis portion of the optimizer, or in the peephole optimizer inside the architecture-specific backend, it seems like.