[LLVMbugs] [Bug 14056] New: Incorrect assembly of MOV/MOVABS instructions with 64-bit displacements

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=14056

             Bug #: 14056
           Summary: Incorrect assembly of MOV/MOVABS instructions with
                    64-bit displacements
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: arthur.j.odwyer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I'm not sure if this should be filed on this Bugzilla or not, but it seems to
be related to Clang's internal x86 assembler — at least I don't see Clang
calling out to any external assembler in the -v output.

    .code64
    movabsq 0x123456789abcdef, %rax
    movq 0x123456789abcdef, %rax

GCC's assembler produces the expected output:
    48 a1 ef cd ab 89 67 45 23 01   // movabsq 0x123456789abcdef, %rax
    48 8b 04 25 ef cd ab 89         // movq 0x89abcdef, %rax
with a compile-time warning about the truncated displacement in "movq".

Clang rejects the movabsq instruction with an error...
    test.s:4:10: error: invalid operand for instruction
     movabsq 0x123456789abcdef, %rax
             ^
...and *silently* miscompiles the "movq".
    48 8b 04 25 ef cd ab 89         // movq 0x89abcdef, %rax

I'd like to see both issues addressed, but particularly the lack of MOVABS,
because it's very inconvenient to have to resort to ".byte" directives in the
case of an instruction that's been around for ages.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.