Bug 49581 - [trans-mem] save/restore of thread-local data in nested txns is missing
Summary: [trans-mem] save/restore of thread-local data in nested txns is missing
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: trans-mem
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2011-06-29 15:51 UTC by torvald
Modified: 2012-01-31 13:12 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2012-01-11 00:00:00

test case (188 bytes, text/x-csrc)
2011-06-29 15:51 UTC, torvald

Note You need to log in before you can comment on or make changes to this bug.
Description torvald 2011-06-29 15:51:47 UTC
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.
Comment 1 Aldy Hernandez 2012-01-11 15:36:29 UTC
The testcase should have s/__transaction/__transaction_atomic/ because of the front-end changes.

Confirmed for -On where n > 0.
Comment 2 Aldy Hernandez 2012-01-11 17:23:54 UTC
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)>
  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;
 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?
Comment 3 torvald 2012-01-31 13:12:59 UTC
Yes, this works now.  Closing it as fixed.