-march=pentium4 issue

Message

Messiah · Post by **Messiah** » Mon Mar 24, 2003 11:11 am

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=d ... p_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.

sputnik1969 · Post by **sputnik1969** » Mon Mar 24, 2003 7:51 pm

Messiah wrote: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=d ... p_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.

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

vikwiz · Post by **vikwiz** » Mon Mar 24, 2003 9:04 pm

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

barlad · Post by **barlad** » Mon Mar 24, 2003 9:24 pm

got no problem with -march=pentium4. Everything works fine so far. Hopefully it will stay that way

.

rtn · Post by **rtn** » Tue Mar 25, 2003 9:50 pm

If you have a recent version of portage and merged the make.conf, you might
find something like this in it:

Code: Select all

# ATHLON-4 will generate invalid SSE instructions; use 'athlon' instead.
# PENTIUM4 will generate invalid instructions; use 'pentium3' instead.

*shrug* You have been warned.

--rtn

Liathus · Post by **Liathus** » Wed Mar 26, 2003 12:27 am

for those of you that are using march=pentum4... try to run this code

Code: Select all

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

vikwiz · Post by **vikwiz** » Wed Mar 26, 2003 3:25 am

Liathus wrote:for those of you that are using march=pentum4... try to run this code
Code: Select all
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...

rlyacht · Post by **rlyacht** » Wed Mar 26, 2003 3:33 am

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.

Vazagi · Post by **Vazagi** » Wed Mar 26, 2003 9:50 am

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?

snutte · Post by **snutte** » Wed Mar 26, 2003 2:12 pm

pentium4 works great for me with gcc 3.2.2 cant say that ive had any problems.

Liathus · Post by **Liathus** » Wed Mar 26, 2003 2:18 pm

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 :(

Vazagi · Post by **Vazagi** » Wed Mar 26, 2003 11:06 pm

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.

Beetle B. · Post by **Beetle B.** » Thu Mar 27, 2003 1:32 am

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?

Liathus · Post by **Liathus** » Thu Mar 27, 2003 6:22 am

Yes... If you didnt get an overflow you should be alright. At least to the best of my knowledge.

daktak · Post by **daktak** » Sat Mar 29, 2003 1:47 pm

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) ?

Vazagi · Post by **Vazagi** » Sat Mar 29, 2003 4:41 pm

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.

daktak · Post by **daktak** » Mon Mar 31, 2003 6:08 am

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,

Vazagi · Post by **Vazagi** » Mon Mar 31, 2003 8:34 am

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... =/

daktak · Post by **daktak** » Mon Mar 31, 2003 9:25 am

Excellent, thanks Vazagi,

Ok is there anything else that could be causing probs apart from glibc?
anything else have to re emerge?

jesterspet · Post by **jesterspet** » Mon Mar 31, 2003 8:36 pm

For those that care for an update:

I have sucessfully gotten Glibc to compile and work without issue with the following flags

Code: Select all

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: Select all

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

daktak · Post by **daktak** » Wed Apr 02, 2003 12:51 am

CFLAGS="-march=pentium4 -O3 -pipe -ffast-math -fPIC -mno-sse2 -mmmx -msse -mfpmath=sse,387 -falign-functions=4 -fomit-frame-pointer"

works

FarcePest · Post by **FarcePest** » Wed Apr 02, 2003 7:55 pm

Code: Select all

CFLAGS="-march=pentium3 -mcpu=pentium4 -O2 -finline-functions -falign-jumps=5 -falign-loops=5 -falign-functions=64 -pipe"

To test:

Code: Select all

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

Code: Select all

info gcc

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

nat · Post by **nat** » Tue Apr 08, 2003 9:31 am

Liathus wrote:for those of you that are using march=pentum4... try to run this code
Code: Select all
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).

bsolar · Post by **bsolar** » Tue May 20, 2003 7:03 am

Heard that from gcc-3.2.3 the issue is resolved. Can someone confirm?

subodh · Post by **subodh** » Tue May 20, 2003 8:08 am

Yes this bug has been resolved in gcc-3.2.3 and gcc-3.3. gcc-3.3 is available in portage (hard masked).

-march=pentium4 issue

-march=pentium4 issue

Re: -march=pentium4 issue

Re: -march=pentium4 issue

This WFM