Hi Joseph,
> fixincludes is the right place for a fix for this issue. There is a
> plausible case for having an architecture-independent
> __FLT_EVAL_METHOD___ macro that takes only values defined by
> C99 (regardless of -fpermitted-flt-eval-methods), rather than using the
> new C23 values
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,
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
> 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?
>
Hi,
> See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=100854 .
I found that, indeed, but what I struggle to see is: this behaviour of
__FLT_EVAL_METHOD__ has been around for several years now, so why aren’t there
more tests failing?
I’m not sure what the fix should be, either. We could use
On Thu, Dec 23, 2021, 14:24 FX via Gcc wrote:
> Hi,
>
> Some recently introduced tests have been failing for several weeks on
> x86_64-apple-darwin.
>
> FAIL: gcc.target/i386/cond_op_maxmin__Float16-1.c
> FAIL: gcc.target/i386/pr102464-copysign-1.c
> FAIL: gcc.target/i386/pr102464-fma.c
> FAIL:
Hi,
Some recently introduced tests have been failing for several weeks on
x86_64-apple-darwin.
FAIL: gcc.target/i386/cond_op_maxmin__Float16-1.c
FAIL: gcc.target/i386/pr102464-copysign-1.c
FAIL: gcc.target/i386/pr102464-fma.c
FAIL: gcc.target/i386/pr102464-maxmin.c
FAIL:
