Spotted when running tier1 tests on Windows JVM build with clang.
MethodExitTest failed with:
----------System.out:(6/187)----------
Agent_OnLoad started
Agent_OnLoad finished

ThreadStart: cthread: 000001E0573A5980, name: main
ThreadStart: GetThreadLocalStorage for carrier thread returned value 111 as expected

----------System.err:(0/0)----------
...
test result: Failed. Unexpected exit from test [exit code: -1073740791]

This exit code translates to STATUS_STACK_BUFFER_OVERRUN. No hs_err file is generated, but there's an entry in Windows event log:

Faulting application name: java.exe, version: 22.0.0.0, time stamp: 0x64a2ef1a
Faulting module name: MethodExitTest.dll, version: 0.0.0.0, time stamp: 0x64a31b75
Exception code: 0xc0000409
Fault offset: 0x00000000000039f5

This, along with the test output, points to stack overrun in libMethodExitTest.cpp / ThreadStart.

Looking at the method, it passes a variable loc_tls_data of type long to SetThreadLocalStorage, and then calls GetThreadLocalStorage to retrieve the stored value back to the same variable.
The problem here is that ThreadLocalStorage is a pointer, which is 8 bytes long on 64 bit architectures. Long on Windows can only store 4 bytes, so the call to GetThreadLocalStorage overwrites additional 4 bytes on stack. When the code is compiled by MS compiler, the overrun is ignored, but clang-compiled code detects the overrun and crashes the application.