https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #11 from Keith Marshall <keith.marshall at mailinator dot com> ---
(In reply to Jakub Jelinek from comment #8)
> Indeed, this really is a mingw bug.
Wrong! It is *both* a MinGW bug, *and* a GCC bug. The difference is that I am
fully committed to fixing the MinGW bug, whereas you seem to want to sweep the
GCC bug under the carpet.
> "and for other values of FLT_EVAL_METHOD, they are
> otherwise implementation-defined."
> Being implementation-defined doesn't mean they aren't defined at all.
That's correct; (and it's also why simply suppressing references to float_t and
double_t in <cmath> isn't the right thing to do). However, neither is defining
__FLT_EVAL_METHOD__ as "indeterminate" the right thing -- the case in question
most definitely isn't indeterminate.
The right thing, in this case, is to exercise the licence granted by POSIX.1,
(and by inference, by ISO-C), to specify an implementation-defined
FLT_EVAL_METHOD, (POSIX.1-2008 stipulates that it should be less than -1), for
which I can check in MinGW's <math.h>, and typedef float_t and double_t
accordingly:
:
# elif __FLT_EVAL_METHOD__ == -2 /* say */
typedef float float_t;
typedef long double double_t;
:
