I still want to write at least one sequel to that post, on the theme “Alright, can we make a Friendly C Compiler by disabling the annoying optimizations, then?”.
Obviously the people who want a Friendly C Compiler do not want to disable all optimizations. This would be easy to do, but these users do not want the stupid 1+2+16 expressions in their C programs, generated through macro-expansion, to be compiled to two additions with each intermediate result making a round-trip through memory.
So the question is: can we get a Friendly C Compiler by enabling only the Friendly optimizations in an unfriendly compiler?
And for the answer to that, I had to write an entire other blog post as preparation, to show that there are some assumptions an optimizing compiler can do:
- that may be used in one or several optimizations, but the compiler authors did not really keep track of where they were used,
- that cannot be disabled and that the compiler maintainers will not consider having an option to disable,
- and that are definitely unfriendly.
Here is the URL of the blog post that I had to write in preparation for the upcoming blog post about getting ourselves a Friendly C Compiler: https://trust-in-soft.com/blog/2020/04/06/gcc-always-assumes... . I recommend you take a look, I think it is interesting in itself.
You will have guessed that I'm not optimistic about the approach. We can try to maintain a list of friendly optimizations for ourselves, though, even if the compiler developers are not helping. This might still be less work that maintaining a C compiler.
> Here is the URL of the blog post that I had to write in preparation for the upcoming blog post about getting ourselves a Friendly C Compiler: https://trust-in-soft.com/blog/2020/04/06/gcc-always-assumes.... . I recommend you take a look, I think it is interesting in itself.
So, it's definitely interesting -- I think a lot of odd stuff you can do should probably be undefined. Eliminating pointer accesses after a null check sounds A-ok to me, because your program should never dereference null.
Another interesting thought is requiring more of these things that lead to miscompilation to produce compile time diagnostics.
Obviously the people who want a Friendly C Compiler do not want to disable all optimizations. This would be easy to do, but these users do not want the stupid 1+2+16 expressions in their C programs, generated through macro-expansion, to be compiled to two additions with each intermediate result making a round-trip through memory.
So the question is: can we get a Friendly C Compiler by enabling only the Friendly optimizations in an unfriendly compiler?
And for the answer to that, I had to write an entire other blog post as preparation, to show that there are some assumptions an optimizing compiler can do:
- that may be used in one or several optimizations, but the compiler authors did not really keep track of where they were used,
- that cannot be disabled and that the compiler maintainers will not consider having an option to disable,
- and that are definitely unfriendly.
Here is the URL of the blog post that I had to write in preparation for the upcoming blog post about getting ourselves a Friendly C Compiler: https://trust-in-soft.com/blog/2020/04/06/gcc-always-assumes... . I recommend you take a look, I think it is interesting in itself.
You will have guessed that I'm not optimistic about the approach. We can try to maintain a list of friendly optimizations for ourselves, though, even if the compiler developers are not helping. This might still be less work that maintaining a C compiler.