On Thu, Dec 23, 2021, 14:24 FX via Gcc <gcc@gcc.gnu.org> 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: gcc.target/i386/pr102464-maxmin.c > FAIL: gcc.target/i386/pr102464-sqrtph.c > FAIL: gcc.target/i386/pr102464-sqrtsh.c > FAIL: gcc.target/i386/pr102464-vrndscaleph.c > > In all cases the symptom is the same: the include of <math.h> errors out > with “Unsupported value of __FLT_EVAL_METHOD__”. It appears that the > compile option -mavx512fp16 defines __FLT_EVAL_METHOD__ to have value 16, > which is not understood by darwin: > > > /* Define float_t and double_t per C standard, ISO/IEC 9899:2011 7.12 2, > > taking advantage of GCC's __FLT_EVAL_METHOD__ (which a compiler may > > define anytime and GCC does) that shadows FLT_EVAL_METHOD (which a > > compiler must define only in float.h). > */ > > #if __FLT_EVAL_METHOD__ == 0 > > typedef float float_t; > > typedef double double_t; > > #elif __FLT_EVAL_METHOD__ == 1 > > typedef double float_t; > > typedef double double_t; > > #elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1 > > typedef long double float_t; > > typedef long double double_t; > > #else /* __FLT_EVAL_METHOD__ */ > > # error "Unsupported value of __FLT_EVAL_METHOD__." > > #endif /* __FLT_EVAL_METHOD__ */ > > > Is the use of __FLT_EVAL_METHOD__ set to 16 supposed to be portable across > all targets? Or is it linux-only, and should marked as such? >
See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=100854 . > Thanks for any help you can give. > > FX
