[Bug target/82626] -msse and -mfpmath=sse Causes __FLT_EVAL_METHOD__ to be -1

keith.marshall at mailinator dot com gcc-bugzilla@gcc.gnu.org
Fri Oct 20 15:24:00 GMT 2017


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.


More information about the Gcc-bugs mailing list