View previous topic :: View next topic |
Author |
Message |
Messiah Tux's lil' helper
Joined: 30 Apr 2002 Posts: 139
|
Posted: Mon Mar 24, 2003 11:11 am Post subject: -march=pentium4 issue |
|
|
Dear all,
i have some problems. I installed my machine with march=pentium4, but now one specific program doesn't work, see this:
https://sourceforge.net/tracker/?func=detail&atid=113764&aid=706976&group_id=13764
It seems that i need to pick something less restrictive. i have a pentium4 machine. What should i take? pentium3 perhaps?
Any ideas are welcome. |
|
Back to top |
|
|
sputnik1969 Guru
Joined: 08 Aug 2002 Posts: 401 Location: Berlin / Germany
|
Posted: Mon Mar 24, 2003 7:51 pm Post subject: Re: -march=pentium4 issue |
|
|
gcc 3.2.2 creates defect bins with -march=pentium4, try -march=pentium3 or -mcpu=pentium4, but i think -march=pentium3 will create better/faster binaries... _________________ 'Cynic' is a word invented by optimists to criticize realists. - Nigel. In the ocean of Night by Gregory Benford
"Zyniker" ist ein Wort das Optimisten erfunden haben um Realisten zu kritisieren. - Nigel. Im Meer der Nacht von Gregory Benford |
|
Back to top |
|
|
vikwiz n00b
Joined: 01 Mar 2003 Posts: 50 Location: Budapest
|
Posted: Mon Mar 24, 2003 9:04 pm Post subject: Re: -march=pentium4 issue |
|
|
sputnik1969 wrote: | gcc 3.2.2 creates defect bins with -march=pentium4, try -march=pentium3 or -mcpu=pentium4, but i think -march=pentium3 will create better/faster binaries... |
Don't tell me, please!
My actual system emerged with -march=pentium4, initialy with gcc 3.2, later packages with gcc 3.2.2, without troubles.
Now I'm emerging a new system in a chroot jail from stage1, it's downloading/compiling since more than 2 or 3 weeks now, and you tell me it will be defected? I will be very sad |
|
Back to top |
|
|
barlad l33t
Joined: 22 Feb 2003 Posts: 673
|
Posted: Mon Mar 24, 2003 9:24 pm Post subject: |
|
|
got no problem with -march=pentium4. Everything works fine so far. Hopefully it will stay that way . |
|
Back to top |
|
|
rtn Guru
Joined: 15 Nov 2002 Posts: 427
|
Posted: Tue Mar 25, 2003 9:50 pm Post subject: |
|
|
If you have a recent version of portage and merged the make.conf, you might
find something like this in it:
Code: | # ATHLON-4 will generate invalid SSE instructions; use 'athlon' instead.
# PENTIUM4 will generate invalid instructions; use 'pentium3' instead.
|
*shrug* You have been warned.
--rtn |
|
Back to top |
|
|
Liathus Apprentice
Joined: 21 Mar 2003 Posts: 163 Location: Fargo, ND
|
Posted: Wed Mar 26, 2003 12:27 am Post subject: |
|
|
for those of you that are using march=pentum4... try to run this code
Code: |
python -c 'int(10.1); int(10000.3); int(1.2)'
|
It will most likely give you an overflow error. This is just an example of the binary corruption that DOES occur with march=pentium4 on gcc3.2x |
|
Back to top |
|
|
vikwiz n00b
Joined: 01 Mar 2003 Posts: 50 Location: Budapest
|
Posted: Wed Mar 26, 2003 3:25 am Post subject: |
|
|
Liathus wrote: | for those of you that are using march=pentum4... try to run this code
Code: |
python -c 'int(10.1); int(10000.3); int(1.2)'
|
It will most likely give you an overflow error. This is just an example of the binary corruption that DOES occur with march=pentium4 on gcc3.2x |
yes, confirm, it does
so rebuild all... |
|
Back to top |
|
|
rlyacht Apprentice
Joined: 17 Apr 2002 Posts: 170
|
Posted: Wed Mar 26, 2003 3:33 am Post subject: |
|
|
I just had exactly this problem (int function in python), and I traced it down to the modf library function in glibc. It does indeed seem that -march-pentium4 is the culprit. I compiled glibc with -O2 and it worked fine, and I bet -O3 would too. Without the -march=, I assume that you get pentium3....
Anyway, recompliing python with different settings won't fix this; you need to recompile glibc. _________________ It's spelled Raymond Luxury-Yacht, but it's pronounced Throat-Warbler Mangrove. |
|
Back to top |
|
|
Vazagi n00b
Joined: 07 Jan 2003 Posts: 43 Location: Denmark
|
Posted: Wed Mar 26, 2003 9:50 am Post subject: |
|
|
I have compiled a lot of my system with the march=pentium4 flag and gcc 3.2.2, so I'm wondering, how much of my system would I need to recompile? Should I remerge everything that was compiled with march=pentium4 & gcc 3.2.2? |
|
Back to top |
|
|
snutte Apprentice
Joined: 24 Apr 2002 Posts: 181 Location: Sweden, Malmö
|
Posted: Wed Mar 26, 2003 2:12 pm Post subject: |
|
|
pentium4 works great for me with gcc 3.2.2 cant say that ive had any problems. |
|
Back to top |
|
|
Liathus Apprentice
Joined: 21 Mar 2003 Posts: 163 Location: Fargo, ND
|
Posted: Wed Mar 26, 2003 2:18 pm Post subject: |
|
|
I don't know the answer to this. I can only assume that anything compiled while those setting were in place could contain potential problems. Now i do not no how seriously this will effect the system. I started my system with march=pentium4 and after i realized this was wrong switched it.
The stance i have been taking is that if I notice something goofey I will recompile that package. This might not be a good choice though as some things may be difficult if not impossible detect.
I guess if i was running a server (as oppesed to a laptop) or any other mission critical setup I would recompile anything to be certain.
I think that we could really use some help here from some gcc gurus. For instance, if we installed from a stage 1 with march=pentium4 is our gcc itself potentially corrupt? i don't know all of the answers... i am trying to figure this out as well :( |
|
Back to top |
|
|
Vazagi n00b
Joined: 07 Jan 2003 Posts: 43 Location: Denmark
|
Posted: Wed Mar 26, 2003 11:06 pm Post subject: |
|
|
There's some more information on the problem here.
Apparently, using the flag '-mno-sse2' should fix it. I'll test it and post the results.
...
Whoops, had forgotten to click submit =/
Anyway, it seems that the glibc ebuild uses a function that strips away most of the cflags, including '-mno-sse2' and I have no idea of how to disabling this safely even though I did get it working by changing line 32 in /usr/portage/eclass/flag-o-matic.eclass from
ALLOWED_FLAGS="-O -mcpu -march -pipe -g"
to
ALLOWED_FLAGS="-O -mcpu -march -pipe -g -mno-sse2"
I just hope that this doesn't break anything. =/
EDIT:
Oh, and yes, -mno-sse2 seems to have fixed the problem.
At least the code snipped provided by Liathus no longer results in an overflow. |
|
Back to top |
|
|
Beetle B. Guru
Joined: 01 Mar 2003 Posts: 524
|
Posted: Thu Mar 27, 2003 1:32 am Post subject: |
|
|
I didn't get an overflow error.
But I didn't get anything else either (just takes me back to the prompt). So am I OK? _________________ Beetle B.
Please update the table of equivalents.
A Firefox guide. |
|
Back to top |
|
|
Liathus Apprentice
Joined: 21 Mar 2003 Posts: 163 Location: Fargo, ND
|
Posted: Thu Mar 27, 2003 6:22 am Post subject: |
|
|
Yes... If you didnt get an overflow you should be alright. At least to the best of my knowledge. |
|
Back to top |
|
|
daktak Tux's lil' helper
Joined: 18 Oct 2002 Posts: 142 Location: Melbourne, Victoria
|
Posted: Sat Mar 29, 2003 1:47 pm Post subject: |
|
|
ok so ive tried various flags, and emerging python, and no matter what i do i get the error,
so what do i have to do?
rebuild all? how? (or emerge -eu python for examlple to get python to work) ? |
|
Back to top |
|
|
Vazagi n00b
Joined: 07 Jan 2003 Posts: 43 Location: Denmark
|
Posted: Sat Mar 29, 2003 4:41 pm Post subject: |
|
|
daktak wrote: | ok so ive tried various flags, and emerging python, and no matter what i do i get the error,
so what do i have to do?
rebuild all? how? (or emerge -eu python for examlple to get python to work) ? |
I just emerged glibc and the error went away. However, I'm not sure if there are other packages that needs to be remerged. |
|
Back to top |
|
|
daktak Tux's lil' helper
Joined: 18 Oct 2002 Posts: 142 Location: Melbourne, Victoria
|
Posted: Mon Mar 31, 2003 6:08 am Post subject: |
|
|
i tried re emerging glibc with the cflag -mno-sse2 and the python thing still failed, so i did it with pentium 3 and i passed the test, |
|
Back to top |
|
|
Vazagi n00b
Joined: 07 Jan 2003 Posts: 43 Location: Denmark
|
Posted: Mon Mar 31, 2003 8:34 am Post subject: |
|
|
That's because the glibc ebuild removes most CFLAGs including the '-mno-sse2' flag. I posted one way to avoid this a couple of posts back, but remember that it's just a hack... =/ |
|
Back to top |
|
|
daktak Tux's lil' helper
Joined: 18 Oct 2002 Posts: 142 Location: Melbourne, Victoria
|
Posted: Mon Mar 31, 2003 9:25 am Post subject: |
|
|
Excellent, thanks Vazagi,
Ok is there anything else that could be causing probs apart from glibc?
anything else have to re emerge? |
|
Back to top |
|
|
jesterspet Apprentice
Joined: 05 Feb 2003 Posts: 215 Location: Atlanta
|
Posted: Mon Mar 31, 2003 8:36 pm Post subject: |
|
|
For those that care for an update:
I have sucessfully gotten Glibc to compile and work without issue with the following flags
Code: | CFLAGS="-s -march=pentium3 -mcpu=pentium4 -mmmx -msse -msse2 -Os -fomit-frame-pointer -pipe -fexpensive-optimizations -fpic -frerun-cse-after-loop -frerun-loop-opt -foptimize-register-move -masm=intel" |
Running the python code
Code: | python -c 'int(10.1); int(10000.3); int(1.2)' |
generates no error. and i have not seen anything else puke during my daily computing. Having not changed anything else (not even recompiling Python) I would say that a possible workaround to the '-march=pentium4' issue is to either use '-mno-sse2' or 'march=pentium3 -mcpu=pentium4'
Can anyone confirm or deny that either one of these two workaround works _________________ (X) Yes! I am a brain damaged lemur on crack, and would like to buy your software package for $499.95 |
|
Back to top |
|
|
daktak Tux's lil' helper
Joined: 18 Oct 2002 Posts: 142 Location: Melbourne, Victoria
|
Posted: Wed Apr 02, 2003 12:51 am Post subject: |
|
|
CFLAGS="-march=pentium4 -O3 -pipe -ffast-math -fPIC -mno-sse2 -mmmx -msse -mfpmath=sse,387 -falign-functions=4 -fomit-frame-pointer"
works |
|
Back to top |
|
|
FarcePest n00b
Joined: 27 Jan 2003 Posts: 10 Location: Georgia, US
|
Posted: Wed Apr 02, 2003 7:55 pm Post subject: This WFM |
|
|
Code: | CFLAGS="-march=pentium3 -mcpu=pentium4 -O2 -finline-functions -falign-jumps=5 -falign-loops=5 -falign-functions=64 -pipe"
|
To test:
Code: | $ gcc -Q -v $CFLAGS -c nothing.c # an empty file
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs
Configured with: /var/tmp/portage/gcc-3.2.2-r2/work/gcc-3.2.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.2 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,ada,f77,objc,java --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext
Thread model: posix
gcc version 3.2.2 20030322 (Gentoo Linux 1.4 3.2.2-r2)
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ -D__pentium2 -D__pentium2__ -D__pentium3 -D__pentium3__ -D__tune_pentium4__ -D__SSE__ -D__MMX__ nothing.c -dumpbase nothing.c -march=pentium3 -mcpu=pentium4 -mpreferred-stack-boundary=2 -O2 -version -finline-functions -falign-jumps=5 -falign-loops=5 -falign-functions=64 -o - |
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/../../../../i686-pc-linux-gnu/bin/as
-V -Qy -o nothing.o -
GNU CPP version 3.2.2 20030322 (Gentoo Linux 1.4 3.2.2-r2) (cpplib) (i386 Linux/ELF)
GNU C version 3.2.2 20030322 (Gentoo Linux 1.4 3.2.2-r2) (i686-pc-linux-gnu)
compiled by GNU C version 3.2.2 20030322 (Gentoo Linux 1.4 3.2.2-r2).
options passed: -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2
-D__GNUC_PATCHLEVEL__=2 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix
-D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__
-D__unix -D__linux -Asystem=posix -D__OPTIMIZE__ -D__STDC_HOSTED__=1
-Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__i686 -D__i686__
-D__pentiumpro -D__pentiumpro__ -D__pentium2 -D__pentium2__ -D__pentium3
-D__pentium3__ -D__tune_pentium4__ -D__SSE__ -D__MMX__ -march=pentium3
-mcpu=pentium4 -mpreferred-stack-boundary=2 -O2 -finline-functions
-falign-jumps=5 -falign-loops=5 -falign-functions=64
options enabled: -fdefer-pop -foptimize-sibling-calls -fcse-follow-jumps
-fcse-skip-blocks -fexpensive-optimizations -fthread-jumps
-fstrength-reduce -fpeephole -fforce-mem -ffunction-cse
-fkeep-static-consts -fcaller-saves -fpcc-struct-return -fgcse -fgcse-lm
-fgcse-sm -frerun-cse-after-loop -frerun-loop-opt
-fdelete-null-pointer-checks -fschedule-insns2 -fsched-interblock
-fsched-spec -fbranch-count-reg -freorder-blocks -fcprop-registers
-fcommon -fgnu-linker -fregmove -foptimize-register-move -fargument-alias
-fstrict-aliasing -fmerge-constants -fident -fpeephole2
-fguess-branch-probability -fmath-errno -ftrapping-math -m80387
-mhard-float -mno-soft-float -mieee-fp -mfp-ret-in-387 -mcpu=pentium4
-march=pentium3 -mpreferred-stack-boundary=2
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include
/usr/include
End of search list.
GNU assembler version 2.13.90.0.20 (i686-pc-linux-gnu) using BFD version 2.13.90.0.20 20030319
Execution times (seconds)
TOTAL : 0.01 0.01 0.04
|
Note that there is no -D__SSE2__, because the Pentium 3 instruction set (determined by -march=pentium3) does not have SSE2. (SSE2 support is apparently buggy in current GCC. SSE2, when available, is used for double-precision floating point calculations.) However optimization is done according to the Pentium 4 instruction timings (determined by -march=pentium4).
Also note that if you manually try to do -mmmx, the compiler does -mmmx and -mno-mmx. Same applies for -msse and -msse2. (Try it yourself.)
The -falign-*= stuff I picked up from one of the other threads. The Pentium 4 uses a 128-byte cache line (i.e. entries are in blocks of 128 bytes). Going across boundaries incurs a performance penalty. Apparently aligning at 64 bytes is also ok. From what I can tell, most Pentium 3's (Coppermine and up?) also have a 128-byte cache line. Anyway...
-falign-functions=64 makes sure that functions start at the beginning of a cache line (or in the middle).
-falign-loops=5 makes (mostly) sure that loops start on an 8-byte boundary, for performance reasons. Why 8 when there is clearly a 5 there? Because GCC rounds up to the next power of 2. Why not put an 8 there? If 5 or more bytes are required to pad (with nop) to the next boundary, it doesn't pad. (5 nops is also a performance hit...) 4 is also an acceptable value here.
-falign-jumps=5 is like -falign-loops only for jump entry points, for the same reasons.
for more details.
Also... Compiling for Atlhon-XP/MP has a similar problem: SSE (not SSE2, because Athlon doesn't have SSE2 yet) support is buggy. In theory you can do -march=athlon -mcpu=athlon-xp if you have an Athlon-XP. (SSE support is not in the original Athlon; I think it shows up in the Athlon-XP.) I need to try this at home.
(Note: do not use -mpreferred-stack-boundary=x. I forgot to remove this when I was researching the various flags. You'll probably break stuff if you use it.) |
|
Back to top |
|
|
nat Apprentice
Joined: 04 Sep 2002 Posts: 205
|
Posted: Tue Apr 08, 2003 9:31 am Post subject: |
|
|
Liathus wrote: | for those of you that are using march=pentum4... try to run this code
Code: |
python -c 'int(10.1); int(10000.3); int(1.2)'
|
It will most likely give you an overflow error. This is just an example of the binary corruption that DOES occur with march=pentium4 on gcc3.2x |
Does anyone has a small c-program that triggers the same error? I would like to test this but i dont want to recompile glibc. (its compiled without the sse2 support). |
|
Back to top |
|
|
bsolar Bodhisattva
Joined: 12 Jan 2003 Posts: 2764
|
Posted: Tue May 20, 2003 7:03 am Post subject: |
|
|
Heard that from gcc-3.2.3 the issue is resolved. Can someone confirm? _________________ I may not agree with what you say, but I'll defend to the death your right to say it. |
|
Back to top |
|
|
subodh n00b
Joined: 24 Apr 2003 Posts: 31 Location: UK
|
Posted: Tue May 20, 2003 8:08 am Post subject: |
|
|
Yes this bug has been resolved in gcc-3.2.3 and gcc-3.3. gcc-3.3 is available in portage (hard masked). |
|
Back to top |
|
|
|