>>! In D5694#4, @rnk wrote:
> I think recording the MSAsmStmt in the statement field of the LabelDecl is
> probably the way to go here. Then we can wait until the end of the function
> to check what label went where.
OK, I'll try doing that.
================
Comment at: lib/Parse/ParseStmtAsm.cpp:50
@@ +49,3 @@
+ /// The LabelDecls encountered when parsing the asm block.
+ std::set<LabelDecl*> LabelDecls;
+
----------------
rnk wrote:
> This can be `SmallPtrSet<LabelDecl*, 4>`. Sorry, we have a silly STL allergy.
> :)
np, I'm not new to that allergy. ;)
================
Comment at: lib/Parse/ParseStmtAsm.cpp:118
@@ +117,3 @@
+ for (const auto *Label : LabelDecls) {
+ if (!Label->isResolvedMSAsmLabel()) {
+ TheParser.getActions().DiagnoseCrossBlockLabelUse(Label);
----------------
rnk wrote:
> Do we reject this?
> void f(int x) {
> __asm {
> label:
> nop
> }
> x++;
> __asm {
> cmp x, 10
> je label
> }
> }
Ah, no. :( Sorry I must have caught this myself. I'll fix it.
================
Comment at: test/Sema/ms-inline-asm.c:109
@@ -108,3 +108,3 @@
__declspec(naked) int t5(int x) { // expected-note {{attribute is here}}
- asm { movl eax, x } // expected-error {{parameter references not allowed in
naked functions}} expected-error {{use of undeclared label 'x'}}
+ asm { movl eax, x } // expected-error {{parameter references not allowed in
naked functions}} expected-error {{use of undeclared label 'x'}} expected-error
{{cannot use inline assembly label 'x' defined outside of an inline assembly
block}}
asm { retl }
----------------
rnk wrote:
> Hm, this diagnostic is pretty bad. :( We should try returning the found
> declaration even when we generate the first diagnostic to suppress these
> follow on diagnostics.
Can I do that in a separate patch? It's only tangentially related to this
change.
http://reviews.llvm.org/D5694
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
