https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> --- On linux with glibc, both versions output the same number, so your libm is to blame. Normally, the int version, implemented with multiplications, may be less accurate than the general version. And gcc does generate multiplications for you if you pass it the flag -ffast-math (probably something a little weaker is sufficient), meaning that you are ok with the slight loss of precision as long as the program is faster. Depending on the flags (-fwhole-program or -flto for instance), you may even get f inlined and the result of pow is computed at compile-time by MPFR ;-) The template version right below in cmath catches the int case, uses __builtin_powl, which gcc's optimizers know they can replace with __builtin_powil if the second argument is converted from an integer and the circumstances are right (command-line flags). I don't see what in the comment in cmath makes it look like a temporary patch, we tend to add those DR markers as documentation of past changes, not as FIXME. Actually, I guess we could remove those overloads completely, even in C++03, since we have the template version. But it might confuse users who were relying on the performance benefit (and relaxed accuracy) in C++03 even without suitable command-line flags. Everyone should move to C++14 anyway...