rjmccall added a comment. Clang is trying to avoid using non-byte-multiple integer types for memory accesses in LLVM IR, whereas Swift isn't. If you take your test case and make the field non-atomic, you'll see that: Clang is accessing the field as an `i8` and Swift is accessing it as an `i1`. So there's a deeper mismatch here which in practice works out because there's no actual difference in memory access width between those types.
The most correct thing for Swift to do is probably to follow Clang's lead in access widths when accessing a C type. In general, I'm not sure there's any compelling reason for Swift to be doing its own IR type layout on Clang's struct types instead of asking Clang IRGen for the lowering, field indexes, and so on. So in the abstract, I think the best fixes would be for Swift to use Clang's IR type and to access this field in memory as an `i8`, whether it's atomic or not; and if we did that, Swift would have to have `mapIntoNative` / `mapFromNative` potentially truncate / extend to match the CC schema, even for fields Swift imported as `Bool`. That would be a more invasive change; probably right now it'd be better to just add that logic to match schemas so that `_Atomic(_Bool)` works. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D94854/new/ https://reviews.llvm.org/D94854 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
