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 C649B3858C53; Fri,  2 Jun 2023 08:49:28 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C649B3858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1685695768;
	bh=+1WGBkveKmp0mGx2EiUtWuHcF6+b0dxQtjPseCkVocc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=S7D1ICK6on6ais0OIYwxIMVEi4PdhKKxZhj4WECiXeEUhFUURlVpNlsT54OHo7Pwv
	 mFwdd/ZcEn/N42hvj4ioJYQyCZ+jgFHnIi+IQPwJxVfPj4p4EnNvGpvnURXoi7u5RD
	 jBzOHBAYZLTMGAQEdEl/CcabsV2ylgQZMkle2dgs=
From: "jbeulich at suse dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/109954] x86-64's -m32 does not conform to documentation
Date: Fri, 02 Jun 2023 08:49:28 +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: 13.1.0
X-Bugzilla-Keywords: documentation, patch
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jbeulich at suse dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 10.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109954-4-8G1AGkJ8xn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109954-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109954-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=3D109954

--- Comment #19 from jbeulich at suse dot com ---
(In reply to Thomas Schwinge from comment #17)
> I'm still confused.
>=20
> Conversely this means that the x86_64 'm32' multilib isn't actually "code
> that runs on any i386 system", right?  (Unless configured with suitable
> '--with-arch-32=3D[32-bit x86]'.)
>=20
> However, 'gcc/config/i386/i386.opt':
>=20
>     m32
>     Target RejectNegative Negative(m64) InverseMask(ISA_64BIT)
> Var(ix86_isa_flags) Save
>     Generate 32bit i386 code.
>=20
> Note: "32bit i386 code".

I think this wants correcting. Just "32-bit code" is accurate (with the
intentions explained throughout this bug) and then no longer misleading.

> Per 'info as':
>=20
>     The i386 version of 'as' has a few machine dependent options:
>=20=20=20=20=20
>     '--32 | --x32 | --64'
>          Select the word size, either 32 bits or 64 bits.  '--32' implies
>          Intel i386 architecture, while '--x32' and '--64' imply AMD x86-=
64
>          architecture with 32-bit or 64-bit word-size respectively.
>=20
> Note: "'--32' implies Intel i386 architecture" (thus, 32-bit x86 code?),
> again.

Whereas no, in the x86 assembler it's different: No matter whether i386 or
x86-64, by default all extensions are enabled.=