[PATCH] D149579: [X86][MC] Fix parsing Intel syntax indirect branch with symbol only

Fangrui Song via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri May 5 10:59:13 PDT 2023


MaskRay added inline comments.


================
Comment at: llvm/test/MC/X86/intel-syntax-branch.s:61-67
+  // FIXME: MASM does not accept this syntax and GAS assembles this as a direct
+  //        call/jump instead of indirect. Consider making this syntax an error?
+  call [offset fn_ref]
+  jmp [offset fn_ref]
+  // CHECK-32-LABEL: t7:
+  // CHECK-32: calll *fn_ref
+  // CHECK-32: jmpl *fn_ref
----------------
alvinhochun wrote:
> About the `call [offset fn_ref]` case, do you think we should reject it since MASM does not accept this syntax and GAS appears to behave oddly with it? The `ms-inline-asm-functions.c` test does generate `call [offset _kptr]` so this will also need to be changed.
Yes, I think we should reject `call [offset fn_ref]`. Confirmed with a MinGW dev (lh_mouse) that this is invalid.


================
Comment at: llvm/test/MC/X86/intel-syntax-branch.s:48
+  call dword ptr fn_ref
+  jmp dword ptr fn_ref
+  // CHECK-32-LABEL: t5:
----------------
alvinhochun wrote:
> MaskRay wrote:
> > ICC and MSVC parse this differently.
> > 
> > Is this syntax valid?
> MASM ml.exe assembles this as `jmp dword ptr [fn_ref]` in my test, so does GAS. I don't know how valid this syntax is though.
LG. cl.exe compiles `void (*kptr)(); ... __asm call kptr;` to `call    DWORD PTR _kptr`, so it seems that the bracket can be omitted.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149579/new/

https://reviews.llvm.org/D149579



More information about the cfe-commits mailing list