title: error: jump to label 'foo' crosses initialization of 'bar'
body: <p>The following C++ example fails to compile with gcc or clang, but only generates a warning with ICC, and nothing at all with MSVC:</p>
  
  <pre><code>int main(int argc, char *argv[])
  {
      if (argc &lt; 2)
          goto clean_up;
  
  #if 1   // FAIL
      int i = 0;
  #elif 0 // workaround - OK
      {
          int i = 0;
      }
  #else   // workaround - OK
      int i;
      i = 0;
  #endif
  
  clean_up:
      return 0;
  }
  </code></pre>
  
  <p>g++:</p>
  
  <pre><code>init.cpp:13: error: jump to label ‘clean_up’
  init.cpp:4: error:   from here
  init.cpp:7: error:   crosses initialization of ‘int i’
  </code></pre>
  
  <p>clang++:</p>
  
  <pre><code>init.cpp:4:9: error: cannot jump from this goto statement to its label
          goto clean_up;
          ^
  init.cpp:7:9: note: jump bypasses variable initialization
      int i = 0;
          ^
  </code></pre>
  
  <p>ICC: </p>
  
  <pre><code>init.cpp(4): warning #589: transfer of control bypasses initialization of:
              variable "i" (declared at line 7)
            goto clean_up;
            ^
  </code></pre>
  
  <p>I understand the cause of the error, and for a simple example such as this it is fairly easy to work around (I've included a couple of possible workarounds in the example above), but I'm working on a large cross-platform legacy code base that is peppered with error-handling macros which use a similar <code>goto</code> construct. Other developers working with MSVC or ICC keep introducing inline initialisations which subsequently result in errors for gcc or clang builds (and of course they just ignore the warnings they get with MSVC/ICC).</p>
  
  <p>So I need to find a way to either (a) make such cases result in errors on ICC/MSVC or (b) reduce them to warnings with gcc/clang. I tried <code>-fpermissive</code> with gcc but that doesn't seem to help.
  <hr>
  For extra credit I'm also curious as to the rationale behind this error for simple scalar initialisation - I can see why jumping over a <em>constructor</em> might be problematic, but initialising an <code>int</code> as in the above example doesn't seem like it could ever be an issue, and simply splitting the definition+initialisation into a definition + assignment makes the error go away?</p>