From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9B96E388C002; Mon, 26 Oct 2020 10:17:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9B96E388C002 From: "jbeulich at suse dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/53929] Bug in the use of Intel asm syntax when a global is named "and" Date: Mon, 26 Oct 2020 10:17:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.6.3 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: jbeulich at suse 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: Message-ID: In-Reply-To: References: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 10:17:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D53929 --- Comment #6 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #3) > The problem is that the intel asm syntax is just badly defined (broken by > design). I'm not aware of any compiler that would emit for such testcases > something that could be assembled correctly with gas. At the risk of stating the obvious, Intel syntax implies that global symbols would have a prefix character appended, typically an underscore, or that otherwise global symbols avoid the assembler recognized identifiers. This s= adly is a growing set as new register extensions get added. IOW people wanting to avoid having to rename their symbols eventually would need to also restrict= the set of recognized register names via suitable .arch directives.(In reply to Jakub Jelinek from comment #5) > It is far easier to use (the default) assembler syntax that is properly > designed and doesn't have flaws like this. While in the general case I agree, there are downsides when it comes to wan= ting to make use of macros to "stand in" for instructions, and then wanting to e= .g. derive symbols from macro arguments specifying registers. Such macros need = to go to some length to get rid of the % character.=