[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