_Float16-related failures on x86_64-apple-darwin

[Joseph Myers]

On Fri, 24 Dec 2021, Hongtao Liu via Gcc wrote:

> gcc define __FLT_EVAL_METHOD__ according to
> 
>   builtin_define_with_int_value ("__FLT_EVAL_METHOD__",
> c_flt_eval_method (true));
> 
> and guess we need to handle things like:
> 
>    /* GCC only supports one interchange type right now, _Float16.  If
>       we're evaluating _Float16 in 16-bit precision, then flt_eval_method
>       will be FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16.  */
> +  if (x == FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16
> +      && x == y)
> +    return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;

That's an incorrect change.  excess_precision_mode_join has 
straightforward, well-defined semantics documented in the comment above 
the function and correcly implemented by it before this change; modifying 
those semantics is not the appropriate way to address this issue.

fixincludes is the right place for a fix for this issue.  There is a 
plausible case for having an architecture-independent 
__FLT_EVAL_METHOD_<something>__ macro that takes only values defined by 
C99 (regardless of -fpermitted-flt-eval-methods), rather than using the 
new C23 values such as 16, but if you did have such a macro you'd still 
need to fixinclude the system headers - it would just affect exactly what 
change fixincludes makes to those headers (if there were such a macro, 
fixincludes could change the headers to use it).

-- 
Joseph S. Myers
joseph@codesourcery.com