<div dir="ltr">The attached patch fixes a bug in Sema::ActOnGCCAsmStmt where it wasn't computing the corresponding ConstraintIdx from an operand number correctly when there were constraints with the '+' modifier.<div><br></div><div>For example, when the following inline-asm statement is compiled,</div><div><br></div><div><div>void g2(int one, int two, int three) {</div><div>  asm volatile ("%0 %1 %2 %3 %4" : "+r" (one), "+r"(two) : "r"(three));<br></div><div>}</div></div><div><br></div><div>the existing code maps the operand number in the assembly template to ConstraintIdx in the following way:</div><div><br></div><div>%0 => "+r" (one) => ConstraintIdx = 0</div><div><div>%1 => "+r" (one) => ConstraintIdx = 0</div></div><div><div>%2 => "+r" (two) => ConstraintIdx = 1</div></div><div><div>%3 => "+r" (two) => ConstraintIdx = 1</div></div><div><div>%4 => "+r" (three) => ConstraintIdx = 2</div></div><div><br></div><div><div>The correct mapping should be like this:</div><div><br></div></div><div><div>%0 => "+r" (one) => ConstraintIdx = 0</div><div>%1 => "+r" (two) => ConstraintIdx = 1</div><div>%3 => "+r" (three) => ConstraintIdx = 2</div><div>%4 => "+r" (one) => ConstraintIdx = 0</div><div>%5 => "+r" (two) => ConstraintIdx = 1<br></div></div><div><br></div><div>I couldn't find the rule documented anywhere in the link below, but judging from the code I see in CodeGenFunction::EmitAsmStmt and the IR clang generates, I believe this is the correct way to find the corresponding constraint.</div><div><br></div><div><a href="https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html">https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html</a></div><div> </div><div>This is the IR generated:</div><div><br></div><div>%1 = tail call { i32, i32 } asm sideeffect "$0 $1 $2 $3 $4", "=r,=r,r,0,1"(i32 %three, i32 %one, i32 %two)</div></div>