[Bug c/18616] New: Strange optimization issue

[Bug c/18616] New: Strange optimization issue

[manus at eiffel dot com]

I have an optimization bug with gcc 3.4.3 on AMD64. If I use either O1, O2 or 
O3 then it fails. Only O0 works fine. I found a small workaround which works 
for any optimization level, it suffices to add a call to printf("..") for a 
particular local variable but of course this is not acceptable. I'm not in a 
position to test if it is a AMD64 specific problem or not.

Here is the output regarding the command line I'm using:

gcc -v -g -c -O3 -Wall -pedantic -std=gnu99 -pipe -fPIC -c my_file.c
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-
exceptions --enable-languages=c,c++,objc,java,f77 --enable-java-awt=gtk --
host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
 /usr/libexec/gcc/x86_64-redhat-linux/3.4.2/cc1 -quiet -v my_file.c -quiet -
dumpbase my_file.c -mtune=k8 -auxbase my_file -g -O3 -Wall -pedantic -
std=gnu99 -version -fPIC -o - |
 as -V -Qy -o my_file.o -
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-
linux/3.4.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-redhat-linux/3.4.2/include
 /usr/include
End of search list.
GNU C version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) (x86_64-redhat-linux)
        compiled by GNU C version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128172
GNU assembler version 2.15.92.0.2 (x86_64-redhat-linux) using BFD version 
2.15.92.0.2 20040927

I've attached below the .s output of an extract of the routine which fails 
(i.e. without printf):

.globl buggy_feature
    .type   buggy_feature, @function
buggy_feature:
.LFB114:
    pushq   %r12
.LCFI94:
    movl    $1, %esi
    pushq   %rbp
.LCFI95:
    pushq   %rbx
.LCFI96:
    movl    %edi, %ebx
    subq    $32, %rsp
.LCFI97:
    leaq    30(%rsp), %rdi
    call    read_int16@PLT
    movswl  30(%rsp),%edi
    xorl    %edx, %edx
    xorl    %esi, %esi
    incl    %edi
    movslq  %edi,%rdi
    call    eif_rt_xmalloc@PLT
    testq   %rax, %rax
    movq    %rax, %rbp
    je  .L1012
.L985:
    movswq  30(%rsp),%rsi
    movq    %rbp, %rdi
    call    read_char@PLT
    movswq  30(%rsp),%rdx
    movq    rt_kind_version@GOTPCREL(%rip), %rax
    movb    $0, (%rdx,%rbp)
    cmpb    $13, (%rax)
    jg  .L1013
    movl    $0, 24(%rsp)
.L987:
    leaq    22(%rsp), %rdi
    movl    $1, %esi
    call    read_int16@PLT
    leaq    20(%rsp), %rdi
    movl    $1, %esi
    call    read_int16@PLT
    movq    type_array(%rip), %rcx
    movswq  22(%rsp),%r11
    movslq  %ebx,%r9
    leaq    (%r9,%r9,4), %r8
    movq    (%rcx), %r10
    movq    8(%rcx), %rsi
    movw    %bx, (%r10,%r11,2)
    leaq    (%rsi,%r8,8), %rbx
    cmpw    $-2, 28(%rbx)
    jne .L1014


Now the same code with an additional call to printf:

.globl buggy_feature
    .type   buggy_feature, @function
buggy_feature:
.LFB114:
    pushq   %r12
.LCFI94:
    movl    %edi, %r12d
    movl    $1, %esi
    pushq   %rbp
.LCFI95:
    pushq   %rbx
.LCFI96:
    subq    $32, %rsp
.LCFI97:
    leaq    30(%rsp), %rdi
    call    read_int16@PLT
    movswl  30(%rsp),%edi
    xorl    %edx, %edx
    xorl    %esi, %esi
    incl    %edi
    movslq  %edi,%rdi
    call    eif_rt_xmalloc@PLT
    testq   %rax, %rax
    movq    %rax, %rbp
    je  .L1012
.L985:
    movswq  30(%rsp),%rsi
    movq    %rbp, %rdi
    call    read_char@PLT
    movswq  30(%rsp),%rdx
    movq    rt_kind_version@GOTPCREL(%rip), %rax
    movb    $0, (%rdx,%rbp)
    cmpb    $13, (%rax)
    jg  .L1013
    movl    $0, 24(%rsp)
.L987:
    leaq    22(%rsp), %rdi
    movl    $1, %esi
    movslq  %r12d,%rbx
    call    read_int16@PLT
    leaq    20(%rsp), %rdi
    movl    $1, %esi
    call    read_int16@PLT
    movq    type_array(%rip), %rcx
    movswq  22(%rsp),%r10
    leaq    (%rbx,%rbx,4), %r8
    leaq    .LC31(%rip), %rdi
    xorl    %eax, %eax
    movq    8(%rcx), %rsi
    movq    (%rcx), %r9
    leaq    (%rsi,%r8,8), %rbx
    movw    %r12w, (%r9,%r10,2)
    movl    %r12d, %esi
    call    printf@PLT
    cmpw    $-2, 28(%rbx)
    jne .L1014

In both cases .L1014 is defined as:

.L1014:
    xorl    %edi, %edi
    call    exit@PLT


The actual C code of the `buggy_feature' routine is:

rt_public void buggy_feature (int type_index)
{
    char *a_name;
    type_descriptor *a_conv;
    int16 nb_gen, num_attrib, name_length, dtype;
    int32 flags;

    read_int16 (&name_length, 1);
    a_name = (char *) eif_rt_xmalloc (name_length + 1, C_T, GC_OFF);
    if (a_name == NULL)
        xraise (EN_MEM);
    read_char (a_name, name_length);
    a_name[name_length] = '\0';
	if (rt_kind_version >= 0x0E) {
    	read_int32 (&flags, 1);
	} else {
		flags = 0;
	}
    read_int16 (&dtype, 1);
    read_int16 (&nb_gen, 1);

    type_array->type_index[dtype] = type_index;
    a_conv = type_array->descriptions + type_index;
// Uncomment this line to ensure the condition below is not satisfied.
//  printf ("%d\n", type_index);
    if (!((a_conv->new_type == TYPE_UNDEFINED))) {
        exit(0);
    }
}


If you comment the `printf' line then the code calls `exit (0)',
if you uncomment it, then it does not call it.

It looks to me that the value of the `rbx' register is incorrect when
there is no `printf' statement.

Let me know if you need more information.
Thanks,
Manu

-- 
           Summary: Strange optimization issue
           Product: gcc
           Version: 3.4.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: manus at eiffel dot com
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: Linux madrid.ise 2.6.9-1.667 #1 Tue Nov 2 14:50:10 EST
                    2004 x86_


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

[Bug rtl-optimization/18616] Strange optimization issue

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |rtl-optimization
   GCC host triplet|Linux madrid.ise 2.6.9-1.667|
                   |#1 Tue Nov 2 14:50:10 EST   |
                   |2004 x86_                   |
 GCC target triplet|                            |x86_64-linux
           Keywords|                            |wrong-code


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

[Bug rtl-optimization/18616] Strange optimization issue

[schwab at suse dot de]

------- Additional Comments From schwab at suse dot de  2004-11-22 23:36 -------
Please read <http://gcc.gnu.org/bugs.html#detailed>. 

-- 


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

[Bug rtl-optimization/18616] Strange optimization issue

[manus at eiffel dot com]

------- Additional Comments From manus at eiffel dot com  2004-11-23 00:01 -------
Thank you very much for the link to the bug submission page. I had read it and 
I provided as much as I could from what is requested. Looks to me that with 
the .S output I've included and the actual source code you have everything you 
need to see what was incorrectly generated. I've already spend a whole day to 
figure out where was the bug so I'll be glad to provide you more but I need 
guidance at what you will find useful or not.

Thanks,
Manu

-- 


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

[Bug rtl-optimization/18616] Strange optimization issue

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2004-11-23 00:39 -------
We need the preprocessed source, as generated by -save-temps.

Maybe you could also suggest how we could have made that clearer on the
web page?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug rtl-optimization/18616] Strange optimization issue

[manus at eiffel dot com]

------- Additional Comments From manus at eiffel dot com  2004-11-23 01:17 -------
Unfortunately I cannot give you the all .i file. However the source code I gave 
you is an extract very similar of the .i content corresponding to where the 
code generation bug occurs (some upper case macros being replaced by numerical 
value 0 and 2).

I'm trying to reproduce it on a smaller example but I haven't been able to do 
so yet.

-- 


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

[Bug rtl-optimization/18616] Strange optimization issue

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-11-23 01:53 -------
Emmanuel, we can do *nothing* without a compilable source code showing the bug. 
Better if the testcase can compile and link into a standalone executable which 
segfaults. But if this is impossible, at least give us a compilable file 
containing the buggy_feature function and all the declarations needed to 
compile it. From there, we can start analyzing the dumps and check if there is 
something wrong going on.

Another way you can help is pinpointing the exact optimization option which 
triggers the bug. The manual contains a list of all options implied by -O1, so 
you can start from there and remove them one by one (-O1 -fno-this -fno-that) 
until you find which one triggers the bug.

-- 


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

[Bug rtl-optimization/18616] Strange optimization issue

[manus at eiffel dot com]

------- Additional Comments From manus at eiffel dot com  2004-11-23 02:15 -------
I'll try to do my best and will report as soon as I have something more 
concrete for you.

Thank you for your attention
Regards,
Manu

-- 


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

[Bug rtl-optimization/18616] Strange optimization issue

[manus at eiffel dot com]

------- Additional Comments From manus at eiffel dot com  2004-11-30 01:38 -------
It turns out that I had somewhere else a stack corruption that was causing this 
behavior. It was strange that adding a printf statement made it work, or that 
it was working without optimization.

You can close this entry.
Thanks
Manu

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


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