Support output constraints on "asm goto"

[void]

Summary

Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.

Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.

In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.

[void]

Emit asm goto fallthrough early so that any value extracts will show up in the
fallthrough block and not directly after the callbr.

[void]

Adjust the ASM so that it references labels.

[void]

This change is ready for review. PTAL.

[jyknight]

I think -Wuninitialized (UninitializedValues.cpp) should be taught how to detect the use of output variables in error blocks, at least for trivial cases.

Actually, for some reason -- it looks like the warning is failing the wrong way right now, and emits an uninitialized use warning even where there shouldn't be one.

E.g. this example should be okay:

int foo(int x) {
  int y;
  asm goto("# %0 %1 %2" : "=r"(y) : "r"(x) : : err);
  return y;
err:
  return -1;
}

But now warns:

$ clang -Wall -fsyntax-only foo.c
foo.c:4:10: warning: variable 'y' is uninitialized when used here [-Wuninitialized]
  return y;
         ^
foo.c:2:8: note: initialize the variable 'y' to silence this warning
  int y;
       ^
        = 0
1 warning generated.

I'd expect a warning only if the code was modified to say "return y" in the err block.

[jyknight]

Also, since this means we are no longer simply implementing according to GCC's documentation, I think this means we'll need a brand new section in the Clang docs for its inline-asm support.

[void]

Analyze "asm goto" for initialized variables.

An "asm goto" statement is a terminator and thus doesn't indicate variable
assignments like normal inline assembly. Handle them specially.

[void]

In D69876#1740286, @jyknight wrote:

I think -Wuninitialized (UninitializedValues.cpp) should be taught how to detect the use of output variables in error blocks, at least for trivial cases.

Actually, for some reason -- it looks like the warning is failing the wrong way right now, and emits an uninitialized use warning even where there shouldn't be one.

Nice catch! I updated the patch with a fix. PTAL.

[void]

In D69876#1740289, @jyknight wrote:

Also, since this means we are no longer simply implementing according to GCC's documentation, I think this means we'll need a brand new section in the Clang docs for its inline-asm support.

Sure. Which file do we list such things in?

[nickdesaulniers]

In D69876#1741294, @void wrote:

In D69876#1740286, @jyknight wrote:

I think -Wuninitialized (UninitializedValues.cpp) should be taught how to detect the use of output variables in error blocks, at least for trivial cases.

Actually, for some reason -- it looks like the warning is failing the wrong way right now, and emits an uninitialized use warning even where there shouldn't be one.

Nice catch! I updated the patch with a fix. PTAL.

Please add a test for that!

[void]

the real update this time.

[void]

In D69876#1741381, @nickdesaulniers wrote:

Nice catch! I updated the patch with a fix. PTAL.

Please add a test for that!

I did, but the "arc" program pushed the wrong change. :-( Fixed.

When are we going to use GitHub's PRs?

[void]

Add blurb about asm goto with output constraints to the "language extensions"
documentation.

[void]

Adjust label references to account for in/out constraints.

[void]

Move adjustment before error check.

[void]

Friendly ping. :-)

[nickdesaulniers]

clang/lib/Analysis/UninitializedValues.cpp

830

GCCAsmStmt inherits from AsmStmt which has an outputs() method for returning an iterator. Please use that an a range based for loop.

875

Don't declare as as const, then you won't need this const_cast.

[void]

Remove a "const_cast" and use iterators for output constraints.

[void]

Changes made. PTAL

[nickdesaulniers]

clang/lib/Analysis/UninitializedValues.cpp

831

this is still not a range based for loop.

Does:

for (const auto &O : as->outputs())
  if (const VarDecl *VD = findVar(O).getDecl())
    vals[VD] = Initialized;

not work?

[void]

Adjust loop.

[void]

clang/lib/Analysis/UninitializedValues.cpp

831

Done.

[void]

Any further comments?

[rnk]

Changes seem fine to me, FWIW.
+@rsmith

clang/test/Analysis/uninit-asm-goto.cpp

11

This could use a test for the case where an input is uninitialized, and where an uninitialized value is used along the error path.

[void]

clang/test/Analysis/uninit-asm-goto.cpp

11

I have a follow-up patch that I'll upload soon that warns about uninitialized variable use on the indirect paths. I wanted to separate it to keep this patch size down. If you'd prefer I can just add it.

[void]

Note to reviewers: I would *really* like to get this feature into the 10.0.0 release. That's coming up in January. Do you think you'll have your reviews finished by then?

[nickdesaulniers]

Thinking hard about this, I think there's four cases we really need to think hard about:

1. asm redirects control flow BEFORE assigning to output. ie.

int foo(void) {
  int y;
  asm volatile goto ("ja %l1" : "=r"(y) ::: err);
  return y;
err:
  return y;
}

I think we can chalk this up to user error; stupid asm in, stupid asm out. If the inline asm never assigns to the output, regardless of how the assembly block is exited, there's nothing we can do. Your child patch (https://reviews.llvm.org/D71314) warns in the second return, though the first return is equally invalid.

2. asm redirects control flow AFTER assigning to output. ie.

int foo(void) {
  int y;
  asm volatile goto ("mov 42, %0; ja %l1" : "=d"(y) ::: err);
  return y;
err:
  return y;
}

Why is this not valid in the case the indirect branch is taken?

The two other cases I can think of are in regards to conflicting constraints. Consider for example the x86 machine specific output constraints (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints):

3. shared indirect destinations with differing/conflicting constraints

void foo(void) {
    int y;
    asm volatile ("mov 42, %0" : "=d"(y));
}
void bar(void) {
    int y;
    asm volatile ("mov 42, %0" : "=c"(y));
}
void baz(void) {
    int y;
    asm volatile goto ("mov 42, %0; ja %1": "=d"(y) ::: quux);
    asm volatile goto ("mov 42, %0; ja %1": "=c"(y) ::: quux);
    return;
quux:
    return;
}

foo puts 42 in %edx. bar puts 42 in %ecx. Where should baz put 42? Your current patch set produces: error: Undefined temporary symbol.

4. conflicts between register variables and output constraints.

void foo(void) {
    register int y asm("edx") = 0;
    asm volatile goto ("mov 42, %0; ja %l1" : "=c"(y) ::: bar);
bar:
    return;
}
void baz(void) {
    register int y asm("edx") = 0;
    asm volatile ("mov 42, %0" : "=c"(y));
}

The output constraint for asm goto says put the output in %ecx, yet the variable was declared as having register storage in %edx.

Looks like Clang already has bugs or at least disagrees with GCC (for the simpler case of baz, but the problem still exists for foo). Filed https://bugs.llvm.org/show_bug.cgi?id=44328.

I need to think more about this, but I feel like people may see #2 as a reason to not use this feature and I have serious concerns about that.

clang/docs/LanguageExtensions.rst

1275

Would you mind removing the above in this sentence. I initially parsed this as the block above err, which is not correct.

[void]

In D69876#1791475, @nickdesaulniers wrote:

Thinking hard about this, I think there's four cases we really need to think hard about:

1. asm redirects control flow BEFORE assigning to output. ie.

int foo(void) {
  int y;
  asm volatile goto ("ja %l1" : "=r"(y) ::: err);
  return y;
err:
  return y;
}

I think we can chalk this up to user error; stupid asm in, stupid asm out. If the inline asm never assigns to the output, regardless of how the assembly block is exited, there's nothing we can do. Your child patch (https://reviews.llvm.org/D71314) warns in the second return, though the first return is equally invalid.

Right. This is human error. Unless we can parse the inline assembly (not something I'm suggesting) we won't be able to help them here.

2. asm redirects control flow AFTER assigning to output. ie.

int foo(void) {
  int y;
  asm volatile goto ("mov 42, %0; ja %l1" : "=d"(y) ::: err);
  return y;
err:
  return y;
}

Why is this not valid in the case the indirect branch is taken?

I'm not saying that it's *always* invalid, but we won't be able to guarantee correctness during code gen. For example, if you have something like:

int foo(int x) {
  int y;
  if (x < 42)
    asm volatile goto ("mov 42, %0; ja %l1" : "=D"(y) ::: err);
  else
    asm volatile goto ("mov 0, %0; ja %l1" : "=S"(y) ::: err);
  return y;
err:
  return y;
}

we can't necessarily code gen this correctly for the err block. There was a long thread on ways we could try to do this, but they were all very sub-standard.

The two other cases I can think of are in regards to conflicting constraints. Consider for example the x86 machine specific output constraints (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints):

3. shared indirect destinations with differing/conflicting constraints

void foo(void) {
    int y;
    asm volatile ("mov 42, %0" : "=d"(y));
}
void bar(void) {
    int y;
    asm volatile ("mov 42, %0" : "=c"(y));
}
void baz(void) {
    int y;
    asm volatile goto ("mov 42, %0; ja %1": "=d"(y) ::: quux);
    asm volatile goto ("mov 42, %0; ja %1": "=c"(y) ::: quux);
    return;
quux:
    return;
}

foo puts 42 in %edx. bar puts 42 in %ecx. Where should baz put 42? Your current patch set produces: error: Undefined temporary symbol.

Whatever is done for inline assembly that's not "goto" is done here. Or at least should be. I'll fix the error message. But in essence it will move the correct value into the correct register. In this case, it should move 42 into both %edx and %ecx. The temporary symbol issue is most likely unrelated.

4. conflicts between register variables and output constraints.

void foo(void) {
    register int y asm("edx") = 0;
    asm volatile goto ("mov 42, %0; ja %l1" : "=c"(y) ::: bar);
bar:
    return;
}
void baz(void) {
    register int y asm("edx") = 0;
    asm volatile ("mov 42, %0" : "=c"(y));
}

The output constraint for asm goto says put the output in %ecx, yet the variable was declared as having register storage in %edx.

Looks like Clang already has bugs or at least disagrees with GCC (for the simpler case of baz, but the problem still exists for foo). Filed https://bugs.llvm.org/show_bug.cgi?id=44328.

I need to think more about this, but I feel like people may see #2 as a reason to not use this feature and I have serious concerns about that.

Both functions generate the same output for me:

foo:                                    # @foo
	.cfi_startproc
# %bb.0:                                # %entry
	#APP
	movl	42, %edx
	ja	.Ltmp0
	#NO_APP
.Ltmp0:                                 # Block address taken
.LBB0_1:                                # %bar
	retq
.Lfunc_end0:
	.size	foo, .Lfunc_end0-foo
	.cfi_endproc
                                        # -- End function
	.globl	baz                     # -- Begin function baz
	.p2align	4, 0x90
	.type	baz,@function
baz:                                    # @baz
	.cfi_startproc
# %bb.0:                                # %entry
	#APP
	movl	42, %edx
	#NO_APP
	retq

Note that we're not going to be able to fix all of clang's inline assembly bugs with this feature. :-)

[void]

I'm not getting the Undefined temporary symbol in your example (even with optimizations):

[morbo@fawn:llvm-project] cat ../bug.c
void baz(void) {
    int y;
    asm volatile goto ("mov 42, %0; ja %1": "=d"(y) ::: quux);
    asm volatile goto ("mov 42, %0; ja %1": "=c"(y) ::: quux);
    return;
quux:
    return;
}
[morbo@fawn:llvm-project] clang -o - -S ../bug.c
	.text
	.file	"bug.c"
	.globl	baz                     # -- Begin function baz
	.p2align	4, 0x90
	.type	baz,@function
baz:                                    # @baz
	.cfi_startproc
# %bb.0:                                # %entry
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register %rbp
	#APP
	movl	42, %edx
	ja	.Ltmp00
	#NO_APP
	movl	%edx, -8(%rbp)          # 4-byte Spill
	jmp	.LBB0_1
.LBB0_1:                                # %asm.fallthrough
	movl	-8(%rbp), %eax          # 4-byte Reload
	movl	%eax, -4(%rbp)
	#APP
	movl	42, %ecx
	ja	.Ltmp00
	#NO_APP
	movl	%ecx, -12(%rbp)         # 4-byte Spill
	jmp	.LBB0_2
.LBB0_2:                                # %asm.fallthrough1
	movl	-12(%rbp), %eax         # 4-byte Reload
	movl	%eax, -4(%rbp)
	jmp	.LBB0_4
.Ltmp0:                                 # Block address taken
.LBB0_3:                                # %quux
	jmp	.LBB0_4
.LBB0_4:                                # %return
	popq	%rbp
	.cfi_def_cfa %rsp, 8
	retq
.Lfunc_end0:
	.size	baz, .Lfunc_end0-baz
	.cfi_endproc
                                        # -- End function
	.ident	"clang version 10.0.0 (https://github.com/llvm/llvm-project.git 5b71b09a54edbb20900e6d13de35d2592f788330)"
	.section	".note.GNU-stack","",@progbits
	.addrsig
	.addrsig_sym baz

[nickdesaulniers]

In D69876#1791663, @void wrote:

I'm not getting the Undefined temporary symbol in your example (even with optimizations):

[morbo@fawn:llvm-project] clang -o - -S ../bug.c

-S is going the AsmPrinter route. I observe the error with -c. The error goes away with -c -no-integrated-as pointing to an issue with LLVM.

In D69876#1791655, @void wrote:

In D69876#1791475, @nickdesaulniers wrote:

2. asm redirects control flow AFTER assigning to output. ie.

int foo(void) {
  int y;
  asm volatile goto ("mov 42, %0; ja %l1" : "=d"(y) ::: err);
  return y;
err:
  return y;
}

Why is this not valid in the case the indirect branch is taken?

I'm not saying that it's *always* invalid, but we won't be able to guarantee correctness during code gen.

The language added in this patch states:

It's important to note that outputs are valid only on the "fallthrough" branch.

So maybe only should be replaced? Or maybe an additional statement informing the user that they must take care not to write inline assembly in such a way that transfers control flow to an indirect target from the inline asm, then expect to use the output? Or states that it's explicitly undefined behavior whether the output is usable after the indirect branch is taken?

In D69876#1791475, @nickdesaulniers wrote:

I need to think more about this, but I feel like people may see #2 as a reason to not use this feature and I have serious concerns about that.

I tried to dig up some prior art for this. I found two cases that I think calm my concerns:

1. GCC bugs (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381) particularly https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381#c2, copied inline for emphasis:

Note that if output was only reliable on the fall-through path, it would already be useful.

2. LKML posts (https://lkml.org/lkml/2018/2/14/625, https://lkml.org/lkml/2018/2/14/656) particularly:

But extending on what gcc does, and allowing outputs (possibly valid
in the fall-through case only, not in the cases where it jumps away to
a label) would be a big improvement on what gcc does.

So I guess I should shelve my concerns for the minimum viable product. It might be good to reach out to luto about what that __get_user implementation looks like, and how we might wire up support in the kernel for detecting compiler support for asm goto w/ output constraints, then being able to use it. I'd be happy to help implement that.

One test I think it would be worthwhile to add here is to address the concern from the description of this bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615); ie. that an output was properly clobbered. None of the existing or added test cases seem to test this. I'd expect such a test to read from a variable, use it as an output to an asm goto, then in the fallthrough use it, and we'd check that the updated value was used. But I don't see any such tests in llvm/test/...

Note that we're not going to be able to fix all of clang's inline assembly bugs with this feature. :-)

:P

clang/test/Sema/asm-goto.cpp

41

what's going on with the indentation?

44

Maybe the formatting changes to the tests (that don't add new tests or meaningfully change existing ones) above can just be pre-committed?

[void]

In D69876#1791989, @nickdesaulniers wrote:

In D69876#1791663, @void wrote:

I'm not getting the Undefined temporary symbol in your example (even with optimizations):

[morbo@fawn:llvm-project] clang -o - -S ../bug.c

-S is going the AsmPrinter route. I observe the error with -c. The error goes away with -c -no-integrated-as pointing to an issue with LLVM.

Okay. I'll check into it.

In D69876#1791655, @void wrote:

In D69876#1791475, @nickdesaulniers wrote:

2. asm redirects control flow AFTER assigning to output. ie.

int foo(void) {
  int y;
  asm volatile goto ("mov 42, %0; ja %l1" : "=d"(y) ::: err);
  return y;
err:
  return y;
}

Why is this not valid in the case the indirect branch is taken?

I'm not saying that it's *always* invalid, but we won't be able to guarantee correctness during code gen.

The language added in this patch states:

It's important to note that outputs are valid only on the "fallthrough" branch.

So maybe only should be replaced? Or maybe an additional statement informing the user that they must take care not to write inline assembly in such a way that transfers control flow to an indirect target from the inline asm, then expect to use the output? Or states that it's explicitly undefined behavior whether the output is usable after the indirect branch is taken?

I'm afraid that if we open the door for people to use outputs on indirect branches when it's not fully supported then we'll have to support that "feature" forever, when in reality it's an accident of implementation. It might just be best to say that it's undefined behavior.

In D69876#1791475, @nickdesaulniers wrote:

I need to think more about this, but I feel like people may see #2 as a reason to not use this feature and I have serious concerns about that.

I tried to dig up some prior art for this. I found two cases that I think calm my concerns:

1. GCC bugs (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381) particularly https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381#c2, copied inline for emphasis:

Note that if output was only reliable on the fall-through path, it would already be useful.

2. LKML posts (https://lkml.org/lkml/2018/2/14/625, https://lkml.org/lkml/2018/2/14/656) particularly:

But extending on what gcc does, and allowing outputs (possibly valid
in the fall-through case only, not in the cases where it jumps away to
a label) would be a big improvement on what gcc does.

So I guess I should shelve my concerns for the minimum viable product. It might be good to reach out to luto about what that __get_user implementation looks like, and how we might wire up support in the kernel for detecting compiler support for asm goto w/ output constraints, then being able to use it. I'd be happy to help implement that.

I think clang normally uses something like has_attribute for things like this. Could you contact luto and ask for an example?

One test I think it would be worthwhile to add here is to address the concern from the description of this bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615); ie. that an output was properly clobbered. None of the existing or added test cases seem to test this. I'd expect such a test to read from a variable, use it as an output to an asm goto, then in the fallthrough use it, and we'd check that the updated value was used. But I don't see any such tests in llvm/test/...

I'll add some tests for these.

Note that we're not going to be able to fix all of clang's inline assembly bugs with this feature. :-)

:P

[void]

• Improve the asm goto note in the language extensions doc.

• Include another testcase.

clang/docs/LanguageExtensions.rst

1275

I changed it.

clang/test/Sema/asm-goto.cpp

41

Not sure. I blame emacs. :)

[nickdesaulniers]

clang/test/CodeGen/asm-goto.c

91

Thanks for adding this test. I think it doesn't test that addr is *clobbered* though?

[void]

clang/test/CodeGen/asm-goto.c

91

The + modifier indicates that addr is used for both input and output, in effect being clobbered. Otherwise, we would need to add a "clobber" list, but from what I understand that seems to be restricted to registers, memory, and cc. I wouldn't be able to specify a specific register for addr (e.g. "+D"(addr)) and also have %rdx in the clobber list.

Was there something else you were thinking of?

[nickdesaulniers]

No, thanks for the work on this @void !

[jyknight]

LGTM modulo some minor wording.

clang/docs/LanguageExtensions.rst

1256–1258

I find that sentence confusing. Maybe,
"In addition to the functionality provided by <GCC's extended assembly>, Clang also supports output constraints with the goto form."

clang/lib/AST/Stmt.cpp

646–648

I'm confused about this part. Why isn't the "N" specified in the assembly string already the correct value for the labels? Is the ordering we use internally and that users use externally not the same? I'm assuming your code here is correct, just I'm not understanding, so probably an improved comment would be nice.

[void]

Reword the extension explanation to be more readable.

clang/lib/AST/Stmt.cpp

646–648

The LLVM-specific ordering that I saw was something like:

`<output constraints>,<input constraints>,<plus constraints>,<optional X>,<other constraints>`

The <plus constraints> is empty when there are no output constraints. This just makes up for this. It's probably better to reverse the <optional X> and <plus constraints> parts, but I didn't know how pervasive the order's assumption is in the code.

[void]

Push the correct changes to Phabricator.

[jyknight]

I think you pushed the incorrect change? This was the clang half, but now it's showing the LLVM half. Can you re-upload the diff for the clang half?

[jyknight]

clang/lib/AST/Stmt.cpp

646–648

Oh, right -- in llvm IR, the "plus" constraints don't exist -- we specify those as separate-but-linked output and input constraints.

But thinking about this more...I think this code is actually incorrect. It should be translating the numbers based on where it finds the matching argument-number, not on the 'l' character being present. (And it should do so for named-arguments too).

So, yes, I think it'd be better to just swap the order, and move the plus-operand tied-inputs to the end of the arglist, where they don't affect numbering. I don't _think_ reversing the order will cause other issues.

[jyknight]

Reopening, since this didn't actually land yet. BTW, this review still has the wrong contents in the latest uploaded-diff (showing llvm changes, not clang changes).

[void]

In D69876#1812724, @jyknight wrote:

Reopening, since this didn't actually land yet. BTW, this review still has the wrong contents in the latest uploaded-diff (showing llvm changes, not clang changes).

*Pinches bridge of nose*
*Curses under breath*

clang/lib/AST/Stmt.cpp

646–648

I agree that moving them would make the most sense. Let me do some experiments to see if it breaks anything.

[void]

Move plus constraints to after the label constraints.

[MaskRay]

Does this depend on D69868?

[void]

Fix extension example, found by eagle-eye @MaskRay!

[void]

In D69876#1843199, @MaskRay wrote:

Does this depend on D69868?

Yes. I added it as a parent.

[void]

Merge "__has_extension" patch into this patch.

[void]

Typo

[vvereschaka]

Hello @void ,

this commit breaks Aarch64 builder with failed Clang::uninit-asm-goto.cpp test
http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/5020

• FAIL: Clang::uninit-asm-goto.cpp

******************** TEST 'Clang :: Analysis/uninit-asm-goto.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   c:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\build\bin\clang.exe -cc1 -internal-isystem c:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\build\lib\clang\11.0.0\include -nostdsysteminc -std=c++11 -Wuninitialized -verify C:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\llvm-project\clang\test\Analysis\uninit-asm-goto.cpp
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ "c:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\build\bin\clang.exe" "-cc1" "-internal-isystem" "c:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\build\lib\clang\11.0.0\include" "-nostdsysteminc" "-std=c++11" "-Wuninitialized" "-verify" "C:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\llvm-project\clang\test\Analysis\uninit-asm-goto.cpp"
# command stderr:
error: 'warning' diagnostics seen but not expected: 

  File C:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\llvm-project\clang\test\Analysis\uninit-asm-goto.cpp Line 6: value size does not match register size specified by the constraint and modifier

  File C:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\llvm-project\clang\test\Analysis\uninit-asm-goto.cpp Line 6: value size does not match register size specified by the constraint and modifier

error: 'note' diagnostics seen but not expected: 

  File C:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\llvm-project\clang\test\Analysis\uninit-asm-goto.cpp Line 6: use constraint modifier "w"

  File C:\buildbot\as-builder-2\llvm-clang-win-x-aarch64\llvm-project\clang\test\Analysis\uninit-asm-goto.cpp Line 6: use constraint modifier "w"

4 errors generated.

would you fix the problem or revert the commit?

[leonardchan]

*Bump* We're also seeing the same test fail on our aarch64 bots: https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-arm64/b8887516314819686496?blamelist=1#blamelist-tab

FAIL: Clang :: Analysis/uninit-asm-goto.cpp (837 of 17008)
******************** TEST 'Clang :: Analysis/uninit-asm-goto.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   /b/s/w/ir/k/recipe_cleanup/clangu2AOn_/llvm_build_dir/bin/clang -cc1 -internal-isystem /b/s/w/ir/k/recipe_cleanup/clangu2AOn_/llvm_build_dir/lib/clang/11.0.0/include -nostdsysteminc -std=c++11 -Wuninitialized -verify /b/s/w/ir/k/llvm-project/clang/test/Analysis/uninit-asm-goto.cpp
--
Exit Code: 1

Command Output (stderr):
--
error: 'warning' diagnostics seen but not expected: 
  File /b/s/w/ir/k/llvm-project/clang/test/Analysis/uninit-asm-goto.cpp Line 6: value size does not match register size specified by the constraint and modifier
  File /b/s/w/ir/k/llvm-project/clang/test/Analysis/uninit-asm-goto.cpp Line 6: value size does not match register size specified by the constraint and modifier
error: 'note' diagnostics seen but not expected: 
  File /b/s/w/ir/k/llvm-project/clang/test/Analysis/uninit-asm-goto.cpp Line 6: use constraint modifier "w"
  File /b/s/w/ir/k/llvm-project/clang/test/Analysis/uninit-asm-goto.cpp Line 6: use constraint modifier "w"
4 errors generated.

Could you send out a revert or fix soon? Thanks.

[leonardchan]

Woops, sorry. Didn't see you sent out https://reviews.llvm.org/rGe11f9fb4508534d31b09d2ba6cd22428ccc75f65.

clang/docs/LanguageExtensions.rst

 ======
 
 The syntax and high level language feature description is in
 :doc:`BlockLanguageSpec<BlockLanguageSpec>`. Implementation and ABI details for
 the clang implementation are in :doc:`Block-ABI-Apple<Block-ABI-Apple>`.
 
 Query for this feature with ``__has_extension(blocks)``.
 
+ASM Goto with Output Constraints
+================================
+
+Clang provides support for the `goto form of GCC's extended
+assembly<https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html>`_ with output
+constraints.
+
+The goto form of GCC's extended assembly allows the programmer to branch to a C
+label from within an inline assembly block. Clang extends this behavior by
+allowing the programmer to use output constriants:
+
+.. code-block:: c++
+
+  int foo(int x) {
+      int y;
+      asm goto("# %0 %1 %2" : "=r"(y) : "r"(x) : : err);
+      return y;
+    err:
+      return -1;
+  }
+
+It's important to note that outputs are valid only on the "fallthrough" branch.
+Using outputs on an indirect branch may result in undefined behavior. For
+example, in the function above, use of the value assigned to `y` in the `err`
+block is undefined behavior.
+
 Objective-C Features
 ====================
 
 Related result types
 --------------------
 
 According to Cocoa conventions, Objective-C methods with certain names
 ("``init``", "``alloc``", etc.) always return objects that are an instance of

clang/include/clang/AST/Stmt.h

bool isAsmGoto() const {
     return NumLabels > 0;
   }
 
   unsigned getNumLabels() const {
     return NumLabels;
   }
 
   IdentifierInfo *getLabelIdentifier(unsigned i) const {
-    return Names[i + NumInputs];
+    return Names[i + NumOutputs + NumInputs];
   }
 
   AddrLabelExpr *getLabelExpr(unsigned i) const;
   StringRef getLabelName(unsigned i) const;
   using labels_iterator = CastIterator<AddrLabelExpr>;
   using const_labels_iterator = ConstCastIterator<AddrLabelExpr>;
   using labels_range = llvm::iterator_range<labels_iterator>;
   using labels_const_range = llvm::iterator_range<const_labels_iterator>;
 
   labels_iterator begin_labels() {
-    return &Exprs[0] + NumInputs;
+    return &Exprs[0] + NumOutputs + NumInputs;
   }
 
   labels_iterator end_labels() {
-    return &Exprs[0] + NumInputs + NumLabels;
+    return &Exprs[0] + NumOutputs + NumInputs + NumLabels;
   }
 
   labels_range labels() {
     return labels_range(begin_labels(), end_labels());
   }
 
   const_labels_iterator begin_labels() const {
-    return &Exprs[0] + NumInputs;
+    return &Exprs[0] + NumOutputs + NumInputs;
   }
 
   const_labels_iterator end_labels() const {
-    return &Exprs[0] + NumInputs + NumLabels;
+    return &Exprs[0] + NumOutputs + NumInputs + NumLabels;
   }
 
   labels_const_range labels() const {
     return labels_const_range(begin_labels(), end_labels());
   }
 
 private:
   void setOutputsAndInputsAndClobbers(const ASTContext &C,

clang/lib/AST/Stmt.cpp

Expr *GCCAsmStmt::getInputExpr(unsigned i) {
   return cast<Expr>(Exprs[i + NumOutputs]);
 }
 
 void GCCAsmStmt::setInputExpr(unsigned i, Expr *E) {
   Exprs[i + NumOutputs] = E;
 }
 
 AddrLabelExpr *GCCAsmStmt::getLabelExpr(unsigned i) const {
-  return cast<AddrLabelExpr>(Exprs[i + NumInputs]);
+  return cast<AddrLabelExpr>(Exprs[i + NumOutputs + NumInputs]);
 }
 
 StringRef GCCAsmStmt::getLabelName(unsigned i) const {
   return getLabelExpr(i)->getLabel()->getName();
 }
 
 /// getInputConstraint - Return the specified input constraint.  Unlike output
 /// constraints, these can be empty.
int GCCAsmStmt::getNamedOperand(StringRef SymbolicName) const {
   }
 
   for (unsigned i = 0, e = getNumInputs(); i != e; ++i)
     if (getInputName(i) == SymbolicName)
       return getNumOutputs() + NumPlusOperands + i;
 
   for (unsigned i = 0, e = getNumLabels(); i != e; ++i)
     if (getLabelName(i) == SymbolicName)
-      return i + getNumInputs();
+      return i + getNumOutputs() + getNumInputs();
 
   // Not found.
   return -1;
 }
 
 /// AnalyzeAsmString - Analyze the asm string of the current asm, decomposing
 /// it into pieces.  If the asm string is erroneous, emit errors and return
 /// true, otherwise return false.
while (true) {
     }
 
     // Handle operands that have asmSymbolicName (e.g., %x[foo]) and those that
     // don't (e.g., %x4). 'x' following the '%' is the constraint modifier.
 
     const char *Begin = CurPtr - 1; // Points to the character following '%'.
     const char *Percent = Begin - 1; // Points to '%'.
 
+    bool IsLabel = false;
     if (isLetter(EscapedChar)) {
       if (CurPtr == StrEnd) { // Premature end.
         DiagOffs = CurPtr-StrStart-1;
         return diag::err_asm_invalid_escape;
       }
+      IsLabel = EscapedChar == 'l';
       EscapedChar = *CurPtr++;
     }
 
     const TargetInfo &TI = C.getTargetInfo();
     const SourceManager &SM = C.getSourceManager();
     const LangOptions &LO = C.getLangOpts();
 
     // Handle operands that don't have asmSymbolicName (e.g., %x4).
     if (isDigit(EscapedChar)) {
       // %n - Assembler operand n
       unsigned N = 0;
 
       --CurPtr;
       while (CurPtr != StrEnd && isDigit(*CurPtr))
         N = N*10 + ((*CurPtr++)-'0');
 
+      // Labels are placed after "InOut" operands. Adjust accordingly.
+      if (IsLabel)
+        N += getNumPlusOperands();
+
       unsigned NumOperands = getNumOutputs() + getNumPlusOperands() +
                              getNumInputs() + getNumLabels();
       if (N >= NumOperands) {
         DiagOffs = CurPtr-StrStart-1;
         return diag::err_asm_invalid_operand_number;
       }
 
       // Str contains "x4" (Operand without the leading %).

clang/lib/Analysis/UninitializedValues.cpp

public:
 
   void reportUse(const Expr *ex, const VarDecl *vd);
 
   void VisitBinaryOperator(BinaryOperator *bo);
   void VisitBlockExpr(BlockExpr *be);
   void VisitCallExpr(CallExpr *ce);
   void VisitDeclRefExpr(DeclRefExpr *dr);
   void VisitDeclStmt(DeclStmt *ds);
+  void VisitGCCAsmStmt(GCCAsmStmt *as);
   void VisitObjCForCollectionStmt(ObjCForCollectionStmt *FS);
   void VisitObjCMessageExpr(ObjCMessageExpr *ME);
   void VisitOMPExecutableDirective(OMPExecutableDirective *ED);
 
   bool isTrackedVar(const VarDecl *vd) {
     return ::isTrackedVar(vd, cast<DeclContext>(ac.getDecl()));
   }
 
if (VD && isTrackedVar(VD)) {
         // left, since its scope could be re-entered by a jump over the
         // declaration.
         vals[VD] = Uninitialized;
       }
     }
   }
 }
 
+void TransferFunctions::VisitGCCAsmStmt(GCCAsmStmt *as) {
+  // An "asm goto" statement is a terminator that may initialize some variables.
+  if (!as->isAsmGoto())
+    return;
+
+  for (const auto &o : as->outputs())
+    if (const VarDecl *VD = findVar(o).getDecl())
+      vals[VD] = Initialized;
+}
+
 void TransferFunctions::VisitObjCMessageExpr(ObjCMessageExpr *ME) {
   // If the Objective-C message expression is an implicit no-return that
   // is not modeled in the CFG, set the tracked dataflow values to Unknown.
   if (objCNoRet.isImplicitNoReturn(ME)) {
     vals.setAllScratchValues(Unknown);
   }
 }
 
for (CFGBlock::const_pred_iterator I = block->pred_begin(),
     }
   }
   // Apply the transfer function.
   TransferFunctions tf(vals, cfg, block, ac, classification, handler);
   for (const auto &I : *block) {
     if (Optional<CFGStmt> cs = I.getAs<CFGStmt>())
       tf.Visit(const_cast<Stmt *>(cs->getStmt()));
   }
+  CFGTerminator terminator = block->getTerminator();
+  if (GCCAsmStmt *as = dyn_cast_or_null<GCCAsmStmt>(terminator.getStmt()))
+    if (as->isAsmGoto())
+      tf.Visit(as);
   return vals.updateValueVectorWithScratch(block);
 }
 
 namespace {
 
 /// PruneBlocksHandler is a special UninitVariablesHandler that is used
 /// to detect when a CFGBlock has any *potential* use of an uninitialized
 /// variable.  It is mainly used to prune out work during the final

clang/lib/CodeGen/CGStmt.cpp

if (IsGCCAsmGoto) {
         llvm::BlockAddress *BA =
             llvm::BlockAddress::get(CurFn, Dest.getBlock());
         Args.push_back(BA);
         ArgTypes.push_back(BA->getType());
         if (!Constraints.empty())
           Constraints += ',';
         Constraints += 'X';
       }
-      StringRef Name = "asm.fallthrough";
-      Fallthrough = createBasicBlock(Name);
+      Fallthrough = createBasicBlock("asm.fallthrough");
     }
   }
 
   // Clobbers
   for (unsigned i = 0, e = S.getNumClobbers(); i != e; i++) {
     StringRef Clobber = S.getClobber(i);
 
     if (Clobber == "memory")
llvm::InlineAsm::AsmDialect AsmDialect = isa<MSAsmStmt>(&S) ?
     llvm::InlineAsm::AD_Intel : llvm::InlineAsm::AD_ATT;
   llvm::InlineAsm *IA =
     llvm::InlineAsm::get(FTy, AsmString, Constraints, HasSideEffect,
                          /* IsAlignStack */ false, AsmDialect);
   std::vector<llvm::Value*> RegResults;
   if (IsGCCAsmGoto) {
     llvm::CallBrInst *Result =
         Builder.CreateCallBr(IA, Fallthrough, Transfer, Args);
+    EmitBlock(Fallthrough);
     UpdateAsmCallInst(cast<llvm::CallBase>(*Result), HasSideEffect, ReadOnly,
                       ReadNone, S, ResultRegTypes, *this, RegResults);
-    EmitBlock(Fallthrough);
   } else {
     llvm::CallInst *Result =
         Builder.CreateCall(IA, Args, getBundlesForFunclet(IA));
     UpdateAsmCallInst(cast<llvm::CallBase>(*Result), HasSideEffect, ReadOnly,
                       ReadNone, S, ResultRegTypes, *this, RegResults);
   }
 
   assert(RegResults.size() == ResultRegTypes.size());

clang/lib/Parse/ParseStmtAsm.cpp

StmtResult Parser::ParseAsmStatement(bool &msAsm) {
 
   // Parse Outputs, if present.
   bool AteExtraColon = false;
   if (Tok.is(tok::colon) || Tok.is(tok::coloncolon)) {
     // In C++ mode, parse "::" like ": :".
     AteExtraColon = Tok.is(tok::coloncolon);
     ConsumeToken();
 
-    if (!AteExtraColon && isGotoAsm && Tok.isNot(tok::colon)) {
-      Diag(Tok, diag::err_asm_goto_cannot_have_output);
-      SkipUntil(tok::r_paren, StopAtSemi);
-      return StmtError();
-    }
-
     if (!AteExtraColon && ParseAsmOperandsOpt(Names, Constraints, Exprs))
       return StmtError();
   }
 
   unsigned NumOutputs = Names.size();
 
   // Parse Inputs, if present.
   if (AteExtraColon || Tok.is(tok::colon) || Tok.is(tok::coloncolon)) {

clang/lib/Sema/SemaStmtAsm.cpp

StmtResult Sema::ActOnGCCAsmStmt(SourceLocation AsmLoc, bool IsSimple,
 
   // Validate constraints and modifiers.
   for (unsigned i = 0, e = Pieces.size(); i != e; ++i) {
     GCCAsmStmt::AsmStringPiece &Piece = Pieces[i];
     if (!Piece.isOperand()) continue;
 
     // Look for the correct constraint index.
     unsigned ConstraintIdx = Piece.getOperandNo();
+    unsigned NumOperands = NS->getNumOutputs() + NS->getNumInputs();
     // Labels are the last in the Exprs list.
-    if (NS->isAsmGoto() && ConstraintIdx >= NS->getNumInputs())
+    if (NS->isAsmGoto() && ConstraintIdx >= NumOperands)
       continue;
-    unsigned NumOperands = NS->getNumOutputs() + NS->getNumInputs();
     // Look for the (ConstraintIdx - NumOperands + 1)th constraint with
     // modifier '+'.
     if (ConstraintIdx >= NumOperands) {
       unsigned I = 0, E = NS->getNumOutputs();
 
       for (unsigned Cnt = ConstraintIdx - NumOperands; I != E; ++I)
         if (OutputConstraintInfos[I].isReadWrite() && Cnt-- == 0) {
           ConstraintIdx = I;

clang/test/Analysis/uninit-asm-goto.cpp

+// RUN: %clang_cc1 -std=c++11 -Wuninitialized -verify %s
+// expected-no-diagnostics
+
+int test1(int x) {
+    int y;
+    asm goto("# %0 %1 %2" : "=r"(y) : "r"(x) : : err);
+    return y;
+  err:
+    return -1;
+}

clang/test/CodeGen/asm-goto.c

 // REQUIRES: x86-registered-target
 // RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -O0 -emit-llvm %s -o - | FileCheck %s
 // RUN: %clang_cc1 -triple i386-pc-linux-gnu -O0 -emit-llvm %s -o - | FileCheck %s
 
-int foo(int cond)
-{
+int test1(int cond) {
+  // CHECK-LABEL: define i32 @test1(
   // CHECK: callbr void asm sideeffect
   // CHECK: to label %asm.fallthrough [label %label_true, label %loop]
   // CHECK: asm.fallthrough:
   asm volatile goto("testl %0, %0; jne %l1;" :: "r"(cond)::label_true, loop);
-  asm volatile goto("testl %0, %0; jne %l1;" :: "r"(cond)::label_true, loop);
+  asm volatile goto("testl %0, %0; jne %l2;" :: "r"(cond)::label_true, loop);
   // CHECK: callbr void asm sideeffect
   // CHECK: to label %asm.fallthrough1 [label %label_true, label %loop]
   // CHECK: asm.fallthrough1:
   return 0;
 loop:
   return 0;
 label_true:
   return 1;
 }
+
+int test2(int cond) {
+  // CHECK-LABEL: define i32 @test2(
+  // CHECK: callbr i32 asm sideeffect
+  // CHECK: to label %asm.fallthrough [label %label_true, label %loop]
+  // CHECK: asm.fallthrough:
+  asm volatile goto("testl %0, %0; jne %l2;" : "=r"(cond) : "r"(cond) :: label_true, loop);
+  asm volatile goto("testl %0, %0; jne %l3;" : "=r"(cond) : "r"(cond) :: label_true, loop);
+  // CHECK: callbr i32 asm sideeffect
+  // CHECK: to label %asm.fallthrough1 [label %label_true, label %loop]
+  // CHECK: asm.fallthrough1:
+  return 0;
+loop:
+  return 0;
+label_true:
+  return 1;
+}
+
+int test3(int out1, int out2) {
+  // CHECK-LABEL: define i32 @test3(
+  // CHECK: callbr { i32, i32 } asm sideeffect
+  // CHECK: to label %asm.fallthrough [label %label_true, label %loop]
+  // CHECK: asm.fallthrough:
+  asm volatile goto("testl %0, %0; jne %l3;" : "=r"(out1), "=r"(out2) : "r"(out1) :: label_true, loop);
+  asm volatile goto("testl %0, %0; jne %l4;" : "=r"(out1), "=r"(out2) : "r"(out1) :: label_true, loop);
+  // CHECK: callbr { i32, i32 } asm sideeffect
+  // CHECK: to label %asm.fallthrough2 [label %label_true, label %loop]
+  // CHECK: asm.fallthrough2:
+  return 0;
+loop:
+  return 0;
+label_true:
+  return 1;
+}
+
+int test4(int out1, int out2) {
+  // CHECK-LABEL: define i32 @test4(
+  // CHECK: callbr { i32, i32 } asm sideeffect "jne ${5:l}", "={si},={di},r,0,1,X,X
+  // CHECK: to label %asm.fallthrough [label %label_true, label %loop]
+  // CHECK: asm.fallthrough:
+  if (out1 < out2)
+    asm volatile goto("jne %l3" : "+S"(out1), "+D"(out2) : "r"(out1) :: label_true, loop);
+  else
+    asm volatile goto("jne %l5" : "+S"(out1), "+D"(out2) : "r"(out1), "r"(out2) :: label_true, loop);
+  // CHECK: callbr { i32, i32 } asm sideeffect "jne ${7:l}", "={si},={di},r,r,0,1,X,X
+  // CHECK: to label %asm.fallthrough2 [label %label_true, label %loop]
+  // CHECK: asm.fallthrough2:
+  return out1 + out2;
+loop:
+  return -1;
+label_true:
+  return -2;
+}
+
+int test5(int addr, int size, int limit) {
+  // CHECK-LABEL: define i32 @test5(
+  // CHECK: callbr i32 asm "add $1,$0 ; jc ${3:l} ; cmp $2,$0 ; ja ${3:l} ; ", "=r,imr,imr,0,X
+  // CHECK: to label %asm.fallthrough [label %t_err]
+  // CHECK: asm.fallthrough:
+  asm goto(
+      "add %1,%0 ; "
+      "jc %l[t_err] ; "
+      "cmp %2,%0 ; "
+      "ja %l[t_err] ; "
+      : "+r" (addr)
+      : "g" (size), "g" (limit)
+      : : t_err);
+  return 0;
+t_err:
+  return 1;
+}

clang/test/Parser/asm-goto.c

 // RUN: %clang_cc1 -triple i386-pc-linux-gnu -fsyntax-only -verify %s
 // RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -fsyntax-only -verify %s
 
 #if !__has_extension(gnu_asm)
 #error Extension 'gnu_asm' should be available by default
 #endif
 
-
 int a, b, c, d, e, f, g, h, i, j, k, l;
 
-void
-fgoto1 (void)
-{
+void test(void) {
   __asm__ volatile goto (""
             :: [a] "r" (a), [b] "r" (b), [c] "r" (c), [d] "r" (d),
                [e] "r" (e), [f] "r" (f), [g] "r" (g), [h] "r" (h),
                [i] "r" (i), [j] "r" (j), [k] "r" (k), [l] "r" (l)
             ::lab1,lab2);
 lab1: return;
 lab2: return;
 }
 
-void
-fgoto2 (void)
-{
+void test2(void) {
   __asm__ volatile goto (""
             :: [a] "r,m" (a), [b] "r,m" (b), [c] "r,m" (c), [d] "r,m" (d),
                [e] "r,m" (e), [f] "r,m" (f), [g] "r,m" (g), [h] "r,m" (h),
                [i] "r,m" (i), [j] "r,m" (j), [k] "r,m" (k), [l] "r,m" (l)
             :: lab);
   lab: return;
 }
 
-int zoo ()
-{
+int test3(int x) {
+  __asm__ volatile goto ("decl %0; jnz %l[a]"
+                         : "=r" (x) : "m" (x) : "memory" : a);
+a:
+  return -x;
+}
+
+int test4(int x) {
+  int y;
+  if (x > 42)
+    __asm__ volatile goto ("decl %0; jnz %l[a]"
+                           : "=r" (x), "=r" (y) : "m" (x) : "memory" : a);
+  else
+    __asm__ volatile goto ("decl %0; jnz %l[b]"
+                           : "=r" (x), "=r" (y) : "m" (x) : "memory" : b);
+  x = y + 42;
+a:
+  return -x;
+b:
+  return +x;
+}
+
+int test5(void) {
   int x,cond,*e;
   // expected-error@+1 {{expected ')'}}
   asm ("mov %[e], %[e]" : : [e] "rm" (*e)::a)
-  // expected-error@+1 {{'asm goto' cannot have output constraints}}
-  asm goto ("decl %0; jnz %l[a]" :"=r"(x): "m"(x) : "memory" : a);
-  // expected-error@+1 {{expected identifie}}
+  // expected-error@+1 {{expected identifier}}
   asm goto ("decl %0;" :: "m"(x) : "memory" : );
   // expected-error@+1 {{expected ':'}}
   asm goto ("decl %0;" :: "m"(x) : "memory" );
   // expected-error@+1 {{use of undeclared label 'x'}}
   asm goto ("decl %0;" :: "m"(x) : "memory" :x);
   // expected-error@+1 {{use of undeclared label 'b'}}
   asm goto ("decl %0;" :: "m"(x) : "memory" :b);
   // expected-error@+1 {{invalid operand number in inline asm string}}
   asm goto ("testl %0, %0; jne %l3;" :: "r"(cond)::label_true, loop);
   // expected-error@+1 {{unknown symbolic operand name in inline assembly string}}
   asm goto ("decl %0; jnz %l[b]" :: "m"(x) : "memory" : a);
 a:
 label_true:
 loop:
   return 0;
 }
+
+int test6(int y) {
+  int x,cond,*e;
+  // expected-error@+1 {{expected ')'}}
+  asm ("mov %[e], %[e]" : "=r" (y) : [e] "rm" (*e), "r" (y) :: a)
+  // expected-error@+1 {{expected identifier}}
+  asm goto ("decl %0;" : "=r" (y) : "m" (x), "r" (y) : "memory" :);
+  // expected-error@+1  {{expected ':'}}
+  asm goto ("decl %0;" : "=r" (y) : "m" (x), "r" (y) : "memory");
+  // expected-error@+1 {{use of undeclared label 'x'}}
+  asm goto ("decl %0;" : "=r" (y) : "m" (x), "r" (y) : "memory" : x);
+  // expected-error@+1 {{use of undeclared label 'b'}}
+  asm goto ("decl %0;" : "=r" (y) : "m" (x), "r" (y) : "memory" : b);
+  // expected-error@+1 {{invalid operand number in inline asm string}}
+  asm goto ("testl %0, %0; jne %l5;" : "=r" (y) : "r" (cond), "r" (y) :: label_true, loop);
+  // expected-error@+1 {{unknown symbolic operand name in inline assembly string}}
+  asm goto ("decl %0; jnz %l[b]" : "=r" (y) : "m" (x), "r" (y) : "memory" : a);
+label_true:
+loop:
+a:
+  return 0;
+}

clang/test/Parser/asm-goto.cpp

 // RUN: %clang_cc1 -triple i386-pc-linux-gnu -fsyntax-only -verify -std=c++11 %s
 // RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -fsyntax-only -verify -std=c++11 %s
 
-int zoo ()
-{
+int a, b, c, d, e, f, g, h, i, j, k, l;
+
+void test1(void) {
+  __asm__ volatile goto (""
+            :: [a] "r" (a), [b] "r" (b), [c] "r" (c), [d] "r" (d),
+               [e] "r" (e), [f] "r" (f), [g] "r" (g), [h] "r" (h),
+               [i] "r" (i), [j] "r" (j), [k] "r" (k), [l] "r" (l)
+            ::lab1,lab2);
+lab1: return;
+lab2: return;
+}
+
+void test2(void) {
+  __asm__ volatile goto (""
+            :: [a] "r,m" (a), [b] "r,m" (b), [c] "r,m" (c), [d] "r,m" (d),
+               [e] "r,m" (e), [f] "r,m" (f), [g] "r,m" (g), [h] "r,m" (h),
+               [i] "r,m" (i), [j] "r,m" (j), [k] "r,m" (k), [l] "r,m" (l)
+            :: lab);
+  lab: return;
+}
+
+int test3(int x) {
+  __asm__ volatile goto ("decl %0; jnz %l[a]"
+                         : "=r" (x) : "m" (x) : "memory" : a);
+a:
+  return -x;
+}
+
+int test4(int x) {
+  int y;
+  if (x > 42)
+    __asm__ volatile goto ("decl %0; jnz %l[a]"
+                           : "=r" (x), "=r" (y) : "m" (x) : "memory" : a);
+  else
+    __asm__ volatile goto ("decl %0; jnz %l[b]"
+                           : "=r" (x), "=r" (y) : "m" (x) : "memory" : b);
+  x = y + 42;
+a:
+  return -x;
+b:
+  return +x;
+}
+
+int test5(void) {
   int x,cond,*e;
   // expected-error@+1 {{expected ')'}}
   asm ("mov %[e], %[e]" : : [e] "rm" (*e)::a)
-  // expected-error@+1  {{'asm goto' cannot have output constraints}}
-  asm goto ("decl %0; jnz %l[a]" :"=r"(x): "m"(x) : "memory" : a);
-  // expected-error@+1 {{expected identifie}}
+  // expected-error@+1 {{expected identifier}}
   asm goto ("decl %0;" :: "m"(x) : "memory" : );
   // expected-error@+1  {{expected ':'}}
   asm goto ("decl %0;" :: "m"(x) : "memory" );
   // expected-error@+1 {{use of undeclared label 'x'}}
   asm goto ("decl %0;" :: "m"(x) : "memory" :x);
   // expected-error@+1 {{use of undeclared label 'b'}}
   asm goto ("decl %0;" :: "m"(x) : "memory" :b);
   // expected-error@+1 {{invalid operand number in inline asm string}}
   asm goto ("testl %0, %0; jne %l3;" :: "r"(cond)::label_true, loop);
   // expected-error@+1 {{unknown symbolic operand name in inline assembly string}}
   asm goto ("decl %0; jnz %l[b]" :: "m"(x) : "memory" : a);
 label_true:
 loop:
 a:
   return 0;
 }
 
-
-int a, b, c, d, e, f, g, h, i, j, k, l;
-
-void
-fgoto1 (void)
-{
-  __asm__ volatile goto (""
-            :: [a] "r" (a), [b] "r" (b), [c] "r" (c), [d] "r" (d),
-               [e] "r" (e), [f] "r" (f), [g] "r" (g), [h] "r" (h),
-               [i] "r" (i), [j] "r" (j), [k] "r" (k), [l] "r" (l)
-            ::lab1,lab2);
-lab1: return;
-lab2: return;
-}
-
-void
-fgoto2 (void)
-{
-  __asm__ volatile goto (""
-            :: [a] "r,m" (a), [b] "r,m" (b), [c] "r,m" (c), [d] "r,m" (d),
-               [e] "r,m" (e), [f] "r,m" (f), [g] "r,m" (g), [h] "r,m" (h),
-               [i] "r,m" (i), [j] "r,m" (j), [k] "r,m" (k), [l] "r,m" (l)
-            :: lab);
-  lab: return;
+int test6(int y) {
+  int x,cond,*e;
+  // expected-error@+1 {{expected ')'}}
+  asm ("mov %[e], %[e]" : "=r" (y) : [e] "rm" (*e), "r" (y) :: a)
+  // expected-error@+1 {{expected identifier}}
+  asm goto ("decl %0;" : "=r" (y) : "m" (x), "r" (y) : "memory" :);
+  // expected-error@+1  {{expected ':'}}
+  asm goto ("decl %0;" : "=r" (y) : "m" (x), "r" (y) : "memory");
+  // expected-error@+1 {{use of undeclared label 'x'}}
+  asm goto ("decl %0;" : "=r" (y) : "m" (x), "r" (y) : "memory" : x);
+  // expected-error@+1 {{use of undeclared label 'b'}}
+  asm goto ("decl %0;" : "=r" (y) : "m" (x), "r" (y) : "memory" : b);
+  // expected-error@+1 {{invalid operand number in inline asm string}}
+  asm goto ("testl %0, %0; jne %l5;" : "=r" (y) : "r" (cond), "r" (y) :: label_true, loop);
+  // expected-error@+1 {{unknown symbolic operand name in inline assembly string}}
+  asm goto ("decl %0; jnz %l[b]" : "=r" (y) : "m" (x), "r" (y) : "memory" : a);
+label_true:
+loop:
+a:
+  return 0;
 }

clang/test/Sema/asm-goto.cpp

 // RUN: %clang_cc1 %s -triple i386-pc-linux-gnu -verify -fsyntax-only
 // RUN: %clang_cc1 %s -triple x86_64-pc-linux-gnu -verify -fsyntax-only
 
-struct NonTrivial {
-  ~NonTrivial();
+struct S {
+  ~S();
   int f(int);
 private:
   int k;
 };
-void JumpDiagnostics(int n) {
+void test1(int n) {
 // expected-error@+1 {{cannot jump from this goto statement to its label}}
   goto DirectJump;
 // expected-note@+1 {{jump bypasses variable with a non-trivial destructor}}
-  NonTrivial tnp1;
+  S s1;
 
 DirectJump:
 // expected-error@+1 {{cannot jump from this asm goto statement to one of its possible targets}}
   asm goto("jmp %l0;" ::::Later);
 // expected-note@+1 {{jump bypasses variable with a non-trivial destructor}}
-  NonTrivial tnp2;
+  S s2;
 // expected-note@+1 {{possible target of asm goto statement}}
 Later:
   return;
 }
 
-struct S { ~S(); };
-void foo(int a) {
+struct T { ~T(); };
+void test2(int a) {
   if (a) {
 FOO:
 // expected-note@+2 {{jump exits scope of variable with non-trivial destructor}}
 // expected-note@+1 {{jump exits scope of variable with non-trivial destructor}}
-    S s;
+    T t;
     void *p = &&BAR;
 // expected-error@+1 {{cannot jump from this asm goto statement to one of its possible targets}}
     asm goto("jmp %l0;" ::::BAR);
 // expected-error@+1 {{cannot jump from this indirect goto statement to one of its possible targets}}
     goto *p;
     p = &&FOO;
     goto *p;
     return;
   }
 // expected-note@+2 {{possible target of asm goto statement}}
 // expected-note@+1 {{possible target of indirect goto statement}}
 BAR:
   return;
 }
 
-
-//Asm goto:
-int test16(int n)
+int test3(int n)
 {
   // expected-error@+2 {{cannot jump from this asm goto statement to one of its possible targets}}
   // expected-error@+1 {{cannot jump from this asm goto statement to one of its possible targets}}
   asm volatile goto("testl %0, %0; jne %l1;" :: "r"(n)::label_true, loop);
   // expected-note@+2 {{jump bypasses initialization of variable length array}}
   // expected-note@+1 {{possible target of asm goto statement}}
   return ({int a[n];label_true: 2;});
   // expected-note@+1 {{jump bypasses initialization of variable length array}}
   int b[n];
 // expected-note@+1 {{possible target of asm goto statement}}
 loop:
   return 0;
 }