From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id B1DBB3857343; Thu,  4 May 2023 04:11:43 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B1DBB3857343
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1683173503;
	bh=kQW7oFCOXBTqkWqVWO5vlhiJ60yUT0SSi/1Mwy+c0AU=;
	h=From:To:Subject:Date:From;
	b=b5kkLi4AKCQTWez8mu3t6AB2nn8M574QXdYLNqlutQHDUF1Joq8XCigQ8GcgCXROd
	 TPwL8cg0wMa4HPP5eAe7v8Z7vXOwiVGq+I9BK5VpQeKXetQyKphCGR1QiqfCYfix0A
	 16rtjks/WaxKrPSClXocaopiyskAr6Tqd/d6EgO4=
From: "lh_mouse at 126 dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/109726] New: use of variables whose name happen to match
 register names or keywords
Date: Thu, 04 May 2023 04:11:43 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: lh_mouse at 126 dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-109726-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

            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=3D30418
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.=