For an MSSA attachment, the following simple Metal fragment shader is meant to be run in multiple render passes, once per sample, to fill the stencil attachment with different reference values per sample. It does not work as expected, and effectively fills all stencil pixel samples with the reference value on each renderpass. struct _10 { int _m0; }; struct main0_out { float gl_FragDepth [[depth(any)]]; }; fragment main0_out main0(constant _10& _12 [[buffer(0)]], uint gl_SampleID [[sample_id]]) { main0_out out = {}; if (gl_SampleID != _12._m0) { discard_fragment(); } out.gl_FragDepth = 0.5; return out; } The problem seems to be using discard_fragment() on a per-sample basis. The intended operation of discarding one sample but writing another does not occur. Instead, the sample is never discarded, regardless of the comparison value passed in the buffer. In fact, from what I can tell from GPU capture shader tracing results, it appears that the entire if-discard clause is optimized away by the Metal compiler. My guess is that Metal probably recognizes the disconnect between per-sample invocations and discard_fragment(), and removes it, but I can't be sure. I can't find any Metal documentation on discard_fragment() and its use with MSAA, so I can't tell whether discard_fragment() is supposed to work with individual sample invocations in that environment, or whether it can only discard the entire fragment (which admittedly the function name implies, but what does that mean for per-sample invocations?). Does the logic and intention of this shader make sense? Is discard_fragment() supposed to work with individual sample invocations? And why would the Metal compiler possibly be removing the discard operation from my shader?

I am using Xcode 12 to build a static library, and for tvOS, Xcode 12 includes both arm64 and arm64e in the single fat library. Similarly, when building for the Simulator, Xcode 12 includes both x86_64 and arm64 (Mac Apple Silicon) in a single fat library. In both cases, I am not able to create an XCFramework that includes these libraries, using the command: xcodebuild -create-xcframework -output A.xcframework" -library A.a Attempting to do so results in the error error: unable to find any architecture information in the binary at 'A.a' The output from lipo -info A.a clearly indicates both architectures present (arm64 + arm64e and arm64 + x86_64, respectively), so I don't understand why xcodebuild can't recognize and handle it. I have also attempted to extract the individual architectures into two thin files each (eg. A-arm64.a and A-arm64e.a) and then create the XCFramework with those, but that results in a different error: Both tvos-arm64e and tvos-arm64 represent two equivalent library definitions. and Both tvos-arm64-simulator and tvos-x86_64-simulator represent two equivalent library definitions. Am I missing something? How does one create an XCFramework from a fat library (or two equivalent thin libraries)?

I'm using Xcode to prelink a collection of object files (*.o) and static libraries (*.a), all containing bitcode, into a single static library using Single-Object Prelinking. In doing so, the resulting prelinked file does not contain bitcode. The prelinking command and options emitted by Xcode looks like this: ld -r -arch arm64 -bitcode_bundle -bitcode_verify -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS13.6.sdk a.o b.o ... x.a y.ao libABC-arm64-master.o The documentation for the bitcode_bundle option indicates that it "requires all the object files, static libraries and user frameworks/dylibs contain bit-code". I have used otool to verify that all of the constituent files contain bitcode. Prelinking any single object file WILL result in the final prelinked file containing bitcode. But even when only two object files are linked, the resulting prelinked file does NOT contain bitcode. No errors are raised or logged the by the ld command, even when I test it directly from the command line, separately from Xcode. I'm stumped. And any help or suggestions would be appreciated.

I have an Xcode project with a single Scheme that does nothing more than launch an OS X app in Debug configuration. The app is not built by the project, and the project does not have any targets. The Xcode project just launches the app from a Scheme. The app was originally built in Debug mode, via an external command-line build script, and contains a number of dynamic libraries (dylib's) in addition to the main executable.After launching the app in this way through Xcode, if the app is stopped by an assertion statement (or is simply manually paused), the resulting call stack reveals nothing more than address pointers. There are no symbols displayed.However, if I force the assertion to continue, the app crashes and produces a fully-symbolicated crash report, despite an absence of dSYM files anywhere in the app distribution.So, the symbols exist somewhere, they are just not being shown in the UI call stack.Furthermore, this lack of call stack symbols is a recent result. Previously, the same executable displayed a symbolicated call stack when paused or stopped by an assertion.My questions are:What could have caused Xcode to stop showing symbols in the UI call stack?If the symbols are available for a crash report, why can't Xcode display them in the UI call stack?