[llvm-bugs] [Bug 32035] New: pushf/popf default to wrong operand size in 64-bit with Intel syntax

[via llvm-bugs]

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

            Bug ID: 32035
           Summary: pushf/popf default to wrong operand size in 64-bit
                    with Intel syntax
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: mkuper at google.com
                CC: llvm-bugs at lists.llvm.org

Consider:

.intel_syntax noprefix
foo:
  pushf
  popf
  ret

$ gcc -c -x assembler ./foo.S -o foo.obj && objdump -d foo.obj 

foo.obj:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
   0:   9c                      pushfq 
   1:   9d                      popfq  
   2:   c3                      retq   

$ bin/clang -c -x assembler ./foo.S -o foo.obj && objdump -d foo.obj 

foo.obj:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
   0:   66 9c                   pushfw 
   2:   66 9d                   popfw  
   4:   c3                      retq   

While in 32-bit mode, the manual intentionally leaves the behavior ambiguous
(Some assemblers may force the operand size to 16 when PUSHF is used and to 32
when PUSHFD is used. Others may treat these mnemonics as synonyms
(PUSHF/PUSHFD) and use the current setting of the operand-size attribute to
determine the size of values to be pushed from the stack, regardless of the
mnemonic used), I'm fairly sure the intended reading for 64-bit mode is that an
unqualified pushf is pushfq.

In 32-bit mode, clang also uses the 16-bit version, while gcc uses 32-bit, and
even though this is technically allowed, we may want to fix that as well?

Amusingly, adding .code16 actually makes us do emit 64-bit pushfs:

.intel_syntax noprefix
.code16

foo:
  pushf
  popf
  ret

$ bin/clang -c -x assembler ./foo.S -o foo.obj && objdump -d foo.obj 

foo.obj:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
   0:   9c                      pushfq 
   1:   9d                      popfq  
   2:   66 c3                   retw

-- 
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/20170222/bce29ed6/attachment-0001.html>