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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
