On Tue, 6 Sep 2016, James Greenhalgh wrote: > In c-family/c-cppbuiltin.c I've updated cpp_iec_559_value such that also > allow setting __GEC_IEC_559 if FLT_EVAL_METHOD=16, and I've updated > c_cpp_builtins to handle the new value, and use the new enum names.
I think the special cases in this patch show that the abstractions are wrong. How about instead having more than one target macro / hook. One would indicate that excess precision is used by insn patterns (and be set only for i386 and m68k). Another would indicate the API-level excess precision requested by the target and might take an argument to indicate whether the "fast" or "standard" case is in use (in the x86 case the results would differ depending on the argument, in the ARM case they wouldn't). * If the first hook returns true, excess precision is unpredictable in the "fast" case. Otherwise excess precision is predictable. * For short-circuiting excess_precision_type, maybe an internal setting EXCESS_PRECISION_NONE would make sense, and other settings would be turned into it if permitted by the results of the second hook. (For s390, talk to the maintainers, but I think they really need to eliminate the bogus float_t definition in glibc and the FLT_EVAL_METHOD setting that goes along with it. This is the sort of theoretical ABI change that should be safe in practice.) > + machine_mode float16_type_mode = (FLOATN_TYPE_NODE (0) > + ? TYPE_MODE (FLOATN_TYPE_NODE (0)) > + : VOIDmode); This is obviously wrong. Use float16_type_node. > + ||mode == TYPE_MODE (float_type_node)); Missing space after ||. -- Joseph S. Myers jos...@codesourcery.com
