#566 INFINITY defined as double with __GNUC__ defined in math.h

v1.0 (example)

This was reproduced on Fedora 24 using mingw32-crt-5.0-0.2.rc2.v5.x.git65a0c3.20160723

Compiling the following example with i686-w64-mingw32-g++

`#include <math.h>

static const float array[] = { INFINITY };

int main() {
return 0;
Gives the following error:

error: narrowing conversion of '+Inf' from 'double' to 'float' inside { } [-Wnarrowing]
static const float array[] = { INFINITY };

In the mingw-w64-headers/crt/math.h header at about line 356 (in revision 11194fd7e8)

#define INFINITY __builtin_inf()

From what I remember C99 specifies INFINITY to be of type float, so I think this should be using __builtin_inff()


  • FX

    FX - 2017-01-05

    Yes, INFINITY should be of type float (http://en.cppreference.com/w/cpp/numeric/math/INFINITY) and so should NAN (http://en.cppreference.com/w/cpp/numeric/math/NAN). The headers should be fixed with this patch:

    Index: crt/math.h
    --- crt/math.h  (revision 6638)
    +++ crt/math.h  (working copy)
    @@ -349,16 +349,16 @@ _CRTIMP double __cdecl scalb (double, lo
     #if __MINGW_GNUC_PREREQ(3, 3)
     #define HUGE_VALF  __builtin_huge_valf()
     #define HUGE_VALL  __builtin_huge_vall()
    -#define INFINITY   __builtin_inf()
    -#define NAN        __builtin_nan("")
    +#define INFINITY   HUGE_VALF
    +#define NAN        __builtin_nanf("")
     extern const float __INFF;
     #define HUGE_VALF __INFF
     extern const long double  __INFL;
     #define HUGE_VALL __INFL
    -extern const double __QNAN;
    -#define NAN __QNAN
    +extern const double __QNANF;
    +#define NAN __QNANF
     #endif /* __MINGW_GNUC_PREREQ(3, 3) */
     /* Use the compiler's builtin define for FLT_EVAL_METHOD to

    (PS: using HUGE_VALF, and thus __builtin_huge_valf(), instead of __builtin_inff() avoids a warning if floating-point mode didn't support infinities)

  • Tim Mayberry

    Tim Mayberry - 2017-02-17

    Has there been any progress on this issue?

    Perhaps the project owners can comment on whether the patch by FX is appropriate.

  • Jonathan Yong

    Jonathan Yong - 2017-02-17
    • status: open --> closed-accepted
  • Jonathan Yong

    Jonathan Yong - 2017-02-17

    This has already been fixed on the master branch, closing.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks