In practice, it'd probably work.

In theory? The compiler is still free to add data-dependent delays.

For an "evil" example, a compiler could do this:

    ...

    for(int i=0; i<token_length; i++) {
        char temp = input[i];
        if (token[i] == temp) {
            match_count++;
        }
        wait_for_ns(temp);
    }

It wouldn't make sense for a compiler to do so - but it is allowed. It

That's a good point. However, even if you wrote the routine in assembly, the CPU could pull a similar trick. At some point you have to give up and trust the tool not to do something too catastrophically stupid. Whether that point is at the CPU or the C compiler (with sufficiently paranoid C code) or elsewhere, I'm not sure.

Yep. A classic example is multiplication - which isn't constant-time on modern machines but was on many older ones.

Currently, CMOV is looking like it could become the same thing. It currently takes data-independent time. But is not guaranteed to do so, and very well may not in the future.

The distinction is that hardware tends to change slower than software. You generally have multiple compiler versions per hardware version (possible exception of embedded processors, but even then...).