You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
...
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.
The problem is bigger than just 0b. Crypto++ is experiencing it with 1b, also:
whenever it sees .intel_syntax. From my reading of the previous comments in various reviews / bugs, I understand that we rely on isParsingInlineAsm to actually check if we're parsing MSVC-style Intel syntax asm.
This breaks both things like the example Jeffrey attached:
1:
jnz 1b
and any binary immediate like:
.intel_syntax
and edi, 0b010101
What is the preferred way to fix this? Should we introduce a new flag for clang to set in ParseMicrosoftAsmAsmStatement and provide a hidden flag in LLVM to be able to test it independently?
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:
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.
The text was updated successfully, but these errors were encountered: