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
