The existing code looks OK to me -- there's no need to call gen_set_CF_bit31() early because the inputs t0 and t1 to gen_thumb2_data_op() should always be distinct TCG values, and so gen_thumb2_data_op() will never trash t1. (There was a bug in this area involving ORN, but that was fixed in rev 29501f1, and I can see from your patch that you have that fix.)
Can you clarify which exact instruction, input data and output data case this patch is intended to fix, please?
Current git master works for me on that test program without your patch:
cam-vm-266:maverick:qemu$ ./arm-linux-user/qemu-arm ~/Desktop/mvns_imm.exe
cam-vm-266:maverick:qemu$ echo $?
0
(I tested on qemu-0.14 just to confirm that I'm running the test program correctly, and that indeed fails as I would expect it to, exiting with status 255.)
On Mon, Oct 17, 2011 at 10:06 PM, Peter Maydell
<email address hidden> wrote:
> Current git master works for me on that test program without your patch:
> cam-vm-266:maverick:qemu$ ./arm-linux-user/qemu-arm ~/Desktop/mvns_imm.exe
> cam-vm-266:maverick:qemu$ echo $?
> 0
>
> (I tested on qemu-0.14 just to confirm that I'm running the test program
> correctly, and that indeed fails as I would expect it to, exiting with
> status 255.)
>
> Which qemu version have you been testing with?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/874038
>
> Title:
> ARM thumb2 does not propogate carry flag properly
>
> Status in QEMU:
> New
>
> Bug description:
> information on carry flag is lost if gen_set_CF_bit31(t1) is called
> after logic operation.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/874038/+subscriptions
>
The existing code looks OK to me -- there's no need to call gen_set_CF_bit31() early because the inputs t0 and t1 to gen_thumb2_ data_op( ) should always be distinct TCG values, and so gen_thumb2_ data_op( ) will never trash t1. (There was a bug in this area involving ORN, but that was fixed in rev 29501f1, and I can see from your patch that you have that fix.)
Can you clarify which exact instruction, input data and output data case this patch is intended to fix, please?