[PATCH] Fix to PR8880 (clang dies processing a for loop).

[Richard Smith]

  Have you checked that IR generation does the right thing in these cases? A CodeGen test for this would be useful.


================
Comment at: test/Parser/bad-control.c:22-30
@@ +21,11 @@
+
+// GCC rejects this code
+void pr8880_3(int first) {
+  for ( ; ; (void)({ if (first) { first = 0; continue; } 0; })) {}
+}
+
+// GCC rejects this code (see also tests/Analysis/dead-stores.c rdar8014335()
+void pr8880_4(int first) {
+  for ( ; ; (void)({ if (first) { first = 0; break; } 0; })) {}
+}
+
----------------
Serge Pavlov wrote:
> Richard Smith wrote:
> > Does this mean we're misinterpreting pr8880_10 and pr8880_11 below?
> No, this is a feature of GCC. It uses different interpretation depending on whether code is compiled as C or as C++. In C++ mode break and continue in the second or third expression of for statement refer to the inner loop, in C mode - to the outer. However in both modes GCC reject using break/continue if for statement is not inside another loop. Clang is more consistent, it considers that the third expression refers to the inner loop and the second - to outer, the interpretation is the same in C and C++ mode.
Interesting. I agree that it makes little sense for C and C++ to differ here, other than GCC compatibility.

Why does break/continue in the second expression bind to the inner scope and the third expression bind to the outer? It seems strange that we would (deliberately) differ from both GCC's C mode and its C++ mode here.

Since GCC rejects this if the loop is non-nested, it seems more reasonable to me for them to always bind to the surrounding scope. Is there a reason to not do that?


http://llvm-reviews.chandlerc.com/D2018