[llvm-bugs] [Bug 32973] New: The assembly parser eats trailing 'h' chars from macro arguments that start with a number

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=32973

            Bug ID: 32973
           Summary: The assembly parser eats trailing 'h' chars from macro
                    arguments that start with a number
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: martin at martin.st
                CC: llvm-bugs at lists.llvm.org

When macro arguments start with a number, a 'h' after the number gets eaten
before the macro gets expanded.

E.g. this aarch64 snippet fails to assemble with clang/LLVM while it assembles
fine with gnu binutils:


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

do_add 8h


With clang/llvm, this fails to assemble like this:

$ clang -target aarch64-linux-gnu -c test.s -o test.o
<instantiation>:1:9: error: invalid vector kind qualifier
add     v0.8, v0.8, v0.8
        ^
test.s:5:1: note: while in macro instantiation
do_add 8h
^

If the same snippet is written differently, to include the dot in the macro
argument, it assembles fine:

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

do_add .8h

Likewise, the original do_add macro succeeds with other lane sizes like 4s, 8b,
16b etc.



The same phenomenon can be observed with this rather pathological test case:

.macro def_string param
        .ascii  "\param"
.endm

.data
def_string 1hello

When assembled, objdump shows:

$ aarch64-linux-gnu-objdump -s test.o

test.o:     file format elf64-littleaarch64

Contents of section .data:
 0000 31656c6c 6f                          1ello        


The 'h' trailing the number '1' has been eaten and never made it into the macro
expansion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170509/51b411dc/attachment.html>