I'm just a crummy engineer that writes a fair amount of embedded firmware. When this subject comes up I've found mainstream programmers attitude towards these sorts of concerns to be actually hostile. A lot of programmers think when specification gives the compile maintainers a choice between making the code do something platform specific or something silently malicious, to do the malicious thing in order to 'teach the programmer a lesson'

I'm with you. These guys aren't helping us, our customers or the people that pay the bills.

These guys put thousands of hours to maintain and improve a compiler you get for free. Thousands of programmers welcome each and every release jumping to a change log. Every major GCC version lately introduced significant optimizer improvements, new diagnostics, new warnings, faster compile time etc.

How can you claim these guys aren't helping "us" is beyond me. I am developing a small project with just a little over 1000 customers. GCC team efforts over last few years saved thousands of dollars in hardware and electricity costs as well as hundred of hours of computation just because GCC 5.3 produced very significantly faster code than GCC 4.x for low x.

The part you are forgetting is that the commercial compiler vendors do the same things.

These issues aren't specific to gcc, rather to the culture of C and C++ compiler writers, regardless how those compilers are developed.

Bugs are different issue than optimizer being more aggressive. We would all like to avoid bugs but it's hard. There will never be improvement if we don't allow for the possibility of bugs being introduced.

Yes. I think, if I had to do embedded work, I would use Ada.

I immediately thought about the same language. It's clean, safe, fast and explicit, even if a bit verbose. With a quite nice compiler, last time I checked (some 10 years ago), and without "undefined behaviour".

Or even use an explicit C-like dialect that defines more things, if you like the syntax.

Optimally a compiler's version of a language is better defined simply by it's definitions. It's just problematic if the behavior is changed between versions, eg. for the sake of optimizations. It's also bad if undefined behavior is expected to be reliable where the original implementation wasn't intended to be meaningful in the first place.

If those two cases are hard to tell apart, the process of announcing this is at fault, I guess, e.g. the error messages and warnings, the documentation, the info hidden in discussions on the mailinglists or in bug reports, but the gcc docs seem fairly extensive and I can't claim to have read it completely or the c standard.