This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
optimization bug with -fexpensive-optimizations
- To: gcc-bugs at gcc dot gnu dot org
- Subject: optimization bug with -fexpensive-optimizations
- From: Godmar Back <gback at cs dot utah dot edu>
- Date: Sun, 5 Dec 1999 23:07:11 -0700 (MST)
- Cc: java-discuss at sourceware dot cygnus dot com
Hi,
The following program demonstrates a bug where "-O -fexpensive-optimization"
wrongly removes a needed zero-extending "movzbl" instruction after a
byte-setting "setne" instruction. I suspect that the instruction is
removed in combine.c:try_combine(), but I cannot say whether the problem
is there or in the Java front-end. Maybe the Java front-end is
feeding wrong information about the sizes of its basic types to
the optimizer (?).
To reproduce the problem, simply compile and run the attached program.
I've included the relevant assembly output. This is with a current CVS
on a Linux box.
- Godmar
// bug.java
public class bug {
public static void main(String av[]) {
System.out.println(get(true));
}
/* This is miscompiled under "-O -fexpensive-optimizations" on x86;
* both from source and from class file.
Source:
0: new #30=<Class java.lang.Integer>
3: dup
4: iload_0
5: ifeq 12
8: iconst_1
9: goto 13
12: iconst_0
13: invokespecial #33=<Method java.lang.Integer.<init> (int)void>
16: areturn
Output:
get__3bugb:
pushl %ebp
movl %esp, %ebp
subl $16, %esp
pushl %esi
pushl %ebx
movb 8(%ebp), %bl
subl $12, %esp
pushl $_CL_3bug
call _Jv_InitClass
subl $8, %esp
pushl $12
pushl $_CL_Q34java4lang7Integer
call _Jv_AllocObject
movl %eax, %esi
addl $32, %esp
testb %bl, %bl
setne %al
###
### higher-order bits of %eax are non-zero
### we need a movzbl %al, %eax instruction
### but expensive-optimization removes it.
### Bug in combine.c?
###
subl $8, %esp
pushl %eax
pushl %esi
call __Q34java4lang7Integeri
movl %esi, %eax
leal -24(%ebp), %esp
popl %ebx
popl %esi
movl %ebp, %esp
popl %ebp
ret
*/
static Integer get(boolean f) { return new Integer(f ? 1 : 0); }
}