Re: Baby X is bor nagain

On 20/06/2024 22:21, Vir Campestris wrote:

On 17/06/2024 20:29, David Brown wrote:

I do my C development with optimisations enabled, which means that the C compiler will obey all the rules and requirements of C.  Optimisations don't change the meaning of correct code - they only have an effect on the results of your code if you have written incorrect code.  I don't know about you, but my aim in development is to write /correct/ code. If disabling optimisations helped in some way, it would be due to bugs and luck.

 To me disabling optimisations does one slightly useful thing (compiles a little quicker) and one really useful one. It makes the interactive debugger work. Optimised code confuses the debugger, especially when it does things like reorder code, unroll loops, or merge equivalent functions.
 Of course I then test with the optimised version.
 Andy

I understand your viewpoint and motivation.  But my own experience is mostly different.
First, to get it out of the way, there's the speed of compilation. While heavy optimisation (-O3) can take noticeably longer, I never see -O0 as being in any noticeable way faster for compilation than -O1 or even -O2.  (I'm implicitly using gcc options here, but it's mostly applicable to any serious compiler I have used.)  Frankly, if your individual C compiles during development are taking too long, you are doing something wrong.  Maybe you are using far too big files, or trying to do too much in one part - split the code into manageable sections and possibly into libraries, and it will be far easier to understand, write and test.  Maybe you are not using appropriate build tools.  Maybe you are using a host computer that is long outdated or grossly underpowered.
There are exceptions.  Clearly some languages - like C++ - are more demanding of compilers than others.  And if you are using whole-program or link-time optimisation, compilation and build time is more of an issue - but of course these only make sense with strong optimisation.
Secondly, there is the static error analysis.  While it is possible to do this using additional tools, your first friend is your compiler and its warnings.  (Even with additional tools, you'll want compiler warnings enabled.)  You always want to find your errors as early as possible - from your editor/IDE, your compiler, your linker, your additional linters, your automatic tests, your manual tests, your beta tests, your end user complaints.  The earlier in this chain you find the issue, the faster, easier and cheaper it is to fix things.  And compilers do a better job at static error checking with strong optimisations enabled, because they do more code analysis.
Thirdly, optimisation allows you to write your code with more focus on clarity, flexibility and maintainability, relying on the compiler for the donkey work of efficiency details.  If you want efficient results (and that doesn't always matter - but if it doesn't, then C is probably not the best choice of language in the first place) and you also want to write good quality source code, optimisation is a must.
Now to your point about debugging.  It is not uncommon for me to use debuggers, including single-stepping, breakpoints, monitoring variables, modifying data via the debugger, and so on.  It is common practice in embedded development.  I also regularly examine the generated assembly, and debug at that level.  If I am doing a lot of debugging on a section of code, I generally use -O1 rather than -O0 - precisely because it is far /easier/ to understand the generated code.  Typically it is hard to see what is going on in the assembly because it is swamped by stack accesses or code that would be far simpler when optimised.  (That goes back to the focus on source code clarity and flexibility rather than micro-managing for run-time efficiency without optimisation.)
Some specific optimisation options can make a big difference to debugging, and can be worth disabling, such as "-fno-inline" or "-fno-top-reorder", and heavily optimised code can be hard to follow in a debugger.  But disabling optimisation entirely can often, IME, make things harder.
Temporarily changing optimisation flags for all or part of the code while chasing particular bugs is a useful tool, however.