Why can't I pass a constexpr function to std::cout?

Question

This code, when compiled with g++ -O3, does not seem to evaluate get_fibonacci(50) at compile time - as it runs for a very long time.

#include <iostream>

constexpr long long get_fibonacci(int num){
    if(num == 1 || num == 2){return 1;}
    return get_fibonacci(num - 1) + get_fibonacci(num - 2);
}

int main()
{
    std::cout << get_fibonacci(50) << std::endl;
}

Replacing the code with

#include <iostream>

constexpr long long get_fibonacci(int num){
    if(num == 1 || num == 2){return 1;}
    return get_fibonacci(num - 1) + get_fibonacci(num - 2);
}

int main()
{
    long long num = get_fibonacci(50);
    std::cout << num << std::endl;
}

worked perfectly fine. I don't know exactly why this is occurring, but my guess is that get_fibonacci(50) is not evaluated at compile-time in the first scenario because items given std::cout are evaluated at runtime. Is my reasoning correct, or is something else happening? Can somebody please point me in the right direction?

Answer 1

Actually, both versions of your code do not have the Fibonnaci number computed at compile-time, with typical compilers and compilation flags. But, interestingly enough, if you reduce the 50 to be, say, 30, both versions of your program do have the compile-time evaluation.

Proof: GodBolt

At the link, your first program is compiled and run first with 50 as the argument to get_fibbonacci(), then with 30, using GCC 10.2 and clang 11.0.

What you're seeing is the limits of the compiler's willingness to evaluate code at compile-time. Both compilers engage in the recursive evaluation at compile time - until a certain depth, or certain evaluation time cap, has elapsed. They then give up and leave it for run-time evaluation.

Answer 2

I don't know exactly why this is occurring, but my guess is that get_fibonacci(50) is not evaluated at compile-time in the first scenario because items given std::cout are evaluated at runtime

Your function can be computed compile-time, because receive a compile-time know value (50), but can also computed run-time, because the returned value is send to standard output so it's used run-time.

It's a gray area where the compiler can choose both solutions.

To impose (ignoring the as-if rule) the compile-time computation, you can place the returned value in a place where the value is required compile-time.

For example, in a template parameter, in your first example

std::cout << std::integral_constant<long long, get_fibonacci(50)>::value
   << std::endl;

or in a constexpr variable, in your second example

constexpr long long num = get_fibonacci(50);

But remember there is the "as-if rule", so the compiler (in this case, also using constexpr or std::integral_constant) can select the run-time solution because this "do not change the observable behavior of the program".

Answer 3

Assign to a constexpr to get the compiler to spit out an error message

constexpr auto val = get_fibonacci(50);

Answer 4

constexpr functions are evaluated at compile time only in constexpr context, which includes assignment to constexpr variables, template parameter, array size...

Regular function/operator call is not such context.

std::cout << get_fibonacci(50); is done at runtime.

Now, compiler might optimize any (constexpr or not, inline or not) functions with the as-if rule, resulting in a constant, a simpler loop, ...