If the possibility of this flaw were covered by a regression test, then the flaw wouldn't exist.
As long as bugs exist and are found in the field, we can continue to ask the question why these bugs were not covered by testing.
The other part is that bugs are found because "extensive" isn't anywhere near "exhaustive".
For this given bug, there exists some requirements in the ISO C standard. We could ask, why don't we have coverage of all ISO C requirements in the test suite. But even if we had that coverage of all requirements, it won't catch all bugs like this. There are ways of validating these requirements such that the bug won't show up.
The requirements end up violated here through an obscure cascade of unintended consequences, not through a lack of implementation. The repro test case is quite contrived. It treats a piece of memory with no declared type as int. It loads the value from that memory into a temporary variable, then temporarily re-purposes them emory as type double, and then re-purposes it again as int---by storing the original, stashed temp value back into it. This happens all in the same scope. Because the re-purposing of memory is valid, the store back of the temporary variable isn't in fact redundant in this case, as the optimizer is programmed to think.
Catching the problem requires the specific combination of testing the redundancy elimination together with code which re-purposes memory twice in the same scope.
Suppose that you have 12 different optimizations which take advantage of strict aliasing, and 11 of them respect the concept of "effective type" for an object of no declared type. To catch the problem, you need to write the code which exercises requirements related to "effective type", and which elicits that one buggy optimization out of the compiler.
Such combinations of interacting features this explode the testing space. It's not enough to test them in isolation. That optimization, tested in isolation, looks fine. "Effective type" is honored just fine---in absence of that optimization.
[1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=23341...