Why not? This makes little sense to me. Why shouldn't a compiler optimize it?
1) Yes, I know there are rules and all that are precise and allow that.
When people write C, they often do so for specific domains. Crypto, embedded, device drivers. They choose C for these domains because they think, and they are taught that C is some kind of macro assembler, because in these domains they care deeply about the "how". If they wouldn't, they would write java or any current top 20 programming languages. So almost all optimization off looks ok. Reasonable compared to this, anyhow.
If people truly still think C is a macro assembler then that's the problem. Besides if you care deeply about how modern high performance architectures won't cut it anyway.
Compiler writers are stuck in a trap. C++ compilation model is broken. Which makes compiling C++ programs very slow. Which means compiler writers care a lot about how fast compilers are. So they desperately add more optimizations to speed up the compiler program. But which adds more work to the process of compiling a program.
Most of the other users, especially C programmers don't care about speed nearly as much. Notably because while the compilation model for C is also broken, it's not nearly so. So their programs compile in a few seconds, not minutes to hours.
If they really thought that speed was the most important thing wouldn't that abandon those languages for C++.
Explain yourself.
FreePascal only does safe optimizations. (unless it has bugs where it does work at all)
So your argument is "people not using C don't care about the speed of C"? What is this supposed to be proving?
> compiler writers care a lot about how fast compilers are. So they desperately add more optimizations to speed up the compiler program. But which adds more work to the process of compiling a program.
Compiler writers are stuck. The more optimizations they add. The more work the compiler has to do. And the slower it runs. Defeating the purpose of those optimizations.
If you write other types of programs the compilers speed and your programs speed aren't the same at all. People that write other types of programs care more how fast the compiler is and less how fast their programs run. People that write programs that process entrusted data care vastly more about no surprises than they care about speed. Even more so, in modern code bases the hot sections are very small parts of the total code base. For 99% of the code, CPU speed doesn't matter.
The whole thing is made worse because of the disconnect between modern CPU's and machine implemented by C++.
Literally everything you ask for here is fulfilled by not turning on compiler optimizations. That's the default. I don't understand what your complaint is.
And since nobody stated it plainly to you yet: This whole world view is completely bogus. Entire branches of the industry require C++ compilers that produce the fastest possible code (to name a few: Games, HFT, image processing). I don't know how you convinced yourself that compiler writers are the only consumers of compiler optimizations, but it's dead wrong. I don't claim your experience or what tradeoffs you seek in a compiler are wrong, but they are extremely far from universal.
> How likely do you think is it that a program that contains memset and has this optimisation applied how diverts from the indented behaviour and now has a serious flaw in it?
What if this optimization happens after three levels of inlining and some other dead code elimination? Is that "diverting from intended behavior"?
Almost every time.
Yeah, the times when it leads to problems are more important individually. And I have no idea of the overall picture. But looking purely at the frequency, those you enumerate basically never happen.
C really needs a "I mean this!" marker that one can use on those cases. Rust also would gain from some kind of predictable region similar to unsafe, but C would have to gain it first.
The article is about C++ which people choose because they want to go fast. Which is also the dominant reason people choose C (embedded & device drivers both absolutely care about performance & efficiency, too, after all).
You can't have both "C is fast" and also "compilers can't optimize." That's not how that works. Similarly if you're just starting out in crypto and you're reaching for C you're already in a bad place and atomic optimizations are the least of your concerns. C is a terrible language for crypto.
Maybe people using Java or various interpretted languages are fine with that, but most C programmers want their code to be a very close mapping to what they specified.
The flag that may allow things to break is -Ofast.
Eliminating dead stores (including calls to memcpy whose result is never read) seems like one of the most basic and least objectionable optimizations I can imagine. So, if you’re against eliminating dead stores, what optimizations _are_ you okay with?
It has no idea! Which is why it should settle down.
What you seem to want is "do all the optimizations, except the ones that contradict what I 'obviously' mean", which is just not possible with current technology.
Even that isn't enough, unless you go with a CPU that doesn't have any branch prediction, speculative execution, or out-of-order execution. I'm not aware of any such processors.