https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #6 from Keith Marshall <keith.marshall at mailinator dot com> --- (In reply to Jakub Jelinek from comment #5) > __FLT_EVAL_METHOD__ 0 can't be correct in that case, "all operations and > constants evaluate in the range and precision of the type used." does not > hold, __FLT_EVAL_METHOD__ -1 cannot be correct either: "the precision of floating point operations is indeterminable", so you force me to compromise on the typedefs for float_t and double_t, (and the only sane choice I can make is long double for both), yet you use methods of determinable precision for your implementation, (in terms of generated code, and in the case of which the double_t compromise is likely correct, but the float_t isn't). > but "all operations and constants evaluate in the range and precision of > long double." which is the requirement for 2 doesn't hold either - float > operations evaluate in the range and precision of that type (float), double > evaluates in the range and precision of long double. Exactly so, (and there is no standardised FLT_EVAL_METHOD to represent that case), but it is very much a determinate case, ergo __FLT_EVAL_METHOD__ -1 is just plain wrong! Correct would have been to exercise the licence granted by POSIX.1-2008, and to define an implementation specific value less than -1, whence I could then infer the proper (albeit non-standard combination of) type definitions for float_t and double_t. > float_t/double_t definitions aren't provided by GCC, but by the C library. > So, if they aren't defined properly in that case, it is up to glibc or mingw > or whatever else projects owns them. And therein lies your bug: if you've specified that float_t and double_t are of indeterminate precision, (and therefore -- by definition -- they themselves are undefinable), you have no right to gratuitously require their definitions in the C++ <cmath> header.
