As a side note, the branch is correct if testing 0xffffffe + 2 or other combinations to cause a signed overflow. The only special pattern that fails is '0x7ffffff + 1'.
-- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1843133 Title: Possibly incorrect branch in qemu-system-hppa Status in QEMU: New Bug description: I plan to release a new GNU Lightning soon. I no longer have access to any physical HPPA, but code that was tested some years ago did work on HPPA/HP-UX, and now it appears qemu-system-hppa incorrectly branches in code generated by GNU Lightning. Currently only 32 bit hppa jit generation supported. In the lightning check/test tool, the code would be: .code prolog movi %r0 0x7fffffff movi %r1 1 boaddr L0 %r0 %r1 calli @abort L0: ret epilog The code/debug information looks like this: movi r4 0x7fffffff 0xf8ef5018 ldil L%7ffff800,r4 0xf8ef501c ldo 7ff(r4),r4 movi r5 0x1 0xf8ef5020 ldi 1,r5 boaddr L1 r4 r5 0xf8ef5024 addb,sv,n r5,r4,0xf8ef5044 :a.tst:291 0xf8ef5028 nop calli 0xf8eeb68a [...] L1: Apparently it is not understanding 0x7fffffff + 1 is a signed overflow. Tested in Fedora with qemu-system-hppa-3.1.1-2.fc30.x86_64 and using the debian-10 image. To make it a bit easier to test (partially transformed the not so optimized code generated by lightning to gcc -S output): # cat a.s .LEVEL 1.1 .text .align 4 .globl main .type main, @function main: .PROC .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3 .ENTRY copy %r3,%r1 copy %r30,%r3 stwm %r1,64(%r30) zdepi -1,31,31,%r23 ldi 1,%r24 addb,sv,n %r24,%r23,.L0 nop ldi 1,%r28 b,n .L1 nop .L0: ldi 0,%r28 .L1: ldo 64(%r3),%r30 ldwm -64(%r30),%r3 bv,n %r0(%r2) .EXIT .PROCEND .size main, .-main # gcc a.s # ./a.out; echo $? 1 It should have returned 0. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1843133/+subscriptions
