LLVM verify error: Invalid bitcast #59768
Assignees
Comments
|
I think the issue relates to the file referenced above (CallRecordDetails+OutputModels.swift) or this at least corresponds to the stack signature in frame 5: If I put this in a skeleton project I am unable to replicate the issue. In case it is useful, I also include the Accessibility module that is referenced in frame 0 program arguments which references a similarly named Again, including this in an example project does NOT trigger the issue. Let me know if you think there is something else I can provide to help debug this. |
slavapestov
changed the title
|
I haven’t managed to reproduce with a smaller code base, however, I have been trying different optimisation levels on the swift compiler. I have found that: -Onone & -Osize mean my project can be successfully archived. At least this means I have a workaround right now and maybe this will help narrow the problem down. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We were last able to archive our application on Xcode 13.2. Since then, we have experienced different crash signatures when attempting to archive our code base. The code base is very large so is difficult to isolate whether we can workaround the problem or what the root cause is, however, it is appears to be a compiler problem.
Not sure if it is relevant, but TelephonyUI is a cocoapod dependency within the project which makes it difficult to isolate the problem or replicate in a smaller project.
For Xcode Version 13.4.1 (13F100) on a MacBook M1 Pro (16-inch, 2021) with Monterey 12.4 via Product->Archive from the menu, the following is output during execution of swift-frontend:
The application builds and runs successfully when selecting a simulator or device target. The problem seems to be specific to the
Any iOS Device (arm64)target required for archiving. The part of the output that looks relevant is:Frame 4 references an Accessibility object, however, I think that is possibly just alpabetically the first object in the file list. This is literally just a swiftgen swift module with a load of strings defined. I guess the other item that may be relevant to our code base is referenced here in the stack output:
We do have a TelphonyUI extensions called
CallRecordDetailswhich probably refers toCallRecordDetails+OutputModels.swiftfile but this just contains some relatively simple enums and structs and I don't think this is the file being parsed.The text was updated successfully, but these errors were encountered: