Boolean parameter will be misinterpreted when compiled from bytecode rather than from java source. See in assembly (when compiled without any optimizations): movb %al, -1(%ebp) then referencing the variable: movl -8(%ebp), %edx Release: 3.2.2 Environment: mingw, linux How-To-Repeat: Compile the java source to bytecode, then compile it with gcj to produce assembly listing. Watch for the parameter representation of the boolean variable in the stack.
Fix: Compile from java source OR avoid booleans (use ints instead). Note: java bytecode treats booleans as ints already. They shouldn't be treaten like booleans, unless you want packed boolean arrays, which occurs very very rarely.
Can you provide the source file?
Subject: RE: miscompilation of boolean parameters from bytecode Begin forwarded message: > From: Szabó Dániel <szabo.daniel@dpg.hu> > Date: Mon Jun 2, 2003 11:56:35 US/Eastern > To: pinskia@physics.uc.edu > Subject: Re: miscompilation of boolean parameters from bytecode (fwd) > > Hi, > I've sent the files to gcc-bugzilla@... but didn't get any response > and the issue is still in 'waiting' state. > So I thought I would send them directly to you. > > > Szabó Dániel <szabo.daniel@dpg.hu> 2003.05.26. 10:48:47 +2h-kor írta: > >> I'v attached all three files: java, class and s >> >> (I did attach the java file to the web-form bugreport also) >> >>> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* >>> gcc-bugs@gcc.gnu.org. >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10878 >>> >>> >>> pinskia@physics.uc.edu changed: >>> >>> What |Removed |Added >>> >>> --------------------------------------------------------------------- >>> ------- >>> Status|UNCONFIRMED |WAITING >>> >>> >>> ------- Additional Comments From pinskia@physics.uc.edu 2003-05-25 >>> 02:33 >>> ------- >>> Can you provide the source file? >>> >>> >>> >>> ------- You are receiving this mail because: ------- >>> You reported the bug, or are watching the reporter.
Created attachment 4142 [details] bug.java
Created attachment 4143 [details] bug.class
Created attachment 4144 [details] bug.s
Subject: miscompilation of boolean parameters from bytecode (fwd) I'm resending these files, because the bug tracking id was missing in my earlier mail's subject line. > I'v attached all three files: java, class and s > > (I did attach the java file to the web-form bugreport also) > > > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10878 > > > > > > pinskia@physics.uc.edu changed: > > > > What |Removed |Added > > > > ---------------------------------------------------------------------------- > > Status|UNCONFIRMED |WAITING > > > > > > ------- Additional Comments From pinskia@physics.uc.edu 2003-05-25 02:33 > > ------- > > Can you provide the source file? > >
Created attachment 4145 [details] bug.java
Created attachment 4146 [details] bug.class
Created attachment 4147 [details] bug.s
I do not think it matters because because gcc always will load in it by a byte. What do you think? _ZN3bug2g1Eb: pushl %ebp movl %esp, %ebp ; ebp = esp subl $40, %esp ; esp - = $40 movl 12(%ebp), %eax ; eax = 12(ebp) movb %al, -1(%ebp) ; -1(ebp) = al movl 8(%ebp), %eax ; eax = 8(ebp) movl %eax, -12(%ebp) ; -12(ebp) = eax cmpl $0, -12(%ebp) jne .L12 call _Jv_ThrowNullPointerException .L12: movl -12(%ebp), %eax ; eax = -12(ebp) movl %eax, (%esp) ;(esp) = eax call _ZN3bug2f1Ev movzbl %al, %eax eax = extend (al) testl %eax, %eax jne .L13 jmp .L9 .L13: movl $1, -8(%ebp) -8(ebp) = 1 .L9: movl 8(%ebp), %eax eax = 8(ebp) movl -8(%ebp), %edx edx = -8(ebp) movl %edx, -16(%ebp) -16(ebp) = edx movl %eax, -20(%ebp) -20(ebp) = eax cmpl $0, -20(%ebp) jne .L15 call _Jv_ThrowNullPointerException .L15: movl -16(%ebp), %eax eax = -16(ebp) movl %eax, 4(%esp) 4(esp) = eax movl -20(%ebp), %edx -20(ebp) = edx movl %edx, (%esp) (esp) = edx call _ZN3bug2g2Eb leave ret
Subject: Re: miscompilation of boolean parameters from bytecode It definitely matters. Compiled code runs with side effects (for sure, tested, that's why I was looking for what went wrong). The problem is the _location_ on the stack: storing parameter in local storage: > movb %al, -1(%ebp) ; -1(ebp) = al vs reading local storage and passing on: > movl -8(%ebp), %edx edx = -8(ebp) setting the local storage _inside the function_ is correct: > movl $1, -8(%ebp) -8(ebp) = 1 the bogus code is the very first store op. it should read movb %al, -8(%ebp) just compare it to the second store op, where the second function parameter will be stored in local storage: > movl %eax, -12(%ebp) ; -12(ebp) = eax pinskia@physics.uc.edu <gcc-bugzilla@gcc.gnu.org> 2003.06.02. 16:33:46-kor írta: > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10878 > > > > ------- Additional Comments From pinskia@physics.uc.edu 2003-06-02 16:33 > ------- > I do not think it matters because because gcc always will load in it by a > byte. > What do you think? > > _ZN3bug2g1Eb: > pushl %ebp > movl %esp, %ebp ; ebp = esp > subl $40, %esp ; esp - = $40 > movl 12(%ebp), %eax ; eax = 12(ebp) > movb %al, -1(%ebp) ; -1(ebp) = al > movl 8(%ebp), %eax ; eax = 8(ebp) > movl %eax, -12(%ebp) ; -12(ebp) = eax > cmpl $0, -12(%ebp) > jne .L12 > call _Jv_ThrowNullPointerException > ..L12: > movl -12(%ebp), %eax ; eax = -12(ebp) > movl %eax, (%esp) ;(esp) = eax > call _ZN3bug2f1Ev > movzbl %al, %eax eax = extend (al) > testl %eax, %eax > jne .L13 > jmp .L9 > ..L13: > movl $1, -8(%ebp) -8(ebp) = 1 > ..L9: > movl 8(%ebp), %eax eax = 8(ebp) > movl -8(%ebp), %edx edx = -8(ebp) > movl %edx, -16(%ebp) -16(ebp) = edx > movl %eax, -20(%ebp) -20(ebp) = eax > cmpl $0, -20(%ebp) > jne .L15 > call _Jv_ThrowNullPointerException > ..L15: > movl -16(%ebp), %eax eax = -16(ebp) > movl %eax, 4(%esp) 4(esp) = eax > movl -20(%ebp), %edx -20(ebp) = edx > movl %edx, (%esp) (esp) = edx > call _ZN3bug2g2Eb > leave > ret > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter.
I need to read the asm more cosely but you are right it does matter.
I think this fixed on the tree-ssa.
This is fixed by the merge of the tree-ssa.