I'd personally split this, because annoying though it is to split a change, the whole thing is likely to be reverted if part of it turns out to be faulty.

All concerns should be addressed now.

In D13689#265984, @jmellorcrummey wrote:

In reading this patch over again, I realized that you implemented the OMPT TR2 lock initialization callback rather than the OMPT working draft, which also passes a lock hint and a lock type to the init callback. The OMPT implementation in LLVM OpenMP is evolving with the current version of the OMPT draft. There are features already in the code that aren't in OMPT TR2. Fort that reason, I think you should add the lock hint and lock type parameters.

In D13689#265972, @jcownie wrote:

I notice that there aren't any patches to kmp_gsupport.c. I looked in that file and didn't see any support for locking. What will happen when using gcc with this support? Will the instrumented locking routines be called to generate the promised callbacks?

Yes these functions will be called. The OpenMP lock functions are simply normal C functions which are called by the compiler just like any other extern function. They are not name-mangled in a compiler specific fashion, or generated in any special way, so the correct functions will be called at no extra effort.

Changed OMPT_BLAME to OMPT_TRACE for the acquire, init and destroy lock events (thanks John for reading the patch carefully!).