Yes it might - simple lines of code will be evaluated perfectly, by any compiler worth a damn. There will be no differences there.
Better compilers are able to evaluate more complicated lines of code or blocks of code. Their output will be more efficient and thus will run faster, on most or nearly all programs, compared to more primitive compilers.
So MinGW produces the same code too. But you can't compare the results of vc++2010 with yours because the c programs are not the same. The program I posted uses a pointer while yours just uses an integer. Try making your code use a pointer and see the result asm code.
I changed mine to use an int instead of a pointer and the compiler produced the same code as before, but this time added 1. It did not use the inc assembly operator.
I chose not to use a pointer though as the OP simply assigned a value. In the case of a pointer you would be adding 4 as opposed to 1 which makes inc the slower of the 2 as it would be required 4 times as often.
>I just (wrongly) assumed that all compilers would compile simple increments the same
As with many compiler specifics, it's not quite that simple. Depending on the target processor, different instructions may be deemed more efficient. So you'll see compilers favoring for example add over inc, or lea over both add and inc. The bias can change even within the same processor family. So the machine code itself may vary depending on hardware targets.
In terms of which of ++x , x++ , x+=1 , and x=x+1 is faster, you're talking about one of the most basic of basic optimizations (even Ritchie's first C compiler did this). Much like I would expect local variable allocation along with the stack frame regardless of scope rather than when execution enters each scope, I would expect all of the above (in isolation) to produce identical instructions even with optimization disabled.
So let's look at the questions I saw pop up in the thread:
Q: Which is faster, ++x or x+=1 ?
A: On any decent compiler there's no difference, but only when the expressions are taken in isolation. As part of a larger expression, there's more to consider. However, the usual guideline of "mind your own business and let the compiler handle micro-management of expressions" applies. It's better at it than you are anyway.
Q: Will the above compile to the same machine code on my compiler?
A: It's very likely, unless you have a compiler that aggressively refuses to optimize and interprets the C code as literally as possible. Barring student attempts at a toy compiler, I have yet to see any that do this.
Q: Will all compilers compile the above to the same machine code?
A: That's very unlikely. The actual machine code chosen by the compiler depends on a lot of things, and it's unreasonable to expect multiple compilers to make the same choices. However, it's not unreasonable to expect a suitably efficient choice for the situation to be selected. Despite what these "which is faster" questions imply, compiler writers are actually very good at squeezing out as much dead weight as possible.
Honestly, it wouldn't really matter which you do, because it would make EXTREMELY small changes even if you did numbers like from 0 to 2147483647! You wouldn't notice a difference really. So I'd say why would you even want to know which is faster?