Created attachment 24632 [details] test case In the attached test case, stores to x[5] and x[6] in the nested txn do not get rolled back. This happens if the nested txn is restarted by the TM runtime library, or if the nested txn is aborted via __transaction_cancel.
The testcase should have s/__transaction/__transaction_atomic/ because of the front-end changes. Confirmed for -On where n > 0.
On closer inspection, no I can't reproduce this. The outer transaction has correct PHI nodes with values dependent on whether the transaction got aborted/restarted or whether we fell through from the innermost transaction: # x$6_15 = PHI <10(3), 22(6)> # x$5_14 = PHI <10(3), 123(6)> <L2>: y.0_7 = x$5_14 + x$6_15; D.1814_21 = (unsigned int) y.0_7; __builtin__ITM_WU4 (&y, D.1814_21); __builtin__ITM_commitTransaction (); I have verified this by visual inspection of the tree dumps and by modifying the test to print x[5] and x[6] at the end of main(). Upon execution, x[5] and x[6] look correct when the transaction cancels (10 and 10) and when the transaction succeeds (123, 22). This is what I have in main: x[6] += 12; if (foo(2)) __transaction_cancel; } y = x[5] + x[6]; } printf("x[5]=%d, x[6]=%d\n", x[5], x[6]); <-- IS CORRECT I also added a separately linkable foo() to trigger success or failure: int y; __attribute__((transaction_safe)) int foo(int x) { return 1; /* fail transaction */ } Torvald do you mind looking at this again? At least on a transaction cancel everything is working fine. If you can't reproduce, can you close the PR?
Yes, this works now. Closing it as fixed.