https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109726
Bug ID: 109726 Summary: use of variables whose name happen to match register names or keywords Product: gcc Version: 14.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: --- GAS PR: https://sourceware.org/bugzilla/show_bug.cgi?id=30418 Filed in both places, as we need changes both. 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.