View previous topic :: View next topic |
Author |
Message |
xming Guru
Joined: 02 Jul 2002 Posts: 441
|
Posted: Fri Nov 26, 2010 12:33 pm Post subject: |
|
|
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 _________________ http://wojia.be |
|
Back to top |
|
|
pactoo Guru
Joined: 18 Jul 2004 Posts: 553
|
Posted: Sat Nov 27, 2010 3:22 pm Post subject: |
|
|
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: |
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)
|
|
|
Back to top |
|
|
pactoo Guru
Joined: 18 Jul 2004 Posts: 553
|
Posted: Sat Nov 27, 2010 5:14 pm Post subject: |
|
|
And recent mplayer-1.0_rc4_p20101114 fails, too
Code: |
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
|
|
|
Back to top |
|
|
DaggyStyle Watchman
Joined: 22 Mar 2006 Posts: 5909
|
Posted: Sat Nov 27, 2010 5:23 pm Post subject: |
|
|
pactoo wrote: | And recent mplayer-1.0_rc4_p20101114 fails, too
Code: |
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 _________________ Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
Back to top |
|
|
ssteinberg Apprentice
Joined: 09 Jul 2010 Posts: 206 Location: Israel
|
Posted: Sat Nov 27, 2010 6:13 pm Post subject: |
|
|
mplayer-1.0_rc4_p20101114 compiles with gcc 4.5.1-r1.
Code: | -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 |
|
|
Back to top |
|
|
pactoo Guru
Joined: 18 Jul 2004 Posts: 553
|
Posted: Sat Nov 27, 2010 7:19 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
DaggyStyle Watchman
Joined: 22 Mar 2006 Posts: 5909
|
Posted: Sat Nov 27, 2010 8:56 pm Post subject: |
|
|
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. _________________ Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Nov 27, 2010 9:15 pm Post subject: |
|
|
pactoo wrote: | Code: | libvorbis.c:(.text.unlikely+0xad): undefined reference to `vorbis_encode_setup_vbr' |
|
This is a Bug in the linking flags of mplayer, not related with gcc-4.5. |
|
Back to top |
|
|
schwarzygesetzlos Apprentice
Joined: 11 Dec 2004 Posts: 185 Location: Funeralopolis
|
Posted: Mon Nov 29, 2010 9:34 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
saellaven l33t
Joined: 23 Jul 2006 Posts: 646
|
Posted: Mon Nov 29, 2010 9:35 pm Post subject: |
|
|
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. _________________ Ryzen 3700X, Asus Prime X570-Pro, 64 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc |
|
Back to top |
|
|
Darkboy76 n00b
Joined: 28 Oct 2010 Posts: 6
|
Posted: Tue Nov 30, 2010 1:55 am Post subject: |
|
|
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! |
|
Back to top |
|
|
Darkboy76 n00b
Joined: 28 Oct 2010 Posts: 6
|
Posted: Tue Nov 30, 2010 2:15 am Post subject: |
|
|
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" |
|
Back to top |
|
|
Rion Guru
Joined: 12 Oct 2006 Posts: 383 Location: Minsk, Belarus
|
Posted: Tue Nov 30, 2010 5:13 am Post subject: |
|
|
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. _________________ rion-overlay |
|
Back to top |
|
|
saellaven l33t
Joined: 23 Jul 2006 Posts: 646
|
Posted: Wed Dec 01, 2010 8:20 am Post subject: |
|
|
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=k
Code: |
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: |
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: |
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: |
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: |
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: |
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 _________________ Ryzen 3700X, Asus Prime X570-Pro, 64 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6100 Location: Dallas area
|
Posted: Fri Dec 03, 2010 1:06 am Post subject: |
|
|
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) _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
costel78 Guru
Joined: 20 Apr 2007 Posts: 402
|
Posted: Thu Dec 16, 2010 6:49 pm Post subject: |
|
|
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. _________________ Sorry for my English. I'm still learning this language. |
|
Back to top |
|
|
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3435 Location: Gainesville, Florida
|
Posted: Thu Dec 30, 2010 12:33 am Post subject: |
|
|
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. _________________ Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11 |
|
Back to top |
|
|
rhill Retired Dev
Joined: 22 Oct 2004 Posts: 1629 Location: sk.ca
|
Posted: Thu Dec 30, 2010 2:55 am Post subject: |
|
|
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. _________________ by design, by neglect
for a fact or just for effect |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Thu Dec 30, 2010 8:38 am Post subject: |
|
|
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. |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
Posted: Thu Dec 30, 2010 1:09 pm Post subject: |
|
|
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 _________________ https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
Back to top |
|
|
dE_logics Advocate
Joined: 02 Jan 2009 Posts: 2253 Location: $TERM
|
Posted: Thu Dec 30, 2010 2:58 pm Post subject: |
|
|
Graphite works perfectly on Desktop systems (KDE + OOo). _________________ My blog |
|
Back to top |
|
|
jcTux Apprentice
Joined: 29 Dec 2009 Posts: 276 Location: Tours, France
|
Posted: Thu Dec 30, 2010 4:13 pm Post subject: |
|
|
dE_logics wrote: | Graphite works perfectly on Desktop systems (KDE + OOo). |
Same here with gnome |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6100 Location: Dallas area
|
Posted: Thu Dec 30, 2010 4:22 pm Post subject: |
|
|
I've been using graphite all along with the 4.4 series, and haven't seen any problems. _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
dE_logics Advocate
Joined: 02 Jan 2009 Posts: 2253 Location: $TERM
|
Posted: Thu Dec 30, 2010 4:58 pm Post subject: |
|
|
There's one question though.
Where's the parallelization?... I dont see any parallelization. _________________ My blog |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
Posted: Thu Dec 30, 2010 9:39 pm Post subject: |
|
|
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/gcc/Optimize-Options.html
Quote: | -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. |
Quote: | -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 ? _________________ https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
Back to top |
|
|
|