Including <cmath> in mingw with sse results in missing '::double_t'

Thanks for reporting this; frankly, I'm astonished that it has taken nine and a half years, since Danny Smith introduced the double_t and float_t typedefs into <math.h>, for anyone to get around to filing such a report, and even then, only after what appears to me to be a regression in GCC-6 has increased the visibility of the underlying bug.

First, let's address that GCC-6 regression, (for which you should file a report on GCC's upstream bug tracker -- https://gcc.gnu.org/bugzilla): the combination of -msse and -mfpmath=sse, as used in your command example, causes GCC-6 to define its internal __FLT_EVAL_METHOD__ to -1, (I can neither reproduce nor confirm your claim that it is defined but "empty"), whereas with releases from GCC-3 to GCC-5, this same combination of options cause __FLT_EVAL_METHOD__ to assume a value of zero, (which I think is correct; -1 indicates an indeterminate __FLT_EVAL_METHOD__ state, which arises with the earlier GCC versions only when -mfpmath is indeterminately specified as 387,sse, 387+sse, or both ... the latter two equivalents being unsupported in GCC-3). FWIW, if you specify the combination -msseN -mfpmath=sse for N = 2, 3, or 4, then __FLT_EVAL_METHOD__ will be correctly specified as zero.

Secondly, in spite of your issue arising out of a GCC-6 regression, there is an underlying MinGW.org bug; in <math.h> I see:

#ifdef __FLT_EVAL_METHOD__
 /* Use the compiler's builtin define for FLT_EVAL_METHOD to
  * to establish appropriate float_t and double_t typedefs.
  */
# 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
   typedef long double float_t;
   typedef long double double_t;
# endif
#else
 /* ix87 FPU default
  */
  typedef long double float_t;
  typedef long double double_t;
#endif

The problem with this is that it presumes that __FLT_EVAL_METHOD__, if defined, will always assume a value of 0, 1, or 2; it completely ignores the (legitimate) case of GCC defining __FLT_EVAL_METHOD__ with a value of -1. We can, (and should), fix that, but code compiled with the combination of -msse -mfpmath=sse options, as in your example case, will remain vulnerable to the effects of the GCC-6 regression, and will likely misbehave, if the double_t, or float_t data types are actually used; (note that this regression will also affect C code, in the (perhaps less likely) event that these data types are used).

Finally, as an aside, I assume that your reference to "the other question" relates to your StackOverflow reference. This is a perfect illustration of the utter futility of discussing bugs in that particular forum: not only is that entire site top heavy with disinformation, but those participating in such discussions are unlikely to be in any position to fix the underlying issue, and are also unlikely to report the problem to anyone who actually is in such a position. How could this problem have been fixed in 2012, in MinGW.org code, when no one here was ever made aware that the problem even existed?

Thank you for your analysis and explanation.
First I reported this as a bug in GCC and got shot down quickly with the explanation that without -msse2 the correct value is indeed -1. If you think this is wrong, please participate in the discussion at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626

Besides that, yes the -1 case should be handled. But please also note, that other negative values are possible too (http://en.cppreference.com/w/c/types/limits/FLT_EVAL_METHOD).

And lastly: My mistake there. It seems someone from the MinGW64 team answered to the SO post and also fixed it in their code. Probably confused this with MinGW(32).
But besides that it is a good way of asking for help first, as most likely it is a user error not a compiler bug. (Just read the comment on my (unrelated) question "And even a bug in g++ is more unlikely than you did something wrong.") And if people find that it is a compiler bug, one can still go to the bugtrackers.

Attached patch should resolve the MinGW.org aspect of this bug. GCC-6 regression remains, (and may never be resolved, because GCC maintainers seem reluctant to acknowledge their culpability). Please note that, for the specific combination of -msse -mfpmath=sse options, both float_t and double_t will default to 80-bit long double precision, which may not be what you want, but it is the best compromise we can offer, unless GCC maintainers can be persuaded to DTRT.

I believe that [7cd51d] resolves this, to the extent we can achieve; it will be included in the next release.