You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.
We are hitting an issue with Wizering our code after the 1.2 upgrade. We are using wit-bindgen, which generates memcpy statements, and WASI SDK 16 is compiling them using the bulk memory proposal. But Wizer currently fails if it encounters a bulk memory opcode.
I believe we could force WASI SDK to downgrade by passing clang the -mno-bulk-memory flag. But of course it would be unwelcome to force that on non-Wizering consumers.
Is there a way to inject that into the <WasiSdkClangArgs> property from a consumer of Wasi.Sdk? If not, would it be possible to provide one, e.g. in a similar way to native file references?
The text was updated successfully, but these errors were encountered:
We are hitting an issue with Wizering our code after the 1.2 upgrade. We are using
wit-bindgen
, which generatesmemcpy
statements, and WASI SDK 16 is compiling them using the bulk memory proposal. But Wizer currently fails if it encounters a bulk memory opcode.I believe we could force WASI SDK to downgrade by passing clang the
-mno-bulk-memory
flag. But of course it would be unwelcome to force that on non-Wizering consumers.Is there a way to inject that into the
<WasiSdkClangArgs>
property from a consumer of Wasi.Sdk? If not, would it be possible to provide one, e.g. in a similar way to native file references?The text was updated successfully, but these errors were encountered: