Update: it seems like removing any references to the `MlirDialectRegistrationHooks` is an effective workaround for this issue. This is just speculation, but this seems to imply that the issue is the hashing strategy which seems like it is used to determine C struct identity has a nondeterminism on macOS. For more discussion, consult this forum thread: https://llvm.discourse.group/t/strange-swift-issues-with-dialect-registration-hooks/2759/4
Basically, I have a project with three system library targets, each of which ends up including a C header file "Registration.h". When building a target that depends on more than one of these libraries, compilation fails on macOS but not Linux reporting the following error:
Registration.h:64:31: error: 'MlirDialectRegistrationHooks' has different definitions in different modules; first difference is definition in module 'CSCF' found field 'getNamespaceHook' with type 'MlirDialectGetNamespaceHook' (aka 'struct MlirStringRef ⭐()')
36
MlirDialectGetNamespaceHook getNamespaceHook;
37
^
38
Registration.h:64:31: note: but in 'CMLIR' found field 'getNamespaceHook' with type 'MlirDialectGetNamespaceHook' (aka 'struct MlirStringRef ⭐()')
39
MlirDialectGetNamespaceHook getNamespaceHook;
Curiously, there are other `structs` defined in header files that are imported by both (the typedefs in IR.h are a good example) and these work fine, it is just `MlirDialectRegistrationHooks` that causes the problem. Removing references to `MlirDialectRegistrationHooks` in the Swift code fixes the issue.
Update: Running a few more tests revealed that the failure indeed is intermittent. I have been able to successfully build using both Xcode and Swift Package Manager on macOS (I have not been able to get it to fail on Linux), and I have been able to cause both to fail with the error above. This makes me believe this is a race condition. Perhaps there is some code which unifies definitions imported from different C libraries, but isn't properly synchronized.
The text was updated successfully, but these errors were encountered:
Additional Detail from JIRA
md5: c5751a191ee27027a9454fdb6641ece3
Issue Description:
Update: it seems like removing any references to the `MlirDialectRegistrationHooks` is an effective workaround for this issue. This is just speculation, but this seems to imply that the issue is the hashing strategy which seems like it is used to determine C struct identity has a nondeterminism on macOS. For more discussion, consult this forum thread: https://llvm.discourse.group/t/strange-swift-issues-with-dialect-registration-hooks/2759/4
The project where this occurred is open source, and the GitHub Action output can be found here: https://github.com/GeorgeLyon/MLIRSwift/runs/1840955527?check_suite_focus=true
Basically, I have a project with three system library targets, each of which ends up including a C header file "Registration.h". When building a target that depends on more than one of these libraries, compilation fails on macOS but not Linux reporting the following error:
Registration.h:64:31: error: 'MlirDialectRegistrationHooks' has different definitions in different modules; first difference is definition in module 'CSCF' found field 'getNamespaceHook' with type 'MlirDialectGetNamespaceHook' (aka 'struct MlirStringRef⭐ ()')⭐ ()')
36
MlirDialectGetNamespaceHook getNamespaceHook;
37
^
38
Registration.h:64:31: note: but in 'CMLIR' found field 'getNamespaceHook' with type 'MlirDialectGetNamespaceHook' (aka 'struct MlirStringRef
39
MlirDialectGetNamespaceHook getNamespaceHook;
Curiously, there are other `structs` defined in header files that are imported by both (the typedefs in IR.h are a good example) and these work fine, it is just `MlirDialectRegistrationHooks` that causes the problem. Removing references to `MlirDialectRegistrationHooks` in the Swift code fixes the issue.
Update: Running a few more tests revealed that the failure indeed is intermittent. I have been able to successfully build using both Xcode and Swift Package Manager on macOS (I have not been able to get it to fail on Linux), and I have been able to cause both to fail with the error above. This makes me believe this is a race condition. Perhaps there is some code which unifies definitions imported from different C libraries, but isn't properly synchronized.
The text was updated successfully, but these errors were encountered: