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

2023-07-09 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

Andrew Pinski  changed:

   What|Removed |Added

 CC||memmerto at ca dot ibm.com

--- Comment #21 from Andrew Pinski  ---
*** Bug 95661 has been marked as a duplicate of this bug. ***

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

2023-06-02 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #20 from Arsen Arsenović  ---
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

2023-06-02 Thread jbeulich at suse dot com via Gcc-bugs
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

2023-06-02 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #18 from Jakub Jelinek  ---
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

2023-06-02 Thread tschwinge at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

Thomas Schwinge  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #17 from Thomas Schwinge  ---
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

2023-06-01 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #16 from Jonathan Wakely  ---
Fixed on all active branches.

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

2023-06-01 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #15 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-11432-gbdd038cc1782b550b434a806ce995fc79f5d1f6b
Author: Jonathan Wakely 
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

2023-06-01 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-10838-g8538e22f0004565bb95b10741bfd416961030f4c
Author: Jonathan Wakely 
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

2023-06-01 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

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

commit r12-9672-g4466c5ba6e2f1759a2ce461f15fc4e018872a22e
Author: Jonathan Wakely 
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

2023-06-01 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #12 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

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

commit r13-7398-g3b95319b621d95055da182c5fbbccd0d82cb919e
Author: Jonathan Wakely 
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

2023-06-01 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-1464-geeb92704967875411416b0b9508aa6f49e8192fd
Author: Jonathan Wakely 
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

2023-06-01 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

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

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

2023-05-25 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #9 from Richard Biener  ---
Documentation issue.

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

2023-05-24 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #8 from Jonathan Wakely  ---
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

2023-05-24 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #7 from Jakub Jelinek  ---
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

2023-05-24 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #6 from Jonathan Wakely  ---
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

2023-05-24 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #5 from Jakub Jelinek  ---
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

2023-05-24 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #4 from Jonathan Wakely  ---
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

2023-05-24 Thread jbeulich at suse dot com via Gcc-bugs
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

2023-05-24 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So s/on any i386 system/in 32-bit mode/ ?

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

2023-05-24 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
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.