I'm currently implementing support for hardware transactional memory in
the rs6000 backend for POWER8. Things seem to be mostly working, but I
have run into a few issues I'm wondering whether other people are seeing.
For me, all of the libitm execution test cases in libitm/testsuite/libitm.c/
compile and execute without error, except for reentrant.c, which hangs for me.
My gdb hasn't been ported to support HTM on Power yet, so debugging has been
slow, but what I've learned is, that my tbegin. instruction succeeds, but I
fail the test (meaning someone has the write lock) at beginend.cc:200:
if (unlikely(serial_lock.is_write_locked()))
htm_abort();
...so we abort the transaction. The failure is not persistent, so we do
not break out of the loop due to:
if (!htm_abort_should_retry(ret))
break;
We then fall into the following code, where we hang trying to get the
read lock:
serial_lock.read_lock(tx);
I have yet to track down who has the write lock and why, but I am working
towards that. Talking with Andreas, he said he is seeing the same failure
on S390, so I'm wondering whether this might be a generic libitm issue
and it might hit Intel too. Does anyone know whether this executes correctly
on Intel hardware with RTM? I'll note that if I hack the call to
htm_abort_should_retry(ret) so that we break of of the loop and fallback
to SW TM, then the test case executes correctly.
Secondly, many of the test cases in libitm/testsuite/libitm.c++/ fail
to build for me when I use -static with the following error:
/home/bergner/gcc/install/gcc-fsf-mainline-htm/lib64/libitm.a(method-serial.o):(.opd+0x1098):
multiple definition of `__cxa_pure_virtual'
/home/bergner/gcc/install/gcc-fsf-mainline-htm/lib64/libstdc++.a(pure.o):(.opd+0x0):
first defined here
collect2: error: ld returned 1 exit status
The comment in method-serial.cc says it's trying to avoid a dependency
on libstdc++. Is the __cxa_pure_virtual workaround in method-serial.cc
supposed to work with -static?
Finially, when compiling (static or non-static) static-ctor.C, I'm seeing:
/home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18:
error: unsafe function call 'void __cxa_guard_release(long long int*)' within
'transaction_safe' function
static int y = x;
^
/home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18:
error: unsafe function call 'int __cxa_guard_acquire(long long int*)' within
'transaction_safe' function
Does x86 not get calls to __cxa_guard_acquire and __cxa_guard_release for
this access, so it doesn't see this error? To be honest, I'm not sure
what we're supposed to do with this error.
Peter
