llvm-project/llvm/test/MC/AArch64/macro-hex-int.s

// RUN: llvm-mc -triple aarch64-elf -filetype=obj %s -o - | llvm-objdump -d -r - | FileCheck %s

.macro do_add sz
        add     v0.\sz, v0.\sz, v0.\sz
.endm

do_add 8h
// CHECK:  add     v0.8h, v0.8h, v0.8h
[MC] Separate masm integer literal lexer support from inline asm Summary: This renames the IsParsingMSInlineAsm member variable of AsmLexer to LexMasmIntegers and moves it up to MCAsmLexer. This is the only behavior controlled by that variable. I added a public setter, so that it can be set from outside or from the llvm-mc command line. We may need to arrange things so that users can get this behavior from clang, but that's future work. I also put additional hex literal lexing functionality under this flag to fix PR32973. It appears that this hex literal parsing wasn't intended to be enabled in non-masm-style blocks. Now, masm integers (0b1101 and 0ABCh) work in __asm blocks from clang, but 0b label references work when using .intel_syntax in standalone .s files. However, 0b label references will not work from __asm blocks in clang. They will work from GCC inline asm blocks, which it sounds like is important for Crypto++ as mentioned in PR36144. Essentially, we only lex masm literals for inline asm blobs that use intel syntax. If the .intel_syntax directive is used inside a gnu-style inline asm statement, masm literals will not be lexed, which is compatible with gas and llvm-mc standalone .s assembly. This fixes PR36144 and PR32973. Reviewers: Gerolf, avt77 Subscribers: eraman, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D53535 llvm-svn: 345189 2018-10-25 04:23:57 +08:00			`// RUN: llvm-mc -triple aarch64-elf -filetype=obj %s -o - \| llvm-objdump -d -r - \| FileCheck %s`

			`.macro do_add sz`
			`add v0.\sz, v0.\sz, v0.\sz`
			`.endm`

			`do_add 8h`
			`// CHECK: add v0.8h, v0.8h, v0.8h`