Description
Bugzilla Link | 36144 |
Resolution | FIXED |
Resolved on | Oct 24, 2018 13:35 |
Version | trunk |
OS | MacOS X |
Blocks | #11360 |
Attachments | C++ source file, compilation of which with Clang reproduces the issue |
Reporter | LLVM Bugzilla Contributor |
CC | @topperc,@francisvm,@JDevlieghere,@RKSimon,@noloader,@rnk |
Fixed by commit(s) | r345189 |
Extended Description
Overview:
Using operands of the form '0b' (a numbered label appearing earlier in source relative to current source position) in jump instructions (any jump instruction, jmp, je, jne, jz, jnz etc.) in inline
intel dialect x86 assembly causes an 'Invalid operand for instruction' compilation error. In earlier versions (specific versions listed below) of clang this compiled correctly, producing code with the jmp target replaced with the correct label generated from the numbered label in the inline assembly.
Steps to Reproduce:
- Download the attached source 'x86IntelInlineAsmJmpToLabelRelativeTest.cpp'
- Using a version of clang 5.0 or greater (including trunk), attempt to compile this using: clang x86IntelInlineAsmJmpToLabelRelativeTest.cpp -o x86IntelInlineAsmJmpToLabelRelativeTest
- Observe the compilation error on line 17 of x86IntelInlineAsmJmpToLabelRelativeTest.cpp - "Invalid operand for instruction"
Actual Results:
The program fails to compile.
Expected Results:
The program compiles successfully, with the target of the jump instruction replaced with the correct label generated from the numbered label in the inline assembly.
Build Date & Hardware where bug was first encountered:
26 Jan 2018 - Xcode 9.3 Beta 1 (9Q98q), Apple LLVM version 9.1.0 (clang-902.0.30) - Mac OS 10.13.3 (17D47)
Additional Builds and Platforms:
Clang 5.0.0 (non-Xcode version) release reproduced the issue.
Clang 4.0.0 and 4.0.1 (non-Xcode version) releases did not reproduce the issue.
Locally compiled build of Clang on trunk (@ SVN revision 323529) reproduced the issue.
Additional information:
The attached code performs the same operation twice, first using Intel syntax, then using AT&T syntax to demonstrate the issue exists only in the Intel syntax path.
A brief investigation seems to show this arises from an ambiguity when parsing operands to instructions in Intel syntax after handling of MASM style Intel syntax was added in r280555. Because MASM allows integer literals of the form '011010b', '0b' is a valid integer literal representing value 0. The code in lib/MC/MCParser/AsmLexer.cpp - llvm::AsmLexer::LexDigit() with MASM style Intel assembly handling consumes the 'b' suffix on the literal. This means the special handling of positionally relative jump targets in lib/Target/X86/AsmParser/X86AsmParser.cpp - X86AsmParser::ParseIntelExpression() can no longer correctly detect this form of jump target, and incorrectly identifies the jump instruction's operand as just an integer which causes a compilation error.