mjhjmtu

Why is a constexpr function no evaluated at compile time but in runtime in the return statement of main function?

It tried

template<int x>
constexpr int fac() 
 return fac<x - 1>() * x; 
 

template<>
constexpr int fac<1>() 
 return 1; 
 

int main() 
 const int x = fac<3>();
 return x;
 

and the result is

main:
 push rbp
 mov rbp, rsp
 mov DWORD PTR [rbp-4], 6
 mov eax, 6
 pop rbp
 ret

with gcc 8.2. But when I call the function in the return statement

template<int x>
constexpr int fac() 
 return fac<x - 1>() * x; 
 

template<>
constexpr int fac<1>() 
 return 1; 
 

int main() 
 return fac<3>();
 

I get

int fac<1>():
 push rbp
 mov rbp, rsp
 mov eax, 1
 pop rbp
 ret
main:
 push rbp
 mov rbp, rsp
 call int fac<3>()
 nop
 pop rbp
 ret
int fac<2>():
 push rbp
 mov rbp, rsp
 call int fac<1>()
 add eax, eax
 pop rbp
 ret
int fac<3>():
 push rbp
 mov rbp, rsp
 call int fac<2>()
 mov edx, eax
 mov eax, edx
 add eax, eax
 add eax, edx
 pop rbp
 ret

Why is the first code evaluated at compile time and the second at runtime?

Also I tried both snippets with clang 7.0.0 and they are evaluated at runtime. Why is this not valid constexpr for clang?

All evaluation was done in godbolt compiler explorer.

A common misconception with regard to constexpr is that it means "this will be evaluated at compile time"¹.

It is not. constexpr was introduced to let us write natural code that may produce constant expressions in contexts that need them. It means "this must be evaluatable at compile time", which is what the compiler will check.

So if you wrote a constexpr function returning an int, you can use it to calculate a template argument, an initializer for a constexpr variable (also const if it's an integral type) or an array size. You can use the function to obtain natural, declarative, readable code instead of the old meta-programming tricks one needed to resort to in the past.

But a constexpr function is still a regular function. The constexpr specifier doesn't mean a compiler has² to optimize it to heck and do constant folding at compile time. It's best not to confuse it for such a hint.

_{¹ - Thanks user463035818 for the phrasing.
² - c++20 and consteval is a different story however :)}

StoryTeller's answer is good, but I think there's a slightly different take possible.

With constexpr, there are three situations to distinguish:

1. The result is needed in a compile-time context, such as array sizes. In this case, the arguments too must be known at compile time. Evaluation is probably at compile time, and at least all diagnosable errors will be found at compile time.




2. The arguments are only known at run time, and the result is not needed at compile time. In this case, evaluation necessarily has to happen at run time.




3. The arguments may be available at compile time, but the result is needed only at run time.

The fourth combination (arguments available only at runtime, result needed at compile time) is an error; the compiler will reject such code.

Now in cases 1 and 3 the calculation could happen at compile time, as all inputs are available. But to facilitate case 2, the compiler must be able to create a run-time version, and it may decide to use this variant in the other cases as well - if it can.

E.g. some compilers internally support variable-sized arrays, so even while the language requires compile-time array bounds, the implementation may decide not to.