commits 49b4c31efcce45ab714f286f14fa5d5173f9069d and
2de68a4900ef6eb67380b0c128abfe1976bc66e8 reworked the implementation of adc_CC
and sub_CC. The new implementations (on the TCG_TARGET_HAS_add2_i32 code path)
are incorrect. The new logic is:
CF:NF = 0:A +/- 0:CF
CF:NF = CF:A +/- 0:B
The lower
On 2013-02-25 00:04, Peter Crosthwaite wrote:
commits 49b4c31efcce45ab714f286f14fa5d5173f9069d and
2de68a4900ef6eb67380b0c128abfe1976bc66e8 reworked the implementation of adc_CC
and sub_CC. The new implementations (on the TCG_TARGET_HAS_add2_i32 code path)
are incorrect. The new logic is:
CF:NF
On Mon, Feb 25, 2013 at 3:43 PM, Richard Henderson r...@twiddle.net wrote:
On 2013-02-25 00:04, Peter Crosthwaite wrote:
commits 49b4c31efcce45ab714f286f14fa5d5173f9069d and
2de68a4900ef6eb67380b0c128abfe1976bc66e8 reworked the implementation of
adc_CC
and sub_CC. The new implementations (on
On 02/25/2013 09:15 AM, Laurent Desnogues wrote:
Looking at the new sbc_cc, it seems that if t0=t1 and CF=1,
then CF will be cleared while the old code in the helper did
set it.
Sigh, yes I see it. While the transform
x + ~y + cf
-
x - y + cf - 1
works for the low 32-bits,
On 25 February 2013 17:15, Laurent Desnogues
laurent.desnog...@gmail.com wrote:
I'm afraid this fix is not enough
I've confirmed with my risu test tool that sbcs/adcs are indeed
broken even with this patch applied. Patterns used:
ADC_imm A1 cond:4 0010101 s:1 rn:4 rd:4 imm:12
ADC_reg A1 cond:4