On Thursday, 31 July 2014 at 22:21:46 UTC, Daniel Gibson wrote:
Am 31.07.2014 23:59, schrieb Walter Bright:
On 7/31/2014 10:40 AM, Daniel Gibson wrote:
It's a major PITA to debug problems that only happen in
release builds.
Debugging optimized code was a well known problem even back in
the 70's.
Nobody has solved it, and nobody wants unoptimized code.
Yeah, and because of this I'd like optimizations not to cause
different behavior if at all possible to keep these kind of
bugs as low as possible.
And I agree with your stance on those fine-grained optimization
switches from your other post. GCC currently has 191 flags the
influence optimization[1] (+ a version that negates them for
most), and I don't understand what most of them do, so it would
be hard for me to decide which optimizations I want and which I
don't want.
However, what about an extra flag for "unsafe" optimizations?
I'd like the compiler to do inlining, replacing int
multiplications with powers of two with shifts and other "safe"
optimizations that don't change the semantics of my program
(see the examples in the post you quoted), but I *don't* want
it to e.g. remove writes to memory that isn't read afterwards
or make assumptions based on assertions (that are disabled in
the current compile mode).
And maybe a warning mode that tells me about
"dead"/"superfluous" code that would be eliminated in an
optimized build so I can check if that would break anything for
me in that respect without trying to understand the asm output
would be helpful.
A compiler is a program that turns code in one programming
language to equivalent machine code, according to a language
specification. There are obviously many different equivalent
machine code programs corresponding to any sufficiently complex
higher-level program. Classifying them into optimized and
unoptimized ones is rather arbitrary. The same goes for safe vs.
unsafe optimizations.
To achieve what you want, the compiler would have to ignore the
actual language specification and use a different one that is
tweaked according to your criteria. I don't think this is
desirable. If the official language specification has parts that
can lead to the errors you want to avoid, then it's not the
compiler's fault, and therefore the compiler should not be
changed to workaround it. Instead, deficiencies in the
specification should be fixed there.
