_Float16-related failures on x86_64-apple-darwin

[Hongtao Liu]

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;
   if (x == FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16)
     return y;

I'm testing the patch but still need approval from related MAINTAINERs.

On Fri, Dec 24, 2021 at 7:15 AM FX via Gcc <gcc@gcc.gnu.org> wrote:
>
> > I’m not sure what the fix should be, either. We could use fixinclude to make the darwin headers happy, but we don’t really have a macro to provide the right value. Like a __FLT_EVAL_METHOD_OLDSTYLE__ macro.
> >
> > What should be the float_t and double_t types for FLT_EVAL_METHOD == 16? float and double, if I understand right?
>
> This is one possibility, assuming I am right about the types:
>
> diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
> index 46e3b8c993a..bea85ef7367 100644
> --- a/fixincludes/inclhack.def
> +++ b/fixincludes/inclhack.def
> @@ -1767,6 +1767,18 @@ fix = {
>      test_text = ""; /* Don't provide this for wrap fixes.  */
>  };
>
> +/*  The darwin headers don't accept __FLT_EVAL_METHOD__ == 16.
> +*/
> +fix = {
> +    hackname  = darwin_flt_eval_method;
> +    mach      = "*-*-darwin*";
> +    files     = math.h;
> +    select    = "^#if __FLT_EVAL_METHOD__ == 0$";
> +    c_fix     = format;
> +    c_fix_arg = "#if __FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == 16";
> +    test_text = "#if __FLT_EVAL_METHOD__ == 0";
> +};
> +
>  /*
>   *  Fix <c_asm.h> on Digital UNIX V4.0:
>   *  It contains a prototype for a DEC C internal asm() function,
>
>
> Sucks to have to fix headers… and we certainly can’t fix people’s code that may depend on __FLT_EVAL_METHOD__ have well-defined values. So not convinced this is the right approach.
>
> FX



-- 
BR,
Hongtao