`std::cosf`, `std::sinf`, `std::sqrtf` are not declared in `<cmath>`

#include <cmath>

using std::fabsf;
using std::fabsl;

abs.cc:3:12: error: ‘std::fabsf’ has not been declared
 using std::fabsf;
            ^~~~~
abs.cc:4:12: error: ‘std::fabsl’ has not been declared
 using std::fabsl;
            ^~~~~

These are required by C++17 (and maybe implicitly by C++11, although it's not very clear)

Also:

modf{f,l}
acos{f,l}
asin{f,l}
atan2{f,l}
cos{f,l}
sin{f,l}
tan{f,l}
cosh{f,l}
sinh{f,l}
tanh{f,l}
exp{f,l}
frexp{f,l}
ldexp{f,l}
log{f,l}
log10{f,l}
pow{f,l}
sqrt{f,l}
ceil{f,l}
floor{f,l}
fmod{f,l}

*** Bug 89279 has been marked as a duplicate of this bug. ***

The bug is still present with g++ 8.3.0 on Ubuntu 19.04
(g++ (Ubuntu 8.3.0-6ubuntu1) 8.3.0) as tested with sqrtl.
As g++ is not conformant with c++11 (AFAIK):
  std::sqrt(n)
will result in the error message:
  error: ‘sqrtl’ is not a member of ‘std’
while using '# include <ctime>',
this bug should be fixed.
Otherwise please give a short comment to this bug report explaining why this can not or should not be fixed.
Especially if giving C++14 as default ...

(In reply to JMB from comment #3)
> this bug should be fixed.

Yes, we know. That's why there's a bug report.

> Otherwise please give a short comment to this bug report explaining why this
> can not or should not be fixed.

Of course it should be fixed, that's why there's a bug report and it hasn't been closed. But we have lots of bugs and finite resources.

> Especially if giving C++14 as default ...

As I said above, it's not actually clear if this is required by C++11 and C++14. The function sqrtl is not mentioned at all in the C++14 standard. It's definitely required by C++17, but that isn't enabled by default.

I am experiencing the same problem with GCC 10.2.0.

I have included <cmath> and I am attempting to rely on std::ceilf. g++(1) bails with:

error: ‘ceilf’ is not a member of ‘std’; did you mean ‘ceil’

$ g++ --version
g++ (Ubuntu 10.2.0-13ubuntu1) 10.2.0

As it says, you can just use std::ceil.

Not if I want any certainty at compile time that it is single precision.

If you call std::ceil with a float, you get the ceil(float) overload. If you don't call it with a float, you haven't got subtle precision anyway and calling ceil didn't change that.

If you need ceilf you can include <math.h> and call ceilf.

And calling ceilf(x) doesn't give you any certainty of single precision, because if x is a double then it will still work, but you're now doing a conversion from double to float.

If you already know x is a float, then std::ceil(x) is single precision. If you don't know it's a float, using ceilf doesn't change that. The only certainty you have is x will be converted to float.

Thanks Jonathan, but I disagree. The point is that the caller might be wrong in any number of assumptions. The library designers were in agreement, hence why there is an explicit ceilf function.

Nope, ceilf comes from C, which has no overloading.

C++ doesn't need separate names for ceil, ceilf and ceill, so you just have std::ceil.

The fact std::ceilf exists at all is just for consistency with C, not because "the library designers" considered it important. That's why it wasn't even mentioned in C++98, C++03, C++11, or C++14.

We will add all the functions listed above in this bug, because they're meant to be there, but they are not essential. You can use std::ceil((float)x) or ::ceilf(x) as a workaround with identical semantics.

I didn't say STL. I said library designers which includes the standard C runtime. And no, I don't agree with you. Separate names are helpful for greater certainty. As for std::ceilf existing just for consistency with C, that's speculative and, in my view doubtful.

(In reply to Kip Warner from comment #12)
> I didn't say STL. I said library designers which includes the standard C
> runtime.

Why a particular name is used by C is not relevant to C++. The function is in C++ because it was inherited from C99, with no discussion or consideration about suitability for the C++ library.

> And no, I don't agree with you. Separate names are helpful for
> greater certainty. As for std::ceilf existing just for consistency with C,
> that's speculative and, in my view doubtful.

It's not speculative. I am certain that ceilf was never once mentioned in a WG21 proposal (or minutes of WG21 meetings) until https://wg21.link/p0175 proposed explicitly naming it in the C++ standard for consistency with the contents of <math.h> in C99.

It had previously been mentioned in https://wg21.link/lwg289 which concluded that ceilf etc were *not* part of the C++ standard (which meant C++98 at the time). There was no subsequent design decision to explicitly add it to C++, it was brought it when C++ rebased its library on the C99 library. In other words, for consistency with C.

Your time would be better spent submitting a patch to add it to libstdc++ rather than trying to convince me of its history in the C++ library.

Thanks Jonathan, but I still think you are mistaken in that you don't understand why the function exists in its various forms. Your explanation is technical and not philosophical.

Whether it was originally inherited from the standard C library or was a creature of a C++ WG committee isn't material. And yes, you are being speculative.

We can discuss another day the history, design choices, and rationale behind how floating point calculations have been done. In any event, we are going around in circles.

But the important thing is that this is thankfully being patched.

*** Bug 99338 has been marked as a duplicate of this bug. ***

Partial fix attached to https://gcc.gnu.org/pipermail/libstdc++/2021-March/052237.html

*** Bug 101855 has been marked as a duplicate of this bug. ***

(In reply to Jonathan Wakely from comment #13)
> It's not speculative. I am certain that ceilf was never once mentioned in a
> WG21 proposal (or minutes of WG21 meetings) until https://wg21.link/p0175
> proposed explicitly naming it in the C++ standard for consistency with the
> contents of <math.h> in C99.

Actually ceilf was explicitly mentioned in TR1 (https://wg21.link/n1836), although it was introduced as std::tr1::ceilf then. I don't know why the -f/-l variants became implicit (or ignored) when merging TR1 (except for math special functions) into the standard...

Oh... I was wrong. TR1 mentioned -f and -l variants of "new" (C99) function families (e.g. truncf), but no those of "old" (C89) math function families.

GCC 12.1 is being released, retargeting bugs to GCC 12.2.

GCC 13.1 is being released, retargeting bugs to GCC 13.2.

GCC 13.2 is being released, retargeting bugs to GCC 13.3.

Nathaniel provided a patch which I need to get committed:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612339.html

The master branch has been updated by Jonathan Wakely <email address hidden>:

https://gcc.gnu.org/g:0b880466e910b4f1be2ea2d0d9cb9407d24ca299

commit r14-5341-g0b880466e910b4f1be2ea2d0d9cb9407d24ca299
Author: Nathaniel Shead <email address hidden>
Date: Thu May 11 23:02:18 2023 +0100

    libstdc++: Add missing functions to <cmath> [PR79700]

    This patch adds the -f and -l variants of the C99 <math.h> functions to
    <cmath> under namespace std (so std::sqrtf, std::fabsl, etc.) for C++11
    and up.

    libstdc++-v3/ChangeLog:

            PR libstdc++/79700
            * include/c_global/cmath (acosf, acosl, asinf, asinl, atanf)
            (atanl, atan2f, atan2l, ceilf, ceill, cosf, cosl, coshf, coshl)
            (expf, expl, fabsf, fabsl, floorf, floorl, fmodf, fmodl, frexpf)
            (frexpl, ldexpf, ldexpl, logf, logl, log10f, log10l, modff)
            (modfl, powf, powl, sinf, sinl, sinhf, sinhl, sqrtf, sqrtl, tanf)
            (tanl, tanhf, tanhl): Add using-declarations in namespace std.
            * testsuite/26_numerics/headers/cmath/equivalent_functions.cc:
            New test.
            * testsuite/26_numerics/headers/cmath/functions_std_c++17.cc:
            Add checks for existence of above names.

    Signed-off-by: Nathaniel Shead <email address hidden>
    Reviewed-by: Jonathan Wakely <email address hidden>

Fixed for GCC 14 thanks to Nathaniel.