[Bug target/53929] [meta-bug] -masm=intel with global symbol
lh_mouse at 126 dot com
gcc-bugzilla@gcc.gnu.org
Thu May 4 04:37:18 GMT 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #13 from LIU Hao <lh_mouse at 126 dot com> ---
dup notwithstanding, I think I had better copy my recommendation here for
reference:
This is how MSVC handles such names:
(https://gcc.godbolt.org/z/TonjYaxqj)
```
static int* volatile rip;
static unsigned int volatile eax;
int
get_value(void)
{
return rip[eax];
}
```
MSVC outputs:
```
get_value PROC ; COMDAT
mov ecx, DWORD PTR eax
mov rax, QWORD PTR rip
mov eax, DWORD PTR [rax+rcx*4]
ret 0
get_value ENDP
```
GCC outputs:
```
get_value:
mov rdx, QWORD PTR rip[rip]
mov eax, DWORD PTR eax[rip]
mov eax, DWORD PTR [rdx+rax*4]
ret
```
In the case of MSVC, `DWORD PTR eax` is unambiguously parsed as the label `eax`
and `DWORD PTR [eax]` is unambiguously parsed as the register `eax`. The
address of all labels are always relative to RIP, but it is implied, and
brackets are not written explicitly.
Maybe GCC can follow MSVC to omit the RIP register and brackets. The x86_64
memory reference syntax matches x86 with the only change in semantics of the
immediate offset (for x86_64 it is relative to the next instruction, while for
i686 it is absolute), but the opcode is the same.
More information about the Gcc-bugs
mailing list