optimization bug with -fexpensive-optimizations
Godmar Back
gback@cs.utah.edu
Sun Dec 5 22:07:00 GMT 1999
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); }
}
More information about the Gcc-bugs
mailing list