[cfp-interest 3695] Fwd: [SC22WG14.34201] FLT_EVAL_METHOD, double_t and Annex H

[Jim Thomas]

> Begin forwarded message:
> 
> From: Joseph Myers <josmyers at redhat.com>
> Subject: [SC22WG14.34201] FLT_EVAL_METHOD, double_t and Annex H
> Date: October 24, 2025 at 3:27:05 PM PDT
> To: sc22wg14 at open-std.org
> 
> Suppose FLT_EVAL_METHOD is 2 and long double has the same set of values as 
> double.
> 
> According to the main standard, FLT_EVAL_METHOD == 2 means that double_t 
> is defined as long double.
> 
> According to Annex H, FLT_EVAL_METHOD == 2 means "evaluate operations and 
> literals, whose semantic type comprises a set of values that is a strict 
> subset of the values of long double, to the range and precision of long 
> double; evaluate all other operations and literals to the range and 
> precision of the semantic type", and "If FLT_RADIX is 2 and 
> FLT_EVAL_METHOD (H.3) is nonnegative, then each of the types corresponding 
> to a standard or binary floating type is the type whose range and 
> precision are specified by FLT_EVAL_METHOD to be used for evaluating 
> operations and literals of that standard or binary floating type.".
> 
> Does that wording apply to double_t as well as to the other *_t defined in 
> Annex H?  If so, because the values of double aren't a *strict* subset of 
> those of double, "the type whose range and precision are specified by 
> FLT_EVAL_METHOD to be used for evaluating operations and literals of that 
> standard or binary floating type" would, in the case of double_t, be 
> double not long double, and that would indicate that double_t should be 
> defined as double (although float_t and long_double_t would be long 
> double).  Does that mean that Annex H does not permit FLT_EVAL_METHOD == 2 
> when long double and double have the same set of values, because of that 
> contradiction in how to define double_t?
> 
> (Note: the "strict subset" in how FLT_EVAL_METHOD is defined in Annex H is 
> a change relative to TS 18661-3 which instead talked about "at most 
> the range and precision".  I don't know the reason for that change, which 
> affects the definition of the *_t types for types with the same set of 
> values as the type implied by FLT_EVAL_METHOD - for example, if 
> FLT_EVAL_METHOD is 2, it affects double_t if double has the same set of 
> values as long double, _Float64_t if _Float64 does, and so on.)
> 
> -- 
> Joseph S. Myers
> josmyers at redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20251104/8edbbf71/attachment.htm>