这个问题我之前也碰到过，本质是X86-64指令集对立即数的编码限制，加上clang对Intel语法的解析细节导致的，咱们一步步来解决：

问题根源拆解 #

你写的movq rax, 0xFFFFFFFFFFFFFFFF报错，核心原因有两点：

• X86_64架构中，普通mov/movq指令加载立即数到64位通用寄存器时，要求立即数必须是32位有符号数符号扩展到64位的结果。虽然0xFFFFFFFFFFFFFFFF确实是32位0xFFFFFFFF（即-1）的符号扩展，但clang的Intel语法汇编器对movq的默认处理逻辑是关联MMX/XMM寄存器操作，而非通用寄存器的64位移动。
• 宏展开后的0xFFFFFFFFFFFFFFFF作为无符号数呈现时，汇编器可能误判它不符合符号扩展的编码规则。

具体解决方法 #

方法一：改用mov指令替代movq #

在Intel语法下，针对通用寄存器的64位直接赋值，用mov就足够，汇编器会自动处理正确的指令编码：

.intel_syntax noprefix
#define a_const 0xFFFFFFFFFFFFFFFF
mov rax, a_const

或者更简洁地用有符号数直接表示（因为0xFFFFFFFFFFFFFFFF等价于-1）：

.intel_syntax noprefix
mov rax, -1

方法二：切换到AT&T语法的正确写法 #

你提到尝试过AT&T语法，这里给出两种场景的正确写法：

• 对于0xFFFFFFFFFFFFFFFF这种可通过32位符号扩展得到的64位立即数，直接用movq即可：

#define a_const 0xFFFFFFFFFFFFFFFF
movq $-1, %rax  # 等价于movq $a_const, %rax

• 如果是无法通过32位符号扩展得到的64位立即数，则需要用movabsq：

#define a_const 0x123456789ABCDEF0
movabsq $a_const, %rax

验证编译 #

用你原来的编译命令测试修改后的代码：

clang -c -g -O3 -fwrapv -fomit-frame-pointer -march=native my_asm.S

应该就能顺利通过编译了。

内容的提问来源于stack exchange，提问作者Geovandro Pereira