[Bug target/109257] New: `-masm=intel` generates weird syntax for indirect jumps

[Bug target/109257] New: `-masm=intel` generates weird syntax for indirect jumps

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257

            Bug ID: 109257
           Summary: `-masm=intel` generates weird syntax for indirect
                    jumps
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

https://gcc.godbolt.org/z/Tc8v5qfv1

a proper tail call:

```
extern int (*foo)(int, int);
int ptc_to_foo(int a, int b) { return foo(a, b);  }
```

GCC compiles it to this:

```
ptc_to_foo:
        jmp     [QWORD PTR foo[rip]]
```

The outer pair of brackets are superfluous.


The `foo[rip]` part is also invalid but it's a common issue for all addressing
operands for x86_64, not specifically about jmp.

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |jbeulich at suse dot com

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It isn't just for sibcalls, but also for calls:
extern int (*foo) (int, int);
int bar (int a, int b) { return foo (a, b);  }
int baz (int a, int b) { foo (a, b); return 0; }
gcc emits
        jmp     [QWORD PTR foo[rip]]
and
        call    [QWORD PTR foo[rip]]
icc emits
        mov       rax, QWORD PTR foo[rip]                       #2.33
        jmp       rax                                           #2.33
and
        call      QWORD PTR foo[rip]                            #3.26
clang emits
        mov     rax, qword ptr [rip + foo]
        jmp     rax                             # TAILCALL
and
        call    qword ptr [rip + foo]
gas testsuite doesn't have any tests with the []s around the whole thing, but
accepts it the same as without those.
And on the gcc side it is hardcoded that way in lots of spots:
grep '\[[QD]\?WORD' i386.cc i386.md 
i386.cc:                    xasm = "{%p0@GOTPCREL(%%rip)|[QWORD PTR
%p0@GOTPCREL[rip]]}";
i386.cc:                    xasm = "%!jmp\t{*%p0@GOTPCREL(%%rip)|[QWORD PTR
%p0@GOTPCREL[rip]]}";
i386.cc:                    xasm = "{%p0@GOT|[DWORD PTR %p0@GOT]}";
i386.cc:                    xasm = "%!jmp\t{*%p0@GOT|[DWORD PTR %p0@GOT]}";
i386.cc:                xasm = "{%p0@GOTPCREL(%%rip)|[QWORD PTR
%p0@GOTPCREL[rip]]}";
i386.cc:                xasm = "%!call\t{*%p0@GOTPCREL(%%rip)|[QWORD PTR
%p0@GOTPCREL[rip]]}";
i386.cc:                xasm = "{%p0@GOT|[DWORD PTR %p0@GOT]}";
i386.cc:                xasm = "%!call\t{*%p0@GOT|[DWORD PTR %p0@GOT]}";
i386.md:  return "call\t{*%p3@GOT(%1)|[DWORD PTR %p3@GOT[%1]]}";
i386.md:  return "call\t{*%p2@GOTPCREL(%%rip)|[QWORD PTR %p2@GOTPCREL[rip]]}";
i386.md:  return "call\t{*%p2@GOT(%1)|[DWORD PTR %p2@GOT[%1]]}";
i386.md:  return "call\t{*%p1@GOTPCREL(%%rip)|[QWORD PTR %p1@GOTPCREL[rip]]}";
i386.md:  "call\t{*%a1@TLSCALL(%2)|[DWORD PTR [%2+%a1@TLSCALL]]}"
i386.md:  "call\t{*%a1@TLSCALL(%2)|[QWORD PTR [%2+%a1@TLSCALL]]}"
and I'm sure I'm missing some.

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[jbeulich at suse dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257

--- Comment #2 from jbeulich at suse dot com ---
(In reply to LIU Hao from comment #0)
> ptc_to_foo:
>         jmp     [QWORD PTR foo[rip]]
> ```
> 
> The outer pair of brackets are superfluous.

Sure, but there's no reason for gas to not accept what MASM would. You also
don't really make clear why you think this is an issue, and hence why it should
be changed in gcc.

> The `foo[rip]` part is also invalid but it's a common issue for all
> addressing operands for x86_64, not specifically about jmp.

Why's that invalid? foo[eax] and [foo+eax] have always been equivalent in MASM,
and I see no reason why this shouldn't hold for rip-relative addressing as
well.

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257

--- Comment #3 from LIU Hao <lh_mouse at 126 dot com> ---
(In reply to jbeulich from comment #2)
> Sure, but there's no reason for gas to not accept what MASM would. You also
> don't really make clear why you think this is an issue, and hence why it
> should be changed in gcc.

Why not? The syntax is invalid because Intel software developer manual has no
reference to such construction. The fact that MASM would accept it doesn't
render it valid.


> > The `foo[rip]` part is also invalid but it's a common issue for all
> > addressing operands for x86_64, not specifically about jmp.
> 
> Why's that invalid? foo[eax] and [foo+eax] have always been equivalent in
> MASM, and I see no reason why this shouldn't hold for rip-relative
> addressing as well.

Ok that's fine, just not intuitive. I wouldn't argue on this.

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[jbeulich at suse dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257

--- Comment #4 from jbeulich at suse dot com ---
(In reply to LIU Hao from comment #3)
> (In reply to jbeulich from comment #2)
> > Sure, but there's no reason for gas to not accept what MASM would. You also
> > don't really make clear why you think this is an issue, and hence why it
> > should be changed in gcc.
> 
> Why not? The syntax is invalid because Intel software developer manual has
> no reference to such construction. The fact that MASM would accept it
> doesn't render it valid.

Being as compatible as possible with MASM has been the primary goal of
supporting Intel syntax. Intel's SDM doesn't specify complete assembly
language; it serves as a reference where possible/sensible.

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257

--- Comment #5 from LIU Hao <lh_mouse at 126 dot com> ---
(In reply to jbeulich from comment #4)
> Being as compatible as possible with MASM has been the primary goal of
> supporting Intel syntax. Intel's SDM doesn't specify complete assembly
> language; it serves as a reference where possible/sensible.

GAS may accept it at any cost but GCC should not generate it. This is an issue
about GCC, not GAS.

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257

--- Comment #6 from LIU Hao <lh_mouse at 126 dot com> ---
gcc/config/i386/i386.cc:
```
void
ix86_print_operand (FILE *file, rtx x, int code)
{
  if (code)
    {
      switch (code)
        {
        case 'A':
          switch (ASSEMBLER_DIALECT)
            {
            case ASM_ATT:
              putc ('*', file);
              break;

            case ASM_INTEL:
              /* Intel syntax. For absolute addresses, registers should not
                 be surrounded by braces.  */
              if (!REG_P (x))
                {
                  putc ('[', file);
                  ix86_print_operand (file, x, 0);
                  putc (']', file);
                  return;
                }
              break;

            default:
              gcc_unreachable ();
            }

          ix86_print_operand (file, x, 0);
          return;
```

I hope someone can clean this up a bit. The AT&T part is an obvious recursion,
so why should we write something like that? It could be

```
        case 'A':
          if (ASSEMBLER_DIALECT == ASM_ATT)
            {
              putc ('*', file);
              break;
            }

          // intel stuff here.
          return;

```