math: auto-demote f32→f64 in cmath output deduction#11
Merged
Conversation
A deduced cmath output inherits the operand's storage flag. With f32 that could land on a result grid too fine for binary32 (e.g. exp of a large argument: e^20 ≈ 4.85e8 > 2^24), which hard-errored in storage_pick. Now storage_pick WIDENS such a grid to binary64: an `f32` grid that float can't represent exactly but double can stores its raw as `double`. The value stays exact; the f32 policy bit is harmless (storage is raw-driven via fp_raw). Only a grid too fine for double as well is a hard error (`exact` is the escape hatch). This covers the deduced-output case the request was about (a too-fine f32 cmath result widens instead of failing to compile) and, uniformly, a direct f32 grid that needs the wider type — "give me float, or the next best thing it fits in." Done in storage_pick (the one gcc-proven place that already had the f32 clauses) rather than at the type level: an earlier attempt computed a demoted policy via a constexpr function over the grid NTTP in a using-alias, which ICEs GCC 12/13 (cxx_eval_bare_aggregate). Reproduced with g++-13 on test_cmath_double and confirmed the storage_pick approach compiles clean on g++-13/14 and C++20. Test: f32 exp with an over-float output grid deduces f64 storage (no error) and computes correctly; small-output f32 stays f32 (test_storage_flags.cpp). Docs updated. Verified: default 407/407, CORDIC 443/443, FLOAT 398/398; no ICE on gcc-13/14. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
NiceAndPeter
force-pushed
the
math-cmath-f32-demote
branch
from
6f0bd9d to
36c81ee
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up — auto-demote
f32→f64for deduced cmath outputsA cmath auto-output inherits the operand's storage flag. With
f32, a function whose result grid overflows binary32 (e.g.expof a large argument: e²⁰ ≈ 4.85e8 > 2²⁴) previously hard-errored instorage_pick. Now the deduced output auto-widens:f32→f64when the grid fitsdouble, else drops the fp flag to deduced storage. The computation still runs in the float engine — only the result is stored wider.demote_fp_storage<G>(P)— drops/widens an fp storage flag a grid can't represent (f32needsfloat_exact,f64needsdouble_exact;Notch==0fits either), preserving the snap/round bits. Also rescues a too-fine deducedf64.out_bound<G,P> = bound<G, demote_fp_storage<G>(P)>; all 26*_auto_toutput aliases route through it (identity when the flag already fits).A grid a user spells
f32on directly stillstatic_asserts instorage_pick— that's deliberate misuse, not deduction.Test
math::flt::expon an over-floatf32grid now deduces f64 storage (no error) and computes correctly; small-outputf32staysf32.Verified: default 407/407, CORDIC 443/443, FLOAT 398/398.
🤖 Generated with Claude Code