9

I've just updated MinGW using mingw-get-setup and i'm unable to build anyting that contains <cmath> header if I use anything larger than -O0 with -std=c++1y. (I also tried c++11 and c++98) I'm getting errors like this one:

g++.exe -pedantic-errors -pedantic -Wextra -Wall -std=c++1y -O3  -c Z:\Projects\C++\L6\src\events.cpp -o obj\src\events.o
In file included from z:\lander\mingw\lib\gcc\mingw32\4.8.1\include\c++\cmath:44:0,
                 from Z:\Projects\C++\L6\src\utils.h:4,
                 from Z:\Projects\C++\L6\src\events.cpp:10:
z:\lander\mingw\include\math.h: In function 'float hypotf(float, float)':
z:\lander\mingw\include\math.h:635:30: error: '_hypot' was not declared in this scope
 { return (float)(_hypot (x, y)); }

Is something wrong on my side?
Or version at mingw repo is bugged? And if so, is there any quick fix for this header?

HolyBlackCat
  • 78,603
  • 9
  • 131
  • 207

3 Answers3

15

To avoid any further speculation, and downright bad suggestions such as using #if 0, let me give an authoritative answer, from the perspective of a MinGW project contributor.

Yes, the MinGW.org implementation of include/math.h does have a bug in its inline implementation of hypotf (float, float); the bug is triggered when compiling C++, with the affected header included (as it is when cmath is included), and any compiler option which causes __STRICT_ANSI__ to become defined is specified, (as is the case for those -std=c... options noted by the OP). The appropriate solution is not to occlude part of the math.h file, with #if 0 or otherwise, but to correct the broken inline implementation of hypotf (float, float); simply removing the spurious leading underscore from the inline reference to _hypot (float, float), where its return value is cast to the float return type should suffice.

Alternatively, substituting an equivalent -std=gnu... for -std=c... in the compiler options should circumvent the bug, and may offer a suitable workaround.

FWIW, I'm not entirely happy with MinGW.org's current implementation of hypotl (long double, long double) either; correcting both issues is on my punch list for the next release of the MinGW runtime, but ATM, I have little time to devote to preparing this.

Update

This bug is no longer present in the current release of the MinGW.org runtime library (currently mingwrt-3.22.4, but fixed since release 3.22). If you are using anything older than this, (including any of the critically broken 4.x releases), you should upgrade.

Keith Marshall
  • 1,980
  • 15
  • 19
  • Alternatively, substituting an equivalent -std=gnu... for -std=c... so are you saying substitute -std=gnu++0x for -std=c++0x? – Scorb Nov 17 '15 at 05:04
  • @ScottF: "_are you saying substitute -std=gnu++0x for -std=c++0x?_". Yes, exactly that. The effect is to enable the semantics of the corresponding `-std=c...` option, (where that may be important), but _without_ suppression of GNU extensions, and, in particular, avoiding the specification of `__STRICT_ANSI__`. – Keith Marshall Nov 17 '15 at 11:35
2

As noted by Keith, this is a bug in the MinGW.org header.

As an alternative to editing the MinGW.org header, you can use MinGW-w64, which provides everything MinGW.org provides, and a whole lot more. For a list of differences between the runtimes, see this wiki page.

rubenvb
  • 74,642
  • 33
  • 187
  • 332
1

MinGW uses gcc and the Microsoft runtime library. Microsoft's implementation support C90, but its support for later versions of the C standard (C99 and C11) is very poor.

The hypot function (along with hypotf and hypotl) was added in C99.

If you're getting this error with a program that calls hypot, such as:

#include <cmath>
int main() {
    std::cout << std::hypot(3.0, 4.0)) << '\n';
}

then it's just a limitation of the Microsoft runtime library, and therefore of MinGW. If it occurs with any program that has #include <cmath>, then it's a bug, perhaps a configuration error, in MinGW.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631