GCC 4.5 testing

Message

xming · Post by **xming** » Fri Nov 26, 2010 12:33 pm

xibo wrote: this is due to either too agressive link optimization or (more probably) incompatible versions of dbus, qt-dbus and kdelibs (that error messages normally occurs when you forget to moc a Q_OBJECT marked QObject instance).

I tried to recompile dbus, qt-bus, kdelibs w/o -lto but still got the same, solved by recompiling world w/o -lto

pactoo · Post by **pactoo** » Sat Nov 27, 2010 3:22 pm

Anyone managed to compile ffmpeg >0.6 with gcc-4.5.1[-r1]? 0.6 goes well, but any version above fails. Just me?

Code: Select all

libswscale/swscale.c: In function 'ff_getSwsFunc':
libswscale/swscale.c:1269:9: error: implicit declaration of function 'sws_init_swScale_3DNow'
libswscale/swscale.c:1270:16: error: 'swScale_3DNow' undeclared (first use in this function)
libswscale/swscale.c:1270:16: note: each undeclared identifier is reported only once for each function it appears in
libswscale/swscale.c: In function 'sws_scale':
libswscale/swscale.c:1907:5: warning: passing argument 1 of 'check_image_pointers' from incompatible pointer type
libswscale/swscale.c:1877:12: note: expected 'uint8_t **' but argument is of type 'const uint8_t * const*'
libswscale/swscale.c:1911:5: warning: passing argument 1 of 'check_image_pointers' discards qualifiers from pointer target type
libswscale/swscale.c:1877:12: note: expected 'uint8_t **' but argument is of type 'uint8_t * const*'
libswscale/swscale.c:1993:9: warning: new qualifiers in middle of multi-level non-const cast are unsafe
libswscale/swscale.c:2016:9: warning: new qualifiers in middle of multi-level non-const cast are unsafe
libswscale/swscale.c: In function 'ff_getSwsFunc':
libswscale/swscale.c:1310:1: warning: control reaches end of non-void function
make: *** [libswscale/swscale.o] Error 1
emake failed
 * ERROR: media-video/ffmpeg-0.6_p25767 failed:
 *   (no error message)

pactoo · Post by **pactoo** » Sat Nov 27, 2010 5:14 pm

And recent mplayer-1.0_rc4_p20101114 fails, too

Code: Select all

libvorbis.c:(.text.unlikely+0xad): undefined reference to `vorbis_encode_setup_vbr'
libvorbis.c:(.text.unlikely+0xe7): undefined reference to `vorbis_encode_setup_managed'
libvorbis.c:(.text.unlikely+0x108): undefined reference to `vorbis_encode_ctl'
libvorbis.c:(.text.unlikely+0x140): undefined reference to `vorbis_encode_ctl'
libvorbis.c:(.text.unlikely+0x168): undefined reference to `vorbis_encode_ctl'
libvorbis.c:(.text.unlikely+0x170): undefined reference to `vorbis_encode_setup_init'
collect2: ld returned 1 exit status
make: *** [mplayer] Error 1
emake failed
 * ERROR: media-video/mplayer-1.0_rc4_p20101114 failed:
 *   died running emake, base_src_make

DaggyStyle · Post by **DaggyStyle** » Sat Nov 27, 2010 5:23 pm

pactoo wrote:And recent mplayer-1.0_rc4_p20101114 fails, too

Code: Select all

libvorbis.c:(.text.unlikely+0xad): undefined reference to `vorbis_encode_setup_vbr'
libvorbis.c:(.text.unlikely+0xe7): undefined reference to `vorbis_encode_setup_managed'
libvorbis.c:(.text.unlikely+0x108): undefined reference to `vorbis_encode_ctl'
libvorbis.c:(.text.unlikely+0x140): undefined reference to `vorbis_encode_ctl'
libvorbis.c:(.text.unlikely+0x168): undefined reference to `vorbis_encode_ctl'
libvorbis.c:(.text.unlikely+0x170): undefined reference to `vorbis_encode_setup_init'
collect2: ld returned 1 exit status
make: *** [mplayer] Error 1
emake failed
 * ERROR: media-video/mplayer-1.0_rc4_p20101114 failed:
 *   died running emake, base_src_make

are you sure it is gcc related?, I think it is more ffmpeg related

ssteinberg · Post by **ssteinberg** » Sat Nov 27, 2010 6:13 pm

mplayer-1.0_rc4_p20101114 compiles with gcc 4.5.1-r1.

Code: Select all

-march=native -mtune=core2 -O3 -pipe -mfpmath=sse -msse2 -msse3 -mssse3 -ftracer -funswitch-loops -fpeel-loops -fomit-frame-pointer -fexpensive-optimizations -foptimize-register-move -funsafe-math-optimizations -fira-loop-pressure -fipa-sra -floop-block -floop-interchange -floop-strip-mine -ftree-vectorize -fgraphite-identity

pactoo · Post by **pactoo** » Sat Nov 27, 2010 7:19 pm

DaggyStyle wrote:are you sure it is gcc related?, I think it is more ffmpeg related

No, I am absolutely not, that why I was asking, wether this can be reproduced. However, as older Versions (mplayer-1.0_rc4_p20100612 and ffmpeg-0.6) do still compile fine, while newer versions do not - without changing anything in the rest of the system - and gcc still being experimental, this was my closest guess

As stated in a later post, mplayer seems to compile fine. So the problem lies elsewhere. Not sure, wether this is true for ffmpeg, too

DaggyStyle · Post by **DaggyStyle** » Sat Nov 27, 2010 8:56 pm

pactoo wrote:
DaggyStyle wrote:are you sure it is gcc related?, I think it is more ffmpeg related
No, I am absolutely not, that why I was asking, wether this can be reproduced. However, as older Versions (mplayer-1.0_rc4_p20100612 and ffmpeg-0.6) do still compile fine, while newer versions do not - without changing anything in the rest of the system - and gcc still being experimental, this was my closest guess

As stated in a later post, mplayer seems to compile fine. So the problem lies elsewhere. Not sure, wether this is true for ffmpeg, too

I use ffmpeg-mt from git which is based on ffmpeg git, a while ago when I switched to gcc-4.5.0, it was failing compilation, my recommendation, find a ffmpeg version which compiles well and try recompiling mplayer again.

mv · Post by mv » Sat Nov 27, 2010 9:15 pm

pactoo wrote:

Code: Select all

libvorbis.c:(.text.unlikely+0xad): undefined reference to `vorbis_encode_setup_vbr'

This is a [bug=344593]Bug in the linking flags of mplayer[/bug], not related with gcc-4.5.

schwarzygesetzlos · Post by **schwarzygesetzlos** » Mon Nov 29, 2010 9:34 pm

did a 'gcc-4.5.1-r1' emerge -eD world on my system (gnome 2.30.2, gentoo-sources-2.6.36-r3) with 976 stable packages amd64 and about 20 ~amd64 yesterday. surprisingly everything went flawlessly!

the only package i had to upgrade to ~amd64 was gutenprint.

saellaven · Post by **saellaven** » Mon Nov 29, 2010 9:35 pm

saellaven wrote: x11-libs/cairo-1.8.10 (ICE fixed by filtering graphite CFLAGS http://bugs.gentoo.org/show_bug.cgi?id=346445 )

This bug, which was likely causing some other recent ICE reports, was introduced in patchset 1.3 and a new patchset 1.4 is being pushed out this afternoon to correct it. Anyone who installed 4.5.1-r1 in the last week or so should sync and rebuild.

Darkboy76 · Post by **Darkboy76** » Tue Nov 30, 2010 1:55 am

Hello all and sorry to bother you, but I still can't understand if the CFLAG -fgraphite-identity is necessary for graphite to work properly, or if gcc 4.5.1 compiled with USE graphite and CFLAGS as

-floop-interchange -floop-strip-mine -floop-block

are enough; I'm on a Pentium IV 3.00 GHZ with hyperthreading so I can't really afford to recompile everything any other day beacause it takes too much time; I skipped -flto for the time being because it still seams to cause a lot of breakage....I know I am still a noob regarding gcc optimizations and maybe I should just stick to safe CFLAGS,but I'm running ~amd64 so I'm willing to experiment and take risks otherwise how I am supposed to learn something?

Are there other optimizations to put in CFLAGS related to my hardware (Pentium IV 3 GHZ) that could improve code and system performances? Sometimes I see a lot of you guys with many CFLAGS I don't know anythyng about and GCC wiki is not exactly enlightning...

What would you advice about LTO: just waith until it's more mature?

Tank You very much for listening to the super newbie of GCC tricks!

Darkboy76 · Post by **Darkboy76** » Tue Nov 30, 2010 2:15 am

Oh, I should add that my CFLAGS right now in make.conf look like this:

CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed"

Rion · Post by **Rion** » Tue Nov 30, 2010 5:13 am

Darkboy76 wrote:Sometimes I see a lot of you guys with many CFLAGS I don't know anythyng about and GCC wiki is not exactly enlightning...

and most of these flags includes in -O{2,3} optimization. just look at man gcc.

saellaven · Post by **saellaven** » Wed Dec 01, 2010 8:20 am

Just finished rebuilding world on 1074 packages (mostly stable and includes gnome-light, a good chunk of KDE, and a lot of common server daemons) with 4.5.1-r1 and

CFLAGS="-O2 -march=native -mtune=native -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"

(where native = -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=k8)

Code: Select all

Portage 2.1.9.24 (default/linux/amd64/10.0/desktop, gcc-4.5.1, glibc-2.12.1-r3, 2.6.36-gentoo-r3 x86_64)
=================================================================
System uname: Linux-2.6.36-gentoo-r3-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4400+-with-gentoo-1.12.14
Timestamp of tree: Wed, 01 Dec 2010 03:15:01 +0000
distcc 3.1 x86_64-pc-linux-gnu [disabled]
ccache version 2.4 [enabled]
app-shells/bash:     4.1_p7
dev-java/java-config: 2.1.11-r1
dev-lang/python:     2.6.5-r3, 3.1.2-r4
dev-util/ccache:     2.4-r7
dev-util/cmake:      2.8.1-r2
sys-apps/baselayout: 1.12.14-r1
sys-apps/sandbox:    2.3-r1
sys-devel/autoconf:  2.13, 2.65-r1
sys-devel/automake:  1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:  2.20.1-r1
sys-devel/gcc:       4.3.5, 4.4.5, 4.5.1-r1
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.10
sys-devel/make:      3.81-r2
virtual/os-headers:  2.6.36.1 (sys-kernel/linux-headers)
ABI="amd64"
ACCEPT_KEYWORDS="amd64"

I posted last week on my issues rebuilding system, all of which remained resolved during world

The following packages failed:
app-cdr/cdrdao-1.2.3 - resolved by unmasking app-cdr/cdrdao-1.2.3-r1

Code: Select all

ScsiIf-linux.cc: In static member function 'static ScsiIf::ScanData* ScsiIf::scan(int*, char*)':
ScsiIf-linux.cc:287:42: error: no matching function for call to 'stat::stat(const char [22], stat*)'
/usr/include/bits/stat.h:47:3: note: candidates are: stat::stat()
/usr/include/bits/stat.h:47:3: note:                 stat::stat(const stat&)

dev-scheme/guile-1.8.5-r1 resolved by unmasking dev-scheme/guile-1.8.7-r2

Code: Select all

libtool: link: x86_64-pc-linux-gnu-gcc -pthread -O2 -march=native -mtune=native -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -Wall -Wmissing-prototypes .libs/guileS.o -pthread -Wl,-O1 -o .libs/guile guile-guile.o -Wl,--export-dynamic  -Wl,--as-needed ./.libs/libguile.so /usr/lib64/libgmp.so -lcrypt -lm /usr/lib64/libltdl.so -ldl -pthread
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc debug.doc deprecation.doc deprecated.doc discouraged.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc futures.doc gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc gc-card.doc guardians.doc hash.doc hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc properties.doc random.doc rdelim.doc read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc stacks.doc stime.doc strings.doc srfi-4.doc srfi-13.doc srfi-14.doc strorder.doc strports.doc struct.doc symbols.doc threads.doc throw.doc values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc ramap.doc unif.doc dynl.doc filesys.doc posix.doc regex-posix.doc | GUILE="/var/tmp/portage/dev-scheme/guile-1.8.5-r1/work/guile-1.8.5/pre-inst-guile" ../scripts/snarf-check-and-output-texi          > guile-procedures.texi || { rm guile-procedures.texi; false; }
ERROR: unknown doc attribute: (location (string . alist.c) (int . 36) (hash . hash))

dev-util/kbuild-0.1.5-r2 (pulled in from jokey overlay) resolved by nuking the jokey overlay kbuild directory since the ebuilds there are very, very out of date. In fact, I just dumped the whole overlay after realizing that the latest virtualbox was in portage.

Code: Select all

In file included from /var/tmp/portage/dev-util/kbuild-0.1.5-r2/work/kBuild-0.1.5-p1/src/ash/error.c:60:0:
/var/tmp/portage/dev-util/kbuild-0.1.5-r2/work/kBuild-0.1.5-p1/src/ash/output.h:68:6: error: conflicting types for 'dprintf'
/usr/include/stdio.h:417:12: note: previous declaration of 'dprintf' was here
kmk: *** [/var/tmp/portage/dev-util/kbuild-0.1.5-r2/work/kBuild-0.1.5-p1/out/linux.amd64/release/obj/kmk_ash/error.o] Error 1

net-fs/nfs-utils-1.1.4-r1 resolved by unmasking net-fs/nfs-utils-1.2.3-r1

Code: Select all

x86_64-pc-linux-gnu-gcc -Wall -Wstrict-prototypes -pipe -O2 -march=native -mtune=native -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -Wl,-O1 -Wl,--as-needed -o exportfs exportfs.o  ../../support/export/libexport.a ../../support/nfs/libnfs.a ../../support/misc/libmisc.a -lwrap  
exportfs.o: In function `validate_export':
/var/tmp/portage/net-fs/nfs-utils-1.1.4-r1/work/nfs-utils-1.1.4/utils/exportfs/exportfs.c:400: undefined reference to `S_ISDIR'
/var/tmp/portage/net-fs/nfs-utils-1.1.4-r1/work/nfs-utils-1.1.4/utils/exportfs/exportfs.c:400: undefined reference to `S_ISREG'
collect2: ld returned 1 exit status

dev-python/PyQt4-4.7.3 long standing ICE resolved by removing -fgraphite-identity from CFLAGS (the others are fine)

Code: Select all

86_64-pc-linux-gnu-g++ -c -O2 -march=native -mtune=native -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -fPIC -Wall -W -D_REENTRANT -DNDEBUG -DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I/var/tmp/portage/dev-python/PyQt4-4.7.3/work/PyQt-x11-gpl-4.7.3-2.6/qpy/QtGui -I/usr/include/python2.6 -I/usr/mkspecs/linux-g++ -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/usr/include/qt4 -I/usr/include -o sipQtGuiQMatrix2x3.o sipQtGuiQMatrix2x3.cpp
sipQtGuiQMatrix2x3.cpp: In function 'int slot_QMatrix2x3___setitem__(PyObject*, PyObject*)':
sipQtGuiQMatrix2x3.cpp:525:16: warning: converting to non-pointer type 'int' from NULL
sipQtGuiQMatrix2x3.cpp: In function 'PyObject* meth_QMatrix2x3_setToIdentity(PyObject*, PyObject*)':
sipQtGuiQMatrix2x3.cpp:158:18: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.gentoo.org/> for instructions.

I rebooted after doing system but haven't rebooted after doing world yet, though I don't anticipate any significant runtime issues

Anon-E-moose · Post by **Anon-E-moose** » Fri Dec 03, 2010 1:06 am

I had been running 4.4.4 with the graphite flags for a while, with no problems.
Using these CFLAGS -march=native -O2 -floop-interchange -floop-strip-mine -floop-block -pipe

I added gcc 4.5.1-r1, while keeping 4.4.4 just in case, haven't recompiled everything,
just the kernel 2.6.36-zen1, with glibc and xfce-meta and a few odd packages.
System seems more responsive, and perkier.

I didn't add the -lto options (I'll wait for maturation)

costel78 · Post by **costel78** » Thu Dec 16, 2010 6:49 pm

gcc-4.5.2 has just been released. I've tested it in beta stage and happy reporting no errors.
I'll wait for ebuild and recompile all world set with it.

wrc1944 · Post by **wrc1944** » Thu Dec 30, 2010 12:33 am

Yes- just saw 4.5.2 is in ~arch so I'm compiling now on 2 boxes.
I realize this is a bug fix release, but was wondering if all the -flto & graphite stuff was going to be functional?
Been a while since I tried it.

rhill · Post by **rhill** » Thu Dec 30, 2010 2:55 am

Graphite should mostly work - we've been patching bugs as we find them. There are still some left though.

You're not going to see any bug fixes for LTO on the 4.5 branch. It's a new feature so the "regressions only" rule for backporting means no patches for LTO. So it's still broken. Don't use it. Seriously.

mv · Post by mv » Thu Dec 30, 2010 8:38 am

dirtyepic wrote:no patches for LTO. So it's still broken.

As far as I can see the problems with LTO are mainly package-specific or libtool related. I used it together with -fwhole-program for testing, and more than 50% of the packages have no problems with it. Especially: If they compile then they work. Those packages which fail usually only have a problem with shell syntax (=libtool related) or with the missing -fpic (=libtool related). (Some libraries do not like -fwhole-program, of course...). If there is an interest, I can post my mask-file of non-working packages.

kernelOfTruth · Post by **kernelOfTruth** » Thu Dec 30, 2010 1:09 pm

mv wrote:
dirtyepic wrote:no patches for LTO. So it's still broken.
As far as I can see the problems with LTO are mainly package-specific or libtool related. I used it together with -fwhole-program for testing, and more than 50% of the packages have no problems with it. Especially: If they compile then they work. Those packages which fail usually only have a problem with shell syntax (=libtool related) or with the missing -fpic (=libtool related). (Some libraries do not like -fwhole-program, of course...). If there is an interest, I can post my mask-file of non-working packages.

well, yeah in the most cases

FYI: chromium seems to be a different kind of creature - it tends to be more unstable than without

dE_logics · Post by **dE_logics** » Thu Dec 30, 2010 2:58 pm

Graphite works perfectly on Desktop systems (KDE + OOo).

jcTux · Post by **jcTux** » Thu Dec 30, 2010 4:13 pm

dE_logics wrote:Graphite works perfectly on Desktop systems (KDE + OOo).

Same here with gnome

Anon-E-moose · Post by **Anon-E-moose** » Thu Dec 30, 2010 4:22 pm

I've been using graphite all along with the 4.4 series, and haven't seen any problems.

dE_logics · Post by **dE_logics** » Thu Dec 30, 2010 4:58 pm

There's one question though.

Where's the parallelization?... I dont see any parallelization.

kernelOfTruth · Post by **kernelOfTruth** » Thu Dec 30, 2010 9:39 pm

dE_logics wrote:There's one question though.

Where's the parallelization?... I dont see any parallelization.

see: http://gcc.gnu.org/onlinedocs/gcc-4.5.2 ... tions.html

-floop-parallelize-all
Use the Graphite data dependence analysis to identify loops that can be parallelized. Parallelize all the loops that can be analyzed to not contain loop carried dependences without checking that it is profitable to parallelize the loops.

-ftree-parallelize-loops=n
Parallelize loops, i.e., split their iteration space to run in n threads. This is only possible for loops whose iterations are independent and can be arbitrarily reordered. The optimization is only profitable on multiprocessor machines, for loops that are CPU-intensive, rather than constrained e.g. by memory bandwidth. This option implies -pthread, and thus is only supported on targets that have support for -pthread.

@all:

any experience with these ?

are they already stable to use for world or specific packages ?