-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Open
Description
Summary
When using the Halide headers with a Clang toolchain targeting wasm32-wasip1, compilation fails because Halide's feature detection incorrectly assumes _Float16 support is available.
Minimal Reproducible Example
test.cpp
#include <Halide.h>
int main() { return 0; }Compilation Command:
clang++ --target=wasm32-wasip1 -std=c++17 \
-I/path/to/Halide-21.0.0-arm-64-osx/include \
-c test.cpp -o test.oActual Result
The compiler fails with the following error:
/path/to/Halide-21.0.0-arm-64-osx/include/HalideRuntime.h:2156:61: error:
_Float16 is not supported on this target
2156 | HALIDE_ALWAYS_INLINE constexpr halide_type_t halide_type_of<_Float16>() {
| ^
Expected Result
The headers should compile successfully. If the target (WASM) does not support _Float16, Halide should automatically disable the corresponding halide_type_of helpers.
Analysis / Workaround
- In src/runtime/HalideRuntime.h, Halide enables
HALIDE_CPP_COMPILER_HAS_FLOAT16for clang using the__is_identifier(_Float16)check, but it seems this is not enough to ensure that_Float16is actually supported on the target. - For
wasm32-wasip1, that detection appears to succeed even though clang later rejects actual_Float16usage on that target. - Emscripten does not hit this because Halide already excludes
__EMSCRIPTEN__in that detection path. - I can work around this by defining
HALIDE_RUNTIME_ASAN_DETECTEDto disable_Float16support, but this is not ideal since that flag is not intended for this purpose.
Suggested Fixes
- Add
&& !defined(__wasm__)to the clang_Float16auto-detection path. - Add a dedicated opt-out macro such as
HALIDE_DISABLE_CPP_FLOAT16, rather than requiring users to defineHALIDE_RUNTIME_ASAN_DETECTEDfor this purpose.
Environment
- Halide Version: 21.0.0
- Compiler: Homebrew Clang 21.1.8
- OS: macOS 26.3
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels