You ask a question that one could write a thesis on, so I'm not going to try to cover it in depth here. Ideally, of course, you would write strictly conforming C code with no bugs and the compiler would have no bugs, but as is the way of things, those conditions are not always fulfilled. You use the best tools you can, and fix or work around what you can. The C standard is a contract between the user's code and the compiler, and you have every right to expect that the compiler adheres to that contract. Sometimes it won't, and we will do our best to fix that in a timely manner, if possible. You should also be prepared to fix source code that isn't legal C, or possibly not portable C. When we analyze a bug, we will strive to provide a feasible workaround. Since we don't have the resources to immediately release a fix for every bug, you should expect that you may need to use the workaround until we can get you a patched compiler. So as a practical matter, you should use the workaround or wait for a fixed compiler.
As to this particular bug, I can't speculate what part of the compiler creates the problem, as I cannot reproduce it. I await a more complete test case. However, from the looks of it, it is probably a compiler bug.