Ispecting the code produced using the default optimization reveals two things. First, that the calls to printf are inlined inside the transaction. This should be fine and the warning messages can be ignored. Second, the increment of the global variable is also inlined inside the transaction and calls to the STM for isolating the read/write are made. I wouldn't expect this to happen since the increment is inside a tm_waiver function for which the compiler is supposed not to create any transactional code.

Yes, this looks like a compiler issue. However, when I test with our current development compiler the bug seems to have been fixed already.

Since we're already planning a new What-If release, (and we're about to start all of the processes needed to release the code externally), I think you're just going to have to wait for that release for the bug fix.(As Ravi said elsewhere we currently expect this to be released early next month)

Thanks for pointing this out. Thisis a known issue. In our next whatif C++ STM compiler release,the tm_waiver/tm_pure will be inlined as we do today, but thecode inside the inlined function will not be instrumented based on"tm_waiver" block concept.

Yes, this looks like a bug, assuming my example below is similar to the case you are discussing. Unfortunately we're past the code-freeze for the next What-If release, so it's unclear if this can be fixed for that release

Note, though, that this will only be a performance issue in the next release, since the presence of the non tm_safe function will force serialization (whereas in the current release it's a correctness issue since there such functions are implicitly treated as tm_waiver, so do not force serialization).