Are constant C expressions evaluated at compile time or at runtime?

If I write a #define that performs an operation using other preprocessor constants, is the final value computed each time the macro appears at runtime? Does this depend on optimizations in the compiler, or is it covered under a standard?

Example:

#define EXTERNAL_CLOCK_FREQUENCY    32768
#define TIMER_1_S                   EXTERNAL_CLOCK_FREQUENCY
#define TIMER_100_MS                TIMERB_1_S / 10

Will the operation 32768 / 10 occur at runtime every time I use the TIMER_100_MS macro?

I would like to avoid the following:

#define EXTERNAL_CLOCK_FREQUENCY    32768
#define TIMER_1_S                   EXTERNAL_CLOCK_FREQUENCY
#define TIMER_100_MS                3276

Summary

A compiler is required to be able to evaluate constant integral expressions because they are necessary for calculating things like array sizes at compile time. However, the standard only says they "can" -- not "must" -- do so. Therefore, only a brain-dead compiler would not evaluate a constant integral expressions at compile time, but a simple check of the assembly output for an unconventional compiler would verify each case.

Solution 1:

Macros are simply textual substitution, so in your example writing TIMER_100_MS in a program is a fancy way of writing 32768 / 10.

Therefore, the question is when the compiler would evaluate 32768 / 10, which is a constant integral expression. I don't think the standard requires any particular behavior here (since run-time and compile-time evaluation is indistinguishable in effect), but any halfway decent compiler will evaluate it at compile time.

Solution 2:

Most answers in here focused on the effect of the macro substitution. But i think he wanted to know whether

32768 / 10

is evaluated at compile time. First of all, that is an arithmetic constant expression, and in addition a integral constant expression (because it has only got literals of integer type). The implementation is free to calculate it at runtime, but it must also be able to calculate it at compile time, because

1. it must give a diagnostic message if a constant expression is not representable in the type that its expression has
2. such expressions are allowed in contexts that require the value at translation time, for example if used as the size of an array dimension.

If the compiler can principally calculate the result already at compile time, it should use that value, and not recalculate it at runtime i think. But maybe there is some reason still to do that. I wouldn't know.

Edit: I'm sorry i've answered the question as if it were about C++. Noticed today you asked about C. Overflowing in an expression is deemed as undefined behavior in C, regardless of whether it happens in a constant expression or not. The second point is also true in C, of course.

Edit: As a comment notes, if the macro is substituted into an expression like 3 * TIMER_100_MS, then this would evaluate (3 * 32768) / 10. Therefore, the simple and direct answer is "No, it would not occur at runtime every time, because the division may not occur at all because of precedence and associativity rules". My answer above assumes that the macro is always substituted such that the division actually happens.

Solution 3:

I'm not aware of any standard that guarantees it will be optimized out. The preprocessor will substitute 32768/10 for TIMER_100_MS, which you can see by running gcc -c. To see whether the compiler is optimizing further, run gcc -S and check out the assembler. With gcc 4.1, even without any optimization flags, this gets reduced to the constant during compilation:

#include <stdlib.h>
#include <stdio.h>

#define EXTERNAL_CLOCK_FREQUENCY    32768
#define TIMER_1_S                   EXTERNAL_CLOCK_FREQUENCY
#define TIMER_100_MS                TIMER_1_S / 10

int main(int argc, char **argv)
{
  printf("%d\n", TIMER_100_MS);

  return(0);
}

gcc -S test.c
cat test.s

...
    popl    %ebx
    movl    $3276, 4(%esp)
    leal    LC0-"L00000000001$pb"(%ebx), %eax
    movl    %eax, (%esp)
    call    L_printf$stub
...