Since you're using it twice already, is it worth abstracting the "find the appropriate function using dlsym" logic into a function?
I imagine that there will be other user-interface functions which will also need this, so abstracting it sooner rather than later seems a good thing to do.

Can't we shorten this?
I'd prefer

In the proposed Windows code, I think it would be useful to stash the value in a static variable, so that we only make the system call once. While it's very unlikely that this is ever really going to be on a performance path, it's easy to do.
Something like

static inline int getpagesize(void) {
  static int cachedPageSize = 0;
  if (cachedPageSize == 0) {
      SYSTEM_INFO si;
      GetSystemInfo(&si);
      cachedPageSize =  si.dwPageSize;
  }
  return cachedPageSize;
}

Of course, you could also do this with a static constructor, but the order of static construction gets complicated, and this is guaranteed to be safe.

Thanks, LGTM.

Setting all flags in both branches seemed to me as better expressing my intents, but I can change it if you insist.

I am not going to insist. I just find it odd to have a duplicate line of code, and the fact that it is the same in both if branches made me suspicious that there was bug lurking there. So, personally, I would find code like this clearer.

Is "dep_list[i].flags.in = 1;" really supposed to be set in both of the if cases (lines 980 and 983)?
If so, can't we lift that out of the if?

Good point. My personal preference would be to use "== 0", rather than logical not, since I find that easier to read.
So

Code looks fine to me, but it'd be really useful also to add a regression test...

(as suggested by Jim)

LGTM, though the test code may need some reworking to handle Windows...

On the microtask stuff: I have no objection to this, but I'm very surprised that it is needed, since I was under the impression that Clang/OpenMP only ever emits an outlined function for the parallel region that takes a single pointer argument, and then generates code that uses offsets from that to find all the actual arguments.

I have only made a top-level scan, so this needs more review. However,
__kmp_baker_check should look like this

LGTM

Looks fine.

LGTM

Looks good to me.

Do you expect us to align the license to the licenses used by LLVM/OpenMP or
will someone from your team take care of this?

If you choose this approach, 32Ki seems too small. A current maxed-out SGI is already at 256 sockets which could get you to 256*18*2 = 9216 threads, so over 1/4 of the way to your 32Ki.

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?

Can't we roll this up into something which is more table-driven (or loopy) ? (Something more like the code in the testbed runtime, which, admittedly, doesn't parse this yet, but clearly could quite easily.
Note that there's a loop here that extracts the sub-components of the string, then another loop to process them, rather than having five blocks of code, much of which is replicated.

It generally looks fine to me.

LGTM (Ca me parait bon :-)

The LLVM OpenMP landing page contains instructions on getting started that tell people to use the Makefile. Therefore that also needs to be updated to reflect this change.

As I understand it from Jim, icc does not even need this capability any more (acting more like Clang does now)

It looks generally fine, but I am nervous about putting the ompt state placeholders in OpenMP's namespace (by giving them thename prefix "omp_" ). Is there a reason not to name them "ompt_", which would move them into our namespace?

In D10656#194353, @chandlerc wrote:

Oh my, I didn't realize that the runtime actually compiled Fortran code.

I think it would be cleaner if you defined the new constants as KMP_LOCK_RELEASED and KMP_LOCK_STILL_HELD, then the non-nested lock implementations can sensibly return KMP_LOCK_RELEASED, which would be preferable to the explicit "0" they return at the moment.

From a runtime point of view we need to preserve backwards binary compatibility, so we can't change the interface to the current interface function to introduce a count (because that old code won't set it).

Man, I must be in a fuddle this morning. I blame it being Monday.
My logic is utterly wrong :-(

Ah, sorry, I should keep my nose out of stuff that I don't understand.

This looks very dubious
lib/CodeGen/CGStmt.cpp : 2076

assert(CD->hasBody() && "missing CapturedDecl body");