This also reproduced with correctly-sized threadgroup memory. Furthermore, this does look fixed now that I'm running macOS 13.1, so I'm guessing this was a bug that got fixed?

In fact, it was confirmed to me that this was indeed a LLVM back-end bug that was fixed in macOS 13 beta 4.

Thanks, good to know these aren't a problem (although I don't see explained how the autoreleased objects that come from NSAutoreleasePool initialization will get cleaned up, if only at the very end of my application when threads exit). It does make it very annoying to find missing autorelease pools by setting OBJC_DEBUG_MISSING_POOLS=YES though, as almost all of the output will be generated by the NSAutoreleasePool constructor. Are there better tools for this? Running under leaks also reports these objects as ROOT LEAKs.