[llvm-bugs] [Bug 32825] New: arm assembler incorrectly re-uses previously allocated literal pool entries

[via llvm-bugs]

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

            Bug ID: 32825
           Summary: arm assembler incorrectly re-uses previously allocated
                    literal pool entries
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dimitry at andric.com
                CC: llvm-bugs at lists.llvm.org

This is a test case derived from webkit-gtk[23], where it apparently was inline
assembly, but having it as a separate file is easier for reproduction:

======================================================================
$ cat lli1.s
        .text
# Assembler allocates slot in literal pool
# and puts 1234 into it.
        ldr r0, =1234

        # Literal pool is flushed at this place.
        .ltorg
# Actual result:
#      0:       e51f0004        ldr     r0, [pc, #-4]   ; 4 <.text+0x4>
#      4:       000004d2        .word   0x000004d2

# Move PC outside of relative addressing range.
        .=. + 4096

# Assembler incorrectly reuses previously
# allocated slot in literal pool even if its
# outside of of addressable range for
# ldr r0, [pc, #xxx]
        ldr r0, =1234
        .ltorg
# Expected result:
#    1008:       e51f0004        ldr     r0, [pc, #-4]   ; 100c <.text+0x100c>
#    100c:       000004d2        .word   0x000004d2
======================================================================

With GNU as, assembling this example works just fine:

======================================================================
$ arm-gnueabi-freebsd-as -v -o lli1.o lli1.s
GNU assembler version 2.28 (arm-gnueabi-freebsd) using BFD version (GNU
Binutils) 2.28
$ arm-gnueabi-freebsd-objdump -d lli1.o

lli1.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <.text>:
       0:       e51f0004        ldr     r0, [pc, #-4]   ; 4 <.text+0x4>
       4:       000004d2        .word   0x000004d2
        ...
    1008:       e51f0004        ldr     r0, [pc, #-4]   ; 100c <.text+0x100c>
    100c:       000004d2        .word   0x000004d2
======================================================================

E.g. the assembler recognizes the first literal pool is too far away, and puts
the same constant in a new literal pool.

In contrast, clang trunk r300422 cannot assemble this:

======================================================================
$ clang -cc1as -triple arm---eabi -filetype obj -o lli1.o lli1.s
lli1.s:19:2: error: out of range pc-relative fixup value
        ldr r0, =1234
        ^
======================================================================

Obviously the fixup value is not out range, it simply fails to create a new
literal pool.

-- 
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/20170427/6a017997/attachment-0001.html>