unexpected constexpr availability of std::sqrt, std::hypot etc in gcc

Question

std::sqrt (and similarly std::hypot and other <cmaths> functions) are not (yet) constexpr.

So, basically why does this work in gcc?

#include <cmath>

int main() {
    static constexpr double root2 = std::sqrt(10);
    static constexpr int int_root2 = static_cast<int>(root2);
    static_assert(int_root2 == 3);
    return int_root2;
}

Works in gcc, but not in clang, which throws the expected

error: constexpr variable 'root2' must be initialized by a constant expression
    static constexpr double root2 = std::sqrt(10);

Godbolt comparison

Simply: gcc functionality that is outside (beyond) the standard and can't be relied upon?

Update:

From the comments below:

if we pass -fno-builtin to gcc and change the argument to std:sqrt to 10.0 then gcc throws an error, because its builtin for ints is constexpr. Possible duplicate

You could try other compile options, like `-pedantic`, and see if it complains. — Fred Larson, Feb 22 '22 at 19:21
@FredLarson still works with `-pedantic` : https://godbolt.org/z/7T3YdWe7x — Oliver Schönrock, Feb 22 '22 at 19:23
GCC is not conforming to the standard on this. It is a known issue. There probably is a duplicate somewhere... — user17732522, Feb 22 '22 at 19:23
@OliverSchönrock: Yeah, I tried it too. Same result. It was worth a shot! — Fred Larson, Feb 22 '22 at 19:23
@user17732522 what do you mean by "duplicate"? A duplicate SO Q? — Oliver Schönrock, Feb 22 '22 at 19:24
Maybe this one?: https://stackoverflow.com/questions/27744079/is-it-a-conforming-compiler-extension-to-treat-non-constexpr-standard-library-fu — user17732522, Feb 22 '22 at 19:26
@user17732522 But is it `libstd++` or is it the compiler? On my machine I am compiling against `libstdc++` with both gcc and clang. gcc tolerates it and clang doesn't. Godbolt does the same by default I believe. — Oliver Schönrock, Feb 22 '22 at 19:26
@OliverSchönrock Yes, I realized that it is GCC specifically. — user17732522, Feb 22 '22 at 19:28
@user17732522 That other SO Q is good. But if I pass `-fno-builtin` as suggested there... IT STILL WORKS — Oliver Schönrock, Feb 22 '22 at 19:30
@OliverSchönrock Yes, good point. It seems the overloads with integral type parameters are not affected by `-fno-builtin`. I suppose asking about that specifically might make a good non-duplicate question. — user17732522, Feb 22 '22 at 19:42
libstdc++ explicitly uses __builtin_sqrt in the overload that takes an int. If you try `std::sqrt(10.)`, -fno-builtin will matter. — Marc Glisse, Feb 22 '22 at 19:42
@MarcGlisse Check. So gcc is just non-conforming and has been for at least 7 years, and is obviously not intending to fix it... — Oliver Schönrock, Feb 22 '22 at 19:44
It seems likely the standard will eventually make those functions constexpr. Spending time to write a patch to reject this code feels like a waste of time when there are so many more useful things to improve in gcc. — Marc Glisse, Feb 22 '22 at 19:47
Is it non conforming or does it fall under implementation specific functionality? — Taekahn, Feb 22 '22 at 22:15
@Taekahn I am not really qualified to answer that, but the above-linked potential duplicate makes the case that it is non-conforming, I think. — Oliver Schönrock, Feb 22 '22 at 22:56

unexpected constexpr availability of std::sqrt, std::hypot etc in gcc

0 Answers0