[Bug target/109954] New: x86-64's -m32 does not conform to documentation

[Bug target/109954] New: x86-64's -m32 does not conform to documentation

[jbeulich at suse dot com]

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

            Bug ID: 109954
           Summary: x86-64's -m32 does not conform to documentation
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jbeulich at suse dot com
  Target Milestone: ---

Quote from doc: "The -m32 option sets int, long, and pointer types to 32 bits,
and generates code that runs on any i386 system." While it may well be that the
documentation is misleading, I also won't exclude that generated code is wrong
instead for a compiler that defaults to generate 64-bit code: cmov<cc> or SSE
insns are happily used by the compiler, for example. Respective pre-processor
symbols are also defined, including __k8__ and __FXSR__.

Just to make it explicit: No -march= or -mtune= options were used, just -m32.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-05-24
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think a compiler built for x86_64-pc-linux-gnu implicitly has
--with-arch=x86-64 and --with-arch_32=x86-64, which means it assumes the 32-bit
code will actually run on an x86_64 CPU. Which definitely doesn't match the
docs.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So s/on any i386 system/in 32-bit mode/ ?

[Bug target/109954] x86-64's -m32 does not conform to documentation

[jbeulich at suse dot com]

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

--- Comment #3 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #2)
> So s/on any i386 system/in 32-bit mode/ ?

Not sure. So far I was under the (possibly wrong) impression that -m32 would
produce objects sufficiently similar to those a 32-bit compiler would produce.
After all environments like the Linux kernel use it with exactly that goal
(aiui), albeit in combination with -march=. So if really it is documentation to
be adjusted, I think this aspect wants emphasizing more.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
If you override the --with-arch_32=x86-64 default then it's fine.

-m32 -march=i386 will indeed produce code that runs on any i386. -m32
-march=i686 won't, nor will -m32 -march=x86-64 (which is the implicit default
for an x86_64-pc-linux-gnu compiler).

[Bug target/109954] x86-64's -m32 does not conform to documentation

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If -march= isn't specified, then the default configured value (explicitly or
implicitly) is used for it.  That is the case on lots of architectures, not
just for -m32.
We say in the documentation:
@item --with-cpu=@var{cpu}
@itemx --with-cpu-32=@var{cpu}
@itemx --with-cpu-64=@var{cpu}
Specify which cpu variant the compiler should generate code for by default.
@var{cpu} will be used as the default value of the @option{-mcpu=} switch.
This option is only supported on some targets, including ARC, ARM, i386, M68k,
PowerPC, and SPARC@.  It is mandatory for ARC@.  The @option{--with-cpu-32} and
@option{--with-cpu-64} options specify separate default CPUs for
32-bit and 64-bit modes; these options are only supported for aarch64, i386,
x86-64, PowerPC, and SPARC@.

@item --with-schedule=@var{cpu}
@itemx --with-arch=@var{cpu}
@itemx --with-arch-32=@var{cpu}
@itemx --with-arch-64=@var{cpu}
@itemx --with-tune=@var{cpu}
@itemx --with-tune-32=@var{cpu}
@itemx --with-tune-64=@var{cpu}
@itemx --with-abi=@var{abi}
@itemx --with-fpu=@var{type}
@itemx --with-float=@var{type}
These configure options provide default values for the @option{-mschedule=},
@option{-march=}, @option{-mtune=}, @option{-mabi=}, and @option{-mfpu=}
options and for @option{-mhard-float} or @option{-msoft-float}.  As with
@option{--with-cpu}, which switches will be accepted and acceptable values
of the arguments depend on the target.

So, if you configure gcc --with-arch-32=i386 vs. --with-arch-32=x86-64, it will
behave differently.
And if you don't use any of those --with-arch*= configure options, a default is
picked.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
How about:

--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -34089,7 +34089,9 @@ on x86-64 processors in 64-bit environments.
 Generate code for a 16-bit, 32-bit or 64-bit environment.
 The @option{-m32} option sets @code{int}, @code{long}, and pointer types
 to 32 bits, and
-generates code that runs on any i386 system.
+generates code that runs in 32-bit mode. N.B., using @option{-march} might
+be required to produce code suitable for a specific CPU family, e.g.,
+@option{-march=i486}.

 The @option{-m64} option sets @code{int} to 32 bits and @code{long} and
pointer
 types to 64 bits, and generates code for the x86-64 architecture.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is the case for -m64, -mx32, -m16 etc. options as well, it would be weird
to mention it just for one.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yeah, my suggestion doesn't try to explain the full details that you pointed
out, just adds a brief note to avoid the pitfall of not overriding the default
arch, for a probably quite common case.

I chose i486 to avoid any confusion that could arise from -march=i386 being
interpreted as "any generic x86" system. IMHO i486 seems more obviously "a
specific CPU family" and not just a generic term for x86, e.g., Debian still
uses "i386" even though their x86 packages are actually built for i686.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Documentation issue.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620336.html

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:eeb92704967875411416b0b9508aa6f49e8192fd

commit r14-1464-geeb92704967875411416b0b9508aa6f49e8192fd
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Jun 1 11:30:10 2023 +0100

    doc: Fix description of x86 -m32 option [PR109954]

    This option does not imply -march=i386 so it's incorrect to say it
    generates code that will run on "any i386 system".

    gcc/ChangeLog:

            PR target/109954
            * doc/invoke.texi (x86 Options): Fix description of -m32 option.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:3b95319b621d95055da182c5fbbccd0d82cb919e

commit r13-7398-g3b95319b621d95055da182c5fbbccd0d82cb919e
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Jun 1 11:30:10 2023 +0100

    doc: Fix description of x86 -m32 option [PR109954]

    This option does not imply -march=i386 so it's incorrect to say it
    generates code that will run on "any i386 system".

    gcc/ChangeLog:

            PR target/109954
            * doc/invoke.texi (x86 Options): Fix description of -m32 option.

    (cherry picked from commit eeb92704967875411416b0b9508aa6f49e8192fd)

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:4466c5ba6e2f1759a2ce461f15fc4e018872a22e

commit r12-9672-g4466c5ba6e2f1759a2ce461f15fc4e018872a22e
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Jun 1 11:30:10 2023 +0100

    doc: Fix description of x86 -m32 option [PR109954]

    This option does not imply -march=i386 so it's incorrect to say it
    generates code that will run on "any i386 system".

    gcc/ChangeLog:

            PR target/109954
            * doc/invoke.texi (x86 Options): Fix description of -m32 option.

    (cherry picked from commit eeb92704967875411416b0b9508aa6f49e8192fd)

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:8538e22f0004565bb95b10741bfd416961030f4c

commit r11-10838-g8538e22f0004565bb95b10741bfd416961030f4c
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Jun 1 11:30:10 2023 +0100

    doc: Fix description of x86 -m32 option [PR109954]

    This option does not imply -march=i386 so it's incorrect to say it
    generates code that will run on "any i386 system".

    gcc/ChangeLog:

            PR target/109954
            * doc/invoke.texi (x86 Options): Fix description of -m32 option.

    (cherry picked from commit eeb92704967875411416b0b9508aa6f49e8192fd)

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:bdd038cc1782b550b434a806ce995fc79f5d1f6b

commit r10-11432-gbdd038cc1782b550b434a806ce995fc79f5d1f6b
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Jun 1 11:30:10 2023 +0100

    doc: Fix description of x86 -m32 option [PR109954]

    This option does not imply -march=i386 so it's incorrect to say it
    generates code that will run on "any i386 system".

    gcc/ChangeLog:

            PR target/109954
            * doc/invoke.texi (x86 Options): Fix description of -m32 option.

    (cherry picked from commit eeb92704967875411416b0b9508aa6f49e8192fd)

[Bug target/109954] x86-64's -m32 does not conform to documentation

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.5
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on all active branches.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redi at gcc dot gnu.org,
                   |                            |tschwinge at gcc dot gnu.org

--- Comment #17 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
I'm still confused.

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=[32-bit x86]'.)

However, 'gcc/config/i386/i386.opt':

    m32
    Target RejectNegative Negative(m64) InverseMask(ISA_64BIT)
Var(ix86_isa_flags) Save
    Generate 32bit i386 code.

Note: "32bit i386 code".

And, 'gcc/config/i386/x86-64.h'

    #define ASM_SPEC "%{m16|m32:--32} %{m64:--64} %{mx32:--x32}"

Per 'info as':

    The i386 version of 'as' has a few machine dependent options:

    '--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.

Note: "'--32' implies Intel i386 architecture" (thus, 32-bit x86 code?), again.

All that similar for the other related options, as has been mentioned already.

---

Do we need a different default '--with-arch-32=[...]' -- like a number of other
GCC configurations seem to be doing?  For example:

    i[34567]86-*-solaris2* | x86_64-*-solaris2*)
            [...]
            with_arch_32=${with_arch_32:-pentium4}

    mips*-img-linux*)
            [...]
            with_arch_32="mips32r6"
            with_arch_64="mips64r6"

[Bug target/109954] x86-64's -m32 does not conform to documentation

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
i386 is an overloaded term, sometimes it means just i386 CPUs and not i486 and
later,
at other times it means the all CPUs capable of running i386 32-bit code,
sometimes it means ia32.
I don't think it would be a good idea to change the defaults, that would do
more harm than good and all users can pick their own defaults if they don't
like the defaults.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[jbeulich at suse dot com]

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

--- Comment #19 from jbeulich at suse dot com ---
(In reply to Thomas Schwinge from comment #17)
> I'm still confused.
> 
> 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=[32-bit x86]'.)
> 
> However, 'gcc/config/i386/i386.opt':
> 
>     m32
>     Target RejectNegative Negative(m64) InverseMask(ISA_64BIT)
> Var(ix86_isa_flags) Save
>     Generate 32bit i386 code.
> 
> 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':
> 
>     The i386 version of 'as' has a few machine dependent options:
>     
>     '--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.
> 
> 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.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[arsen at gcc dot gnu.org]

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

--- Comment #20 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
I agree, it's probably better to just update all references to be clear that
-m32 generates IA32 code, rather than i?86 code.

IMO, for multilib, it's reasonable to target the same CPU as -m64 in terms of
available extensions (as applicable), but in a different mode.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |memmerto at ca dot ibm.com

--- Comment #21 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 95661 has been marked as a duplicate of this bug. ***