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
jos...@codesourcery.com
