| Issue |
178156
|
| Summary |
[clang] `#pragma clang fp` has no way to control HonorNaNs / HonorInfs / finite-math-only assumptions
|
| Labels |
clang
|
| Assignees |
|
| Reporter |
MacroModel
|
### Summary
While working with strict floating-point semantics (in particular, WebAssembly-style numeric behavior), I noticed that `#pragma clang fp` does not provide any way to locally control NaN/Infinity–related assumptions, such as `HonorNaNs`, `HonorInfs`, or `finite-math-only`.
According to the documentation (`LanguageExtensions.rst`), `#pragma clang fp` currently allows controlling only:
- `reassociate`
- `reciprocal`
- `contract`
- `exceptions`
- `eval_method`
There are no pragma-level controls for honoring NaNs or infinities, nor for disabling `finite-math-only` assumptions.
---
### Motivation
This becomes a problem in scenarios where:
- Most of a translation unit benefits from `-O3 -ffast-math`, but
- A small subset of functions must implement **language- or VM-defined floating-point semantics** (e.g. WebAssembly numeric instructions), where:
- NaNs must remain observable,
- `isnan` / `isunordered` must not be treated as undefined behavior,
- `finite-math-only` assumptions are invalid.
Currently, once `-ffast-math` (or `-Ofast`) is enabled at the command-line level, there is no way to locally restore strict NaN/Inf semantics using pragmas.
---
### Evidence from Clang Source and Behavior
- `#pragma clang fp` is limited to the options listed above (as documented and implemented).
- Diagnostics such as `-Wnan-infinity-disabled` are triggered based on `FPOptions::getNoHonorNaNs()` / `getNoHonorInfs()` (e.g. in `SemaChecking.cpp` for `__builtin_isnan` and related builtins).
- These `FPOptions` fields are affected by command-line options like `-fhonor-nans` / `-fno-honor-nans`, which are handled in the driver (`Clang.cpp`) and apply at translation-unit scope.
- There is currently no pragma mechanism to modify these options at function or block scope.
---
### Question
Is the lack of pragma-level control over `HonorNaNs`, `HonorInfs`, and `finite-math-only` assumptions an intentional design decision?
If so:
- What is the recommended approach for implementing small regions of code with strict floating-point semantics inside a translation unit compiled with `-ffast-math`?
If not:
- Would it be reasonable to consider extending `#pragma clang fp`, or introducing a new pragma, to allow local control over these assumptions (analogous to `contract` / `reassociate`)?
Any guidance on the intended model here would be appreciated.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
