What Every C Programmer Should Know About Undefined Behavior #3/3

Unsafe optimizations aught to be a solvable problem. Once the executable code has been generated, it should be possible to say in a well-defined subset of cases whether the resultant binary is trying to perform a nonsense operation.

If the code has symbols that state what line(s) of source are involved and what optimization(s) were used, you could always give a really verbose warning to say that this specific combination is potentially invalid.

Or, for cleverer results, make the compilation multi-pass. Where a block of intermediate source produces bad results, disable the most likely offending optimizations and try again until either there's nothing left or the tests say that the compilation looks ok.

The disadvantage of the former is that the warnings would be horribly verbose and drown developers in information. The disadvanatge of the latter is that it's slow and of indeterminate duration for relatively marginal gains in what you hope are fringe cases (where the original code is good but the compiler's herustics screw up).

In general, fixing the developers is easier than fixing the freakier cases.