https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Sam James changed:
What|Removed |Added
CC||ismael at linux dot com
--- Comment #22 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Andrew Pinski changed:
What|Removed |Added
CC||memmerto at ca dot ibm.com
--- Comment
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
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
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 woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Thomas Schwinge changed:
What|Removed |Added
CC||redi at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.5
Resolution|---
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 Wa
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 Wa
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 Wak
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 Wak
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #10 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Richard Biener changed:
What|Removed |Added
Keywords||documentation
--- Comment #9 from Rich
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
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.
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{
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 --wi
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 implici
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 si
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-05-24
Ever confirmed|0
22 matches
Mail list logo
