I tend to use math functions of constant expressions for convinience and coherence (i.e log(x)/log(2) instead of log(x)/0.3...). Since these functi
In case of library functions, some compiler might implement these functions as intrinsics, meaning that the compiler knows enough about the functions to replace the call with a constant at compile time. Whether it will do this depends on the compiler. In practice, I often notice that some compilers are reluctant to pre-calculate floating-point expressions at compile time, even if they don't involve any function calls.
In general case, normally they won't and can't get calculated at compile time, assuming the compiler simply doesn't know enough about these functions to be able to calculate them at compile time. Maybe they have some prominent run-time side-effects?
Some compilers might have non-standard compiler-dependent extensions that allow user to provide the additional information about the functions to the compiler, so that the compiler can optimize function calls better and even figure out whether a given call can be replaced with a compile-time pre-calculation. For example, GCC compiler supports such function attributes (GCC-specific extension) as const and pure. If the arguments are known at compile time, a call to function with the const attribute can be theoretically replaced with compile-time pre-calculation. Although I can't say whether GCC can actually do this.
In C++ (even though your question is tagged C) language a planned new feature is a constexpr declaration specifier that serves a similar purpose and supposed to have the effect you describe.