GCC4 and CFLAGS

[Guinpen]

I wonder why I didn't find this already asked on the forum, but hey, here it comes: Will the following happily fuctioning (under GCC 3.4.4) CFLAGS work on GCC 4.0.2 which I want to try out? What about 4.1.0 (beta)? Hardware is Pentium-M 1.3 Banias, 512 RAM.

Code: Select all

ARCH="x86"
CFLAGS="-O2 -march=pentium-m -mtune=pentium-m -pipe -ftracer -fomit-frame-pointer -ffast-math -momit-leaf-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS=${CFLAGS}
LDFLAGS="-Wl,-O1"

[Gnufsh]

Yes., but -momit-leaf-pointer is implied by -fomit-frame-pointer and possibly -O2, so you don't really need it. And people generally advise against -ffast-math. I used -ffast-math for a while, now I don't. I didn't have that many problems with it because most packages that it breaks filter it out. Of course, these are generally the ones that would see the greatest speed-up.

[Guinpen]

Thank you, I have taken your suggestions in mind and removed the 2 flags.

[nbvcxz]

My suggestion is add -ftree-vectorize -fno-ident -s to CFLAGS and CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fno-enforce-eh-specs". You can also remove some debugging code by adding -DNDEBUG -DG_DISABLE_ASSERT -DNO_DEBUG but be carefull - eg. gimp don't like it. Pls have a look at http://forums.gentoo.org/viewtopic-t-333123.html

[Guinpen]

Thanks, although I definitely don't need more crazy optimization over what I have.. it's fast enough, and quite stable like this. I was more worried about GCC4 being broken for my existing flags, rather than adding new ones.

BTW, would -Os instead of -O2 produce substantial decrease in memory requirements for applications, or am I dreaming?

[Gnufsh]

I don't think it would be substantial. IMHO, you're better off with -O2, performance-wise.

[cheater1034]

I am also looking for a stable and optmized setup for GCC 4.x so far building up, I was considering.

Code: Select all

CFLAGS="-O2 -march=athlon-xp -mtune=athlon-xp -fomit-frame-pointer -ftracer -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

NO LDFLAGS :) it breaks about everything

I am about to rebuild the world (testing a new make.conf setup) but a stable make.conf that still has optimization sounds appealing as long as the peformance is increased, not decreased

[nbvcxz]

Au contraire Gnufsh. Because of my rather old computer with Gentoo installed and only 124 Mb ram I use (which works great):

Code: Select all

Portage 2.0.53 (default-linux/x86/2005.0, gcc-4.0.2, glibc-2.3.5.20050722-r0, 2.6.14-nitro2 i686)
=================================================================
System uname: 2.6.14-nitro2 i686 Pentium III (Coppermine)
Gentoo Base System version 1.12.0_pre11
ccache version 2.4 [enabled]
dev-lang/python:     2.3.4-r1, 2.4.2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.91.0.3
sys-devel/libtool:   1.5.20-r1
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-Os -march=pentium3 -mtune=pentium3 -pipe -s -ftree-vectorize -fno-ident -mmmx -msse  -DNDEBUG -DG_DISABLE_ASSERT -DNO_DEBUG"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-Os -march=pentium3 -mtune=pentium3 -pipe -s -ftree-vectorize -fno-ident -mmmx -msse  -DNDEBUG -DG_DISABLE_ASSERT -DNO_DEBUG -fvisibility-inlines-hidden -fno-enforce-eh-specs"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://src.gentoo.pl http://gentoo.zie.pg.gda.pl http://194.117.143.72 ftp://mirror.switch.ch/mirror/gentoo/"
LANG="pl_PL"
LC_ALL="pl_PL"
LINGUAS="pl"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 7zip S3TC X aac acpi alsa ao artswrappersuid audiofile avi berkdb bitmap-fonts bmp bzip2 cairo cdr ck-plus crypt cups curl dbus dga dio divx4linux dlloader emboss encode esd exif expat extras fam ffmpeg flac foomaticdb fortran gdbm geoip gif gimp gimpprint glibc-omitfp glitz glut glx gmp graphviz gtk gtk2 gzip hal hou hpn idn imagemagick imlib jabber java javascript jpeg kde lcms libg++ libgda libwww mad matroska mikmod mmx mng motif mozilla mozsvg mp3 mpeg mpeg4 ncurses new-login nls no-old-linux nocardbus nowin nptl nptlonly nvidia objc ogg oggvorbis openal opengl pam pango pcre pdf pdflib perl pic plugin png python qemu-fast qt quicktime readline rogue rtc sdl slang sou speex spell sqlite sse sse-filters ssl svg svga svgz tcltk tcpd tga theora threads tiff tlen truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis win32codecs wmf wxwindows xatrix xml xml2 xv xvid xvmc zlib linguas_pl userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS

the only problem is KDE - can't compile with gcc-4

[cheater1034]

Au contraire Gnufsh. Because of my rather old computer with Gentoo installed and only 124 Mb ram I use (which works great):

Code: Select all

Portage 2.0.53 (default-linux/x86/2005.0, gcc-4.0.2, glibc-2.3.5.20050722-r0, 2.6.14-nitro2 i686)
=================================================================
System uname: 2.6.14-nitro2 i686 Pentium III (Coppermine)
Gentoo Base System version 1.12.0_pre11
ccache version 2.4 [enabled]
dev-lang/python:     2.3.4-r1, 2.4.2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.91.0.3
sys-devel/libtool:   1.5.20-r1
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-Os -march=pentium3 -mtune=pentium3 -pipe -s -ftree-vectorize -fno-ident -mmmx -msse  -DNDEBUG -DG_DISABLE_ASSERT -DNO_DEBUG"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-Os -march=pentium3 -mtune=pentium3 -pipe -s -ftree-vectorize -fno-ident -mmmx -msse  -DNDEBUG -DG_DISABLE_ASSERT -DNO_DEBUG -fvisibility-inlines-hidden -fno-enforce-eh-specs"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://src.gentoo.pl http://gentoo.zie.pg.gda.pl http://194.117.143.72 ftp://mirror.switch.ch/mirror/gentoo/"
LANG="pl_PL"
LC_ALL="pl_PL"
LINGUAS="pl"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 7zip S3TC X aac acpi alsa ao artswrappersuid audiofile avi berkdb bitmap-fonts bmp bzip2 cairo cdr ck-plus crypt cups curl dbus dga dio divx4linux dlloader emboss encode esd exif expat extras fam ffmpeg flac foomaticdb fortran gdbm geoip gif gimp gimpprint glibc-omitfp glitz glut glx gmp graphviz gtk gtk2 gzip hal hou hpn idn imagemagick imlib jabber java javascript jpeg kde lcms libg++ libgda libwww mad matroska mikmod mmx mng motif mozilla mozsvg mp3 mpeg mpeg4 ncurses new-login nls no-old-linux nocardbus nowin nptl nptlonly nvidia objc ogg oggvorbis openal opengl pam pango pcre pdf pdflib perl pic plugin png python qemu-fast qt quicktime readline rogue rtc sdl slang sou speex spell sqlite sse sse-filters ssl svg svga svgz tcltk tcpd tga theora threads tiff tlen truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis win32codecs wmf wxwindows xatrix xml xml2 xv xvid xvmc zlib linguas_pl userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS

the only problem is KDE - can't compile with gcc-4

Possibly that is CFLAG breakage :-p I compiled kde 3.5 numerous times (emerge kde) with GCC 4.0.2 and my stable make.conf setup :-p

[nxsty]

I wouldn't recomend using the vectorizer in gcc 4.0. It's still suboptimal and usually only decreases performance. It'll be much better in 4.1 and 4.2.

[nbvcxz]

Possibly that is CFLAG breakage :-p I compiled kde 3.5 numerous times (emerge kde) with GCC 4.0.2 and my stable make.conf setup :-p

My mistake - I can't compile kdelibs 3.4.x, so far I have't tried last ver. See http://forums.gentoo.org/viewtopic-t-39 ... ight-.html and http://forums.gentoo.org/viewtopic-t-38 ... t-175.html

(btw - it can't be CFLAGS breakage - I tried event with CFLAGS="-O2 -march=pentium3" and the same CXXFLAGS with no success)

[enderandrew]

I am also looking for a stable and optmized setup for GCC 4.x so far building up, I was considering.

Code: Select all

CFLAGS="-O2 -march=athlon-xp -mtune=athlon-xp -fomit-frame-pointer -ftracer -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

NO LDFLAGS :) it breaks about everything

I am about to rebuild the world (testing a new make.conf setup) but a stable make.conf that still has optimization sounds appealing as long as the peformance is increased, not decreased

I know several users who report zero problems using LDFLAGs, myself included with GCC 4.x

I've yet to read a single report of someone who actually broke their system with normal LDFLAGS on GCC 4.x

So why continue to insist that LDFLAGS break everything?

[luisfelipe]

Just a quick note : with gcc 4.1 at least, some packages require -ffriend-injection in order to compile. Also, my system still has something
like 15 packages that don't compile with it yet, but they are mostly small stuff.
I didn't notice any significant speed increase after upgrading from gcc 3.x .

[yoshi314]

i believe i had. but it could just be because i installed newer packages since i installed everything from scratch ( accidental mkfs on /home and you feel free to experiment :/ ) but i think that at least gcc4 works faster than gcc3, as big packages take less time to build. (there is some improvement with glibc, for example)

i use 4.0.2 with pentium4-based celeron willamette 1.7ghz (it's said to be dog slow, perhaps it is) and 768mb ram

Code: Select all

CFLAGS="-march=pentium4 -mtune=pentium4 -O2 -pipe -fomit-frame-pointer -mfpmath=sse -funit-at-a-time"
CXXCFLAGS="${CFLAGS}"

i often pop -fvisibility-inlines-hidden to cxxflags, and remove them if something fails to work.

so far there have been little apps failing with gcc4 - qemu does not compile (probably never will, judging from the developers point of view), transcode does not compile.

[luisfelipe]

transcode compiles here. And you are indeed correct about gcc4 being faster at compiling. When I said that I didn't notice
any performance increase, I meant system-wise.

[Tiger683]

insane LDFLAGS don't break more packages under gcc-4 than under gcc-3, that's a fact.
Actually, only thing that might mess up something is --as-needed, but mostly stuff that can't take it simply doesn't compile, so you know what's up
before runtime.

The masked version of transcode in portage (1.X.X) builds with gcc-4.1

Kernels built with gcc-4.X are noticeably slower than built with gcc-3.4

[nxsty]

i often pop -fvisibility-inlines-hidden to cxxflags, and remove them if something fails to work.

You need the first patch from this bug to fix that:
http://bugs.gentoo.org/show_bug.cgi?id=109633

[cheater1034]

I am also looking for a stable and optmized setup for GCC 4.x so far building up, I was considering.

Code: Select all

CFLAGS="-O2 -march=athlon-xp -mtune=athlon-xp -fomit-frame-pointer -ftracer -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

NO LDFLAGS :) it breaks about everything

I am about to rebuild the world (testing a new make.conf setup) but a stable make.conf that still has optimization sounds appealing as long as the peformance is increased, not decreased

I know several users who report zero problems using LDFLAGs, myself included with GCC 4.x

I've yet to read a single report of someone who actually broke their system with normal LDFLAGS on GCC 4.x

So why continue to insist that LDFLAGS break everything?

Maybe because simply, it does :-p I added the following to *test*, "LDFLAGS="-W1,-O1", what happened on emerge -e system? it failed on the first package (patch) I removed them, and everything worked fine.

And you get a lot of linker errors, not a good idea for ANY* compiler

[nxsty]

Maybe because simply, it does :-p I added the following to *test*, "LDFLAGS="-W1,-O1", what happened on emerge -e system? it failed on the first package (patch) I removed them, and everything worked fine.

And you get a lot of linker errors, not a good idea for ANY* compiler

That's because it's supposed to be LDFLAGS="-Wl,-O1" and not LDFLAGS="-W1,-O1". Letting ld optimize the ouput is safe and only breaks a few packages with broken Makefiles that passes the LDFLAGS variable to the linker directly and not through gcc.

[Tiger683]

Maybe because simply, it does :-p I added the following to *test*, "LDFLAGS="-W1,-O1", what happened on emerge -e system? it failed on the first package (patch) I removed them, and everything worked fine.

And you get a lot of linker errors, not a good idea for ANY* compiler

I don't know how badly you already broke your system before trying any LDFLAGS at all,
but your elaborations are plain wrong...sorry.

[cheater1034]

Maybe because simply, it does :-p I added the following to *test*, "LDFLAGS="-W1,-O1", what happened on emerge -e system? it failed on the first package (patch) I removed them, and everything worked fine.

And you get a lot of linker errors, not a good idea for ANY* compiler

I don't know how badly you already broke your system before trying any LDFLAGS at all,
but your elaborations are plain wrong...sorry.

I used the most stable LDFLAG setup suggested to me, and it didnt work. My system is up and running now, gcc 4.0.2-r1, no ldflags

LDFLAGS are not supported or particulary stable flags, and in order to keep the most stable possible system on gcc 4.x, it is probally best to not use them.

[mpalencia]

My current system is compiled from scratch using gcc 4.0.2-20051110 (overlay) and nxstys overlay which adds support for -Bdirect.
these are my LDFLAGS:
LDFLAGS="-Wl,-O1 -Wl,-Bdirect -Wl,-z,now"
Of course, -Bdirect is still experimental, although I have not had any problems with it.
The recommended "stable" that will probably not break anything is -Wl,-O1
I use -z,now because it loads all the libraries used by an application, which incresases load time but improves performance and stabilty (or so I read)

[enderandrew]

Maybe because simply, it does :-p I added the following to *test*, "LDFLAGS="-W1,-O1", what happened on emerge -e system? it failed on the first package (patch) I removed them, and everything worked fine.

And you get a lot of linker errors, not a good idea for ANY* compiler

I don't know how badly you already broke your system before trying any LDFLAGS at all,
but your elaborations are plain wrong...sorry.

I used the most stable LDFLAG setup suggested to me, and it didnt work. My system is up and running now, gcc 4.0.2-r1, no ldflags

LDFLAGS are not supported or particulary stable flags, and in order to keep the most stable possible system on gcc 4.x, it is probally best to not use them.

Except I just built two systems with gcc 4.0.2-r1 with the following flags with no problems:

CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -ftracer"
CXXFLAGS="${CFLAGS} -ffriend-injection -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed"

[cheater1034]

Well I dont know what to say.
(1) - The Setup, LDFLAGS="-W1,-O1", did not work (maybe I did it wrong )
(2) - Attempting stability, Im staying away

[mpalencia]

(1) - The Setup, LDFLAGS="-W1,-O1", did not work (maybe I did it wrong )

Maybe the problem is this: LDFLAGS="-W1,-O1", where it should be LDFLAGS="-Wl,-O1", with the letter "L" not the number 1.