I've never heard of a CPU rearranging expressions. Assembly language has no notion of them. It is the job of the compiler, and it should do what you say unless you enable unsafe math optimizations explicitly.

There are two different things at play here that might have been mixed up.

Hardware:
Modern processors do something called "dynamic out of order execution", where they do in fact try to re-arrange the sequence of machine instructions to best utilize the available circuits. However, special care is taken that this trickery remains hidden; i.e. that it doesn't change the produced results. (Messing this up was one of the causes for Intel's security flaws "Meltdown" and "Spectre" and the stream of subsequent flaws uncovered since.)

Software:
The compiler will also do its best to re-arrange the given program statements to better match what the hardware can do. However, the compiler's changes can and do change the results (after all the compiler's output is the sequence of instructions that the machine is supposed to follow to the letter). However, the default of all sane compilers is to not change the order of floating point operations as specified by the programmer. Even at high optimization levels, for example, GCC will not re-arrange floating point arithmetic unless you explicitly allow "-funsafe-math-optimization" (or imply it with "-ffast-math") on invocation of the compiler.

The latter compiler guarantees are not generally true for GPGPU programming. There, the default tends to be utmost performance.

Conclusion:
When you write sequential code in C/C++, you can control the order of floating point arithmetic with parenthesis, and the compiler will generally stick to that. Unless you specifically instruct it to compromise exact correctness for more performance. (Special caveats apply to multithreaded programming, where concurrency means that there is no guaranteed global order between different parallel threads.)

I recently read about "look-ahead-optimization" and "branch-prediction" on CPU level, and that's why I was concerned about a deterministic outcome.

The results are supposed to be deterministic, the timing is not supposed to be deterministic (but as fast as possible). That is the general contract that hardware designers have to fulfil.

(Modern microprocessor architecture is quite an awesome engineering feat. But on the surface, everything is still appearing as if it were a simple one-after-the-other matter.)