Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Thu, Nov 17, 2011 at 07:41:21PM +, James wrote:
Now, why can't the USE descriptions be like the kernel option
descriptions and have something like what Pandu wrote included?
I added this to root's .bashrc a long time ago:
# USE flag settings hack by Ciaran McCreesh:
explainuseflag(){ sed -ne s,^\([^ ]*:\)\?$1 - ,,p $(portageq
portdir)/profiles/use.{,local.}desc; }
alias ef=explainuseflag
Then simply use the alias for a quick check to learn about all the different
uses of a given flag:
'ef graphite'
# ef graphite
Enable support for non-Roman fonts via media-gfx/graphite2
Enable support for non-Roman fonts via media-gfx/graphite2
Add support for the framework for loop optimizations based on a polyhedral
intermediate representation
Then drill down into the a specific package's use flag meaning, using the
aforementioned 'equery u' delineated by Albert.
You people seem to miss my point. I know perfectly well how to find
the USE descriptions. It is just that the USE description, in this
case (as in many others) isn't terribly useful.
Add support for the framework for loop optimizations based on a
polyhedral intermediate representation means absolutely gibberish to
me.
But if one were to add an additional one or two lines a la Pandu,
about how it is supposed to make gcc-4.5.3 use a newer method to
detect parallelism, thus (potentially) makes programs compiled by gcc
to have better multithreaded performance and perhaps even a Kernel
help page style It is mostly stable. If unsure, say Yes.
It would be ever so much more helpful for people who would like to
find out what new flags do before deciding whether or not to follow
the default recommended by the devs which are set into the profile.
(I'm not saying this type of hand holding is necessary for all flags:
enable support for non-Roman fonts via media-gfx/graphite2 is
perfectly understandable, as are most other flags about features a
user is likely to interact with. But for some of the more system
type flags (see also that python/perl flag business from the recent
months), I think the USE descriptions can stand some improvement.)
W
--
Willie W. Wong ww...@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire
et vice versa ~~~ I. Newton
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Nov 18, 2011 9:27 PM, Willie Wong ww...@math.princeton.edu wrote:
On Thu, Nov 17, 2011 at 07:41:21PM +, James wrote:
Now, why can't the USE descriptions be like the kernel option
descriptions and have something like what Pandu wrote included?
I added this to root's .bashrc a long time ago:
# USE flag settings hack by Ciaran McCreesh:
explainuseflag(){ sed -ne s,^\([^ ]*:\)\?$1 - ,,p $(portageq
portdir)/profiles/use.{,local.}desc; }
alias ef=explainuseflag
Then simply use the alias for a quick check to learn about all the
different
uses of a given flag:
'ef graphite'
# ef graphite
Enable support for non-Roman fonts via media-gfx/graphite2
Enable support for non-Roman fonts via media-gfx/graphite2
Add support for the framework for loop optimizations based on a
polyhedral
intermediate representation
Then drill down into the a specific package's use flag meaning, using
the
aforementioned 'equery u' delineated by Albert.
You people seem to miss my point. I know perfectly well how to find
the USE descriptions. It is just that the USE description, in this
case (as in many others) isn't terribly useful.
Add support for the framework for loop optimizations based on a
polyhedral intermediate representation means absolutely gibberish to
me.
But if one were to add an additional one or two lines a la Pandu,
about how it is supposed to make gcc-4.5.3 use a newer method to
detect parallelism, thus (potentially) makes programs compiled by gcc
to have better multithreaded performance and perhaps even a Kernel
help page style It is mostly stable. If unsure, say Yes.
It would be ever so much more helpful for people who would like to
find out what new flags do before deciding whether or not to follow
the default recommended by the devs which are set into the profile.
(I'm not saying this type of hand holding is necessary for all flags:
enable support for non-Roman fonts via media-gfx/graphite2 is
perfectly understandable, as are most other flags about features a
user is likely to interact with. But for some of the more system
type flags (see also that python/perl flag business from the recent
months), I think the USE descriptions can stand some improvement.)
I agree with you (and not because my name is mentioned :-P).
I got lucky with USE graphite: gcc's homepage is quite clear; a 15-minute
reading convinced me to try graphite. But there are still lots of other USE
flags that sent me on hours of goose-chase before I can enable/disable with
conviction.
I'm not sure where to put the more detailed explanations, though; perhaps a
$PN.usedesc file in the package's directory? Kind of a complement to the
.ebuild file(s).
Rgds,
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Fri, Nov 18, 2011 at 9:24 AM, Willie Wong ww...@math.princeton.edu wrote:
On Thu, Nov 17, 2011 at 07:41:21PM +, James wrote:
Now, why can't the USE descriptions be like the kernel option
descriptions and have something like what Pandu wrote included?
I added this to root's .bashrc a long time ago:
# USE flag settings hack by Ciaran McCreesh:
explainuseflag(){ sed -ne s,^\([^ ]*:\)\?$1 - ,,p $(portageq
portdir)/profiles/use.{,local.}desc; }
alias ef=explainuseflag
Then simply use the alias for a quick check to learn about all the different
uses of a given flag:
'ef graphite'
# ef graphite
Enable support for non-Roman fonts via media-gfx/graphite2
Enable support for non-Roman fonts via media-gfx/graphite2
Add support for the framework for loop optimizations based on a polyhedral
intermediate representation
Then drill down into the a specific package's use flag meaning, using the
aforementioned 'equery u' delineated by Albert.
You people seem to miss my point. I know perfectly well how to find
the USE descriptions. It is just that the USE description, in this
case (as in many others) isn't terribly useful.
Add support for the framework for loop optimizations based on a
polyhedral intermediate representation means absolutely gibberish to
me.
But if one were to add an additional one or two lines a la Pandu,
about how it is supposed to make gcc-4.5.3 use a newer method to
detect parallelism, thus (potentially) makes programs compiled by gcc
to have better multithreaded performance
Pretty sure having the word 'optimizations' is sufficient for that.
The rest, you can look up. (Sorry, I hate Just google it answers
more than most, but I think it's appropriate in this case)
IMO, USE flags should have good meaning to people familiar with the
field the package is related to. Otherwise, to keep the same terse
length, you have to dumb it down...but how far do you go?
Now, in this case, I think the use of the word 'polyhedral' in the
description is just silly; that's not going to mean anything to anyone
not intimately familiar with compiler optimizations, if not intimately
familiar with graphite itself. It should probably read something more
like Add support for the experimental 'graphite' framework for loop
optimizations.
If I read his email correctly, Pandu indicated that multithreaded
environments are an example of the impact the new optimization engine
may have. I don't think he indicated that that was its specific
function, so I wouldn't go so far as to point out multithreaded
environments in the USE flag description.
and perhaps even a Kernel
help page style It is mostly stable. If unsure, say Yes.
I'm pretty sure that's the purpose of the default state of USE flags;
if it's enabled by default, it's if unsure, say Yes. If it's
disabled by default, it's if unsure, say No.
It would be ever so much more helpful for people who would like to
find out what new flags do before deciding whether or not to follow
the default recommended by the devs which are set into the profile.
Honestly, if you don't know (and I didn't), the best option seems to
me to be to ask a similar question to what Stéphane asked. Perhaps
what does the 'graphite' USE flag for gcc add?, but go on to say, I
see the USE flag description is '...', but what's the result?
(I'm not saying this type of hand holding is necessary for all flags:
enable support for non-Roman fonts via media-gfx/graphite2 is
perfectly understandable, as are most other flags about features a
user is likely to interact with. But for some of the more system
type flags (see also that python/perl flag business from the recent
months), I think the USE descriptions can stand some improvement.)
Sure. The problem is, what constitutes an improvement for each case?
(And perhaps it'd be a good idea to file bug reports against the
ebuilds.)
IIRC, the recent 'perl' USE flag kerfluffle was about removing 'perl'
support dropping tabs in an application, when those tabs were made
possible by a particular Perl script. I doubt that was the only
perl-based extension, but the argument made at the time was that the
USE flag that affected Perl support for the app should specifically
invoke that it affected that extensions.
That's like saying that a 'perl' or 'extensions' USE flag for irssi
should talk about disabling nick highlighting, when it would also
affect named windows, presence notifications...*anything* that depends
on its Perl extensions mechanism.
--
:wq
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan pa...@poluan.info wrote: On Nov 16, 2011 2:26 PM, Michael Mol mike...@gmail.com wrote: On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon steph...@22decembre.eu wrote: On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote: And if you're adventurous, add USE graphite, reemerge gcc, and reemerge world :) what does graphite add ? Thanks for reminding me; I meant to look it up when I got home. shortcircuit:1@serenity~ Wed Nov 16 02:16 AM !501 #1 j0 ?0 $ euse -i graphite global use flags (searching: graphite) no matching entries found local use flags (searching: graphite) [snip] [- ] graphite sys-devel/gcc: Add support for the framework for loop optimizations based on a polyhedral intermediate representation So, a new, experimental optimization model and framework inside your compiler. If it's specifically for optimizing on loops, I'll venture a guess it's going to be mostly effective for graphics libraries and apps. I've got some slightly riskier educated guesses on how it works and what some numeric side effects and consequences might be, but they scare me, so I think I'll leave it to someone who actually knows more about it... I've been using USE graphite since gcc-4.5.3-r1 appeared. Upstream says that graphite is stable, feature-complete, and production-ready since 4.5.3. To fully taste the effect of graphite, I even went the torturous route of emerging gcc + libtool + binutils (in that order) twice, followed by a wholesale-rebuild of everything (emerge --emptytree), then tarballed the result to my own stage3.1 tarball to spare me the *huge* amount of time required. I've deployed 3 systems with USE graphite, and they *felt* snappier. emerge's *felt* slower, though. (no objective tests, I know). I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more time, this time specifying CFLAGS -march=native... and I just couldn't be happier with the resulting performance :-) Rgds, I might be wrong but don't you need to have the gcc's options for graphite enabled to actually make use of the graphite framework? (You might be using them but you haven't mentioned it.) //Fredric //Fredric
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Nov 18, 2011 10:41 PM, Fredric Johansson fredric.miscm...@gmail.com wrote: On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan pa...@poluan.info wrote: On Nov 16, 2011 2:26 PM, Michael Mol mike...@gmail.com wrote: On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon steph...@22decembre.eu wrote: On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote: And if you're adventurous, add USE graphite, reemerge gcc, and reemerge world :) what does graphite add ? Thanks for reminding me; I meant to look it up when I got home. shortcircuit:1@serenity~ Wed Nov 16 02:16 AM !501 #1 j0 ?0 $ euse -i graphite global use flags (searching: graphite) no matching entries found local use flags (searching: graphite) [snip] [- ] graphite sys-devel/gcc: Add support for the framework for loop optimizations based on a polyhedral intermediate representation So, a new, experimental optimization model and framework inside your compiler. If it's specifically for optimizing on loops, I'll venture a guess it's going to be mostly effective for graphics libraries and apps. I've got some slightly riskier educated guesses on how it works and what some numeric side effects and consequences might be, but they scare me, so I think I'll leave it to someone who actually knows more about it... I've been using USE graphite since gcc-4.5.3-r1 appeared. Upstream says that graphite is stable, feature-complete, and production-ready since 4.5.3. To fully taste the effect of graphite, I even went the torturous route of emerging gcc + libtool + binutils (in that order) twice, followed by a wholesale-rebuild of everything (emerge --emptytree), then tarballed the result to my own stage3.1 tarball to spare me the *huge* amount of time required. I've deployed 3 systems with USE graphite, and they *felt* snappier. emerge's *felt* slower, though. (no objective tests, I know). I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more time, this time specifying CFLAGS -march=native... and I just couldn't be happier with the resulting performance :-) Rgds, I might be wrong but don't you need to have the gcc's options for graphite enabled to actually make use of the graphite framework? (You might be using them but you haven't mentioned it.) Yes. There are some CFLAGS incantations to add to fully utilize graphite, else the optimizations would be marginal at best. That said, turning on the CFLAGS flags was a *very* involved process: 1. By default, graphite is disabled. So you can't directly turn on the graphite-related CFLAGS option. You must first enable USE graphite and re-emerge gcc (or upgrade, if you're still using gcc-4.5.3). This will pull in ppl and cloog-ppl. 2. I don't know if libtool and binutils need to be remerged, but I did it just to be safe. 3. Now that gcc has been compiled with graphite support, you can turn on the CFLAGS flags necessary to fully utilize graphite. WARNING: some flags recommended by upstream *might* make some programs run worse; be careful. (I won't have access to my servers so I can't tell you which ones exactly). 4. At this point, I want gcc itself to be optimized. So, I remerged gcc and libtool and binutils (in that order). Might be unnecessary, but I'm anal like that :-) 5. Finally, universe-remerge (emerge --emptytree). As you can see, steps 4 5 are optional. And they indeed took a *humongous* time to complete. But I am quite satisfied with the result. Everything felt snappier compared to older boxen that haven't been graphite-ed :-) Of course, YMMV. Rgds,
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Nov 18, 2011 11:35 PM, Pandu Poluan pa...@poluan.info wrote: On Nov 18, 2011 10:41 PM, Fredric Johansson fredric.miscm...@gmail.com wrote: On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan pa...@poluan.info wrote: -snip I've been using USE graphite since gcc-4.5.3-r1 appeared. Upstream says that graphite is stable, feature-complete, and production-ready since 4.5.3. To fully taste the effect of graphite, I even went the torturous route of emerging gcc + libtool + binutils (in that order) twice, followed by a wholesale-rebuild of everything (emerge --emptytree), then tarballed the result to my own stage3.1 tarball to spare me the *huge* amount of time required. I've deployed 3 systems with USE graphite, and they *felt* snappier. emerge's *felt* slower, though. (no objective tests, I know). I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more time, this time specifying CFLAGS -march=native... and I just couldn't be happier with the resulting performance :-) Rgds, I might be wrong but don't you need to have the gcc's options for graphite enabled to actually make use of the graphite framework? (You might be using them but you haven't mentioned it.) Yes. There are some CFLAGS incantations to add to fully utilize graphite, else the optimizations would be marginal at best. That said, turning on the CFLAGS flags was a *very* involved process: 1. By default, graphite is disabled. So you can't directly turn on the graphite-related CFLAGS option. You must first enable USE graphite and re-emerge gcc (or upgrade, if you're still using gcc-4.5.3). This will pull in ppl and cloog-ppl. 2. I don't know if libtool and binutils need to be remerged, but I did it just to be safe. 3. Now that gcc has been compiled with graphite support, you can turn on the CFLAGS flags necessary to fully utilize graphite. WARNING: some flags recommended by upstream *might* make some programs run worse; be careful. (I won't have access to my servers so I can't tell you which ones exactly). 4. At this point, I want gcc itself to be optimized. So, I remerged gcc and libtool and binutils (in that order). Might be unnecessary, but I'm anal like that :-) 5. Finally, universe-remerge (emerge --emptytree). As you can see, steps 4 5 are optional. And they indeed took a *humongous* time to complete. But I am quite satisfied with the result. Everything felt snappier compared to older boxen that haven't been graphite-ed :-) Of course, YMMV. Okay, found a forum thread discussing graphite and the proper CFLAGS: http://forums.gentoo.org/viewtopic-t-850087.html IIRC my CFLAGS looks very similar to the once @genstorm uses (scroll down to approximately 80% down the page). Now I never experienced *any* emerge failure, provided that I don't go higher than MAKEOPTS=-j3. Set it higher and several packages failed during compile. I don't know whose fault is that, but you've been warned ;-) Rgds,
[gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
Willie Wong wwong at math.princeton.edu writes:
It makes gcc-4.5.3 use a newer method to detect parallelism, thus
(potentially) makes programs compiled by gcc to have better multithreaded
performance.
Now, why can't the USE descriptions be like the kernel option
descriptions and have something like what Pandu wrote included?
I added this to root's .bashrc a long time ago:
# USE flag settings hack by Ciaran McCreesh:
explainuseflag(){ sed -ne s,^\([^ ]*:\)\?$1 - ,,p $(portageq
portdir)/profiles/use.{,local.}desc; }
alias ef=explainuseflag
Then simply use the alias for a quick check to learn about all the different
uses of a given flag:
'ef graphite'
# ef graphite
Enable support for non-Roman fonts via media-gfx/graphite2
Enable support for non-Roman fonts via media-gfx/graphite2
Add support for the framework for loop optimizations based on a polyhedral
intermediate representation
Then drill down into the a specific package's use flag meaning, using the
aforementioned 'equery u' delineated by Albert.
hth,
James
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Nov 16, 2011 2:15 PM, Stéphane Guedon steph...@22decembre.eu wrote: On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote: And if you're adventurous, add USE graphite, reemerge gcc, and reemerge world :) Rgds, what does graphite add ? thanks It makes gcc-4.5.3 use a newer method to detect parallelism, thus (potentially) makes programs compiled by gcc to have better multithreaded performance. Rgds,
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Wed, Nov 16, 2011 at 03:29:27PM +0700, Pandu Poluan wrote: what does graphite add ? It makes gcc-4.5.3 use a newer method to detect parallelism, thus (potentially) makes programs compiled by gcc to have better multithreaded performance. Now, why can't the USE descriptions be like the kernel option descriptions and have something like what Pandu wrote included? W -- Willie W. Wong ww...@math.princeton.edu Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire et vice versa ~~~ I. Newton
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Wed, 2011-11-16 at 08:30 -0500, Willie Wong wrote: On Wed, Nov 16, 2011 at 03:29:27PM +0700, Pandu Poluan wrote: what does graphite add ? It makes gcc-4.5.3 use a newer method to detect parallelism, thus (potentially) makes programs compiled by gcc to have better multithreaded performance. Now, why can't the USE descriptions be like the kernel option descriptions and have something like what Pandu wrote included? $ equery u gcc [ Legend : U - final flag setting for installation] [: I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-devel/gcc-4.5.3-r1: U I - - bootstrap : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used during original system bootstrapping [make stage2] - - build : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1] + + cxx : Builds support for C++ (bindings, extra libraries, code generation, ...) - - doc : Adds extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally - - fortran : Adds support for fortran (formerly f77) - - gcj : Enable building with gcj (The GNU Compiler for the Javatm Programming Language) - - graphite : Add support for the framework for loop optimizations based on a polyhedral intermediate representation - - gtk : Adds support for x11-libs/gtk+ (The GIMP Toolkit) + + lto : Add support for link-time optimizations (unsupported, use at your own risk). - - mudflap : Add support for mudflap, a pointer use checking library - - multislot : Allow for SLOTs to include minor version (3.3.4 instead of just 3.3) - - nls : Adds Native Language Support (using gettext - GNU locale utilities) - - nocxx : Old flag -- USE=cxx from now on - - nopie : Disable PIE support (NOT FOR GENERAL USE) - - nossp : Disable SSP support (NOT FOR GENERAL USE) + + nptl : Enable support for Native POSIX Threads Library, the new threading module (requires linux-2.6 or better usually) - - objc : Build support for the Objective C code language - - objc++: Build support for the Objective C++ language - - objc-gc : Build support for the Objective C code language Garbage Collector - - openmp: Build support for the OpenMP (support parallel computing), requires =sys-devel/gcc-4.2 built with USE=openmp - - test : Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore - - vanilla : Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Nov 16, 2011 2:26 PM, Michael Mol mike...@gmail.com wrote: On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon steph...@22decembre.eu wrote: On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote: And if you're adventurous, add USE graphite, reemerge gcc, and reemerge world :) what does graphite add ? Thanks for reminding me; I meant to look it up when I got home. shortcircuit:1@serenity~ Wed Nov 16 02:16 AM !501 #1 j0 ?0 $ euse -i graphite global use flags (searching: graphite) no matching entries found local use flags (searching: graphite) [snip] [- ] graphite sys-devel/gcc: Add support for the framework for loop optimizations based on a polyhedral intermediate representation So, a new, experimental optimization model and framework inside your compiler. If it's specifically for optimizing on loops, I'll venture a guess it's going to be mostly effective for graphics libraries and apps. I've got some slightly riskier educated guesses on how it works and what some numeric side effects and consequences might be, but they scare me, so I think I'll leave it to someone who actually knows more about it... I've been using USE graphite since gcc-4.5.3-r1 appeared. Upstream says that graphite is stable, feature-complete, and production-ready since 4.5.3. To fully taste the effect of graphite, I even went the torturous route of emerging gcc + libtool + binutils (in that order) twice, followed by a wholesale-rebuild of everything (emerge --emptytree), then tarballed the result to my own stage3.1 tarball to spare me the *huge* amount of time required. I've deployed 3 systems with USE graphite, and they *felt* snappier. emerge's *felt* slower, though. (no objective tests, I know). I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more time, this time specifying CFLAGS -march=native... and I just couldn't be happier with the resulting performance :-) Rgds, Rgds,
[gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On 11/15/2011 08:58 PM, Jarry wrote: Hi, today I upgraded gcc from 4.4.5 to the last stable version 4.5.3-r1. [...] But at the and I noticed gcc 4.4 has not been unmerged and my world file is somehow larger. To my surprise, it contains these lines: sys-devel/gcc sys-devel/gcc:4.4 I did full backup before, so I compared world-file before and after gcc-upgrade just to find out, these two lines have been really inserted now, during gcc-upgrade. And my question is: what does it mean? Does my system need now both gcc 4.4 and 4.5? Why is actually gcc in world-file, when it is part of system? The old GCC version does not get removed. This is a good thing just in case the new one doesn't work for some reason. If it works OK, you can manually unmerge the old version: emerge -aC gcc:4.4 Before doing that, however, make sure the new one has been activated with gcc-config and verify that it works by building some random package.
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Nov 16, 2011 8:00 AM, Nikos Chantziaras rea...@arcor.de wrote: On 11/15/2011 08:58 PM, Jarry wrote: Hi, today I upgraded gcc from 4.4.5 to the last stable version 4.5.3-r1. [...] But at the and I noticed gcc 4.4 has not been unmerged and my world file is somehow larger. To my surprise, it contains these lines: sys-devel/gcc sys-devel/gcc:4.4 I did full backup before, so I compared world-file before and after gcc-upgrade just to find out, these two lines have been really inserted now, during gcc-upgrade. And my question is: what does it mean? Does my system need now both gcc 4.4 and 4.5? Why is actually gcc in world-file, when it is part of system? The old GCC version does not get removed. This is a good thing just in case the new one doesn't work for some reason. If it works OK, you can manually unmerge the old version: emerge -aC gcc:4.4 Before doing that, however, make sure the new one has been activated with gcc-config and verify that it works by building some random package. And if you're adventurous, add USE graphite, reemerge gcc, and reemerge world :) Rgds,
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote: On Nov 16, 2011 8:00 AM, Nikos Chantziaras rea...@arcor.de wrote: On 11/15/2011 08:58 PM, Jarry wrote: Hi, today I upgraded gcc from 4.4.5 to the last stable version 4.5.3-r1. [...] But at the and I noticed gcc 4.4 has not been unmerged and my world file is somehow larger. To my surprise, it contains these lines: sys-devel/gcc sys-devel/gcc:4.4 I did full backup before, so I compared world-file before and after gcc-upgrade just to find out, these two lines have been really inserted now, during gcc-upgrade. And my question is: what does it mean? Does my system need now both gcc 4.4 and 4.5? Why is actually gcc in world-file, when it is part of system? The old GCC version does not get removed. This is a good thing just in case the new one doesn't work for some reason. If it works OK, you can manually unmerge the old version: emerge -aC gcc:4.4 Before doing that, however, make sure the new one has been activated with gcc-config and verify that it works by building some random package. And if you're adventurous, add USE graphite, reemerge gcc, and reemerge world :) Rgds, what does graphite add ? thanks -- Stéphane Guedon page web : http://www.22decembre.eu/ carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Wed, Nov 16, 2011 at 02:11, Stéphane Guedon steph...@22decembre.eu wrote: On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote: On Nov 16, 2011 8:00 AM, Nikos Chantziaras rea...@arcor.de wrote: On 11/15/2011 08:58 PM, Jarry wrote: Hi, today I upgraded gcc from 4.4.5 to the last stable version 4.5.3-r1. [...] But at the and I noticed gcc 4.4 has not been unmerged and my world file is somehow larger. To my surprise, it contains these lines: sys-devel/gcc sys-devel/gcc:4.4 I did full backup before, so I compared world-file before and after gcc-upgrade just to find out, these two lines have been really inserted now, during gcc-upgrade. And my question is: what does it mean? Does my system need now both gcc 4.4 and 4.5? Why is actually gcc in world-file, when it is part of system? The old GCC version does not get removed. This is a good thing just in case the new one doesn't work for some reason. If it works OK, you can manually unmerge the old version: emerge -aC gcc:4.4 Before doing that, however, make sure the new one has been activated with gcc-config and verify that it works by building some random package. And if you're adventurous, add USE graphite, reemerge gcc, and reemerge world :) Rgds, what does graphite add ? andrey@robot9000 /tmp $ grep graphite /usr/portage/profiles/use*.desc /usr/portage/profiles/use.local.desc:app-office/libreoffice:graphite - Enable support for non-Roman fonts via media-gfx/graphite2 /usr/portage/profiles/use.local.desc:app-portage/eix:strong-optimization - Adds several more agressive CXXFLAGS/LDFLAGS for optimization like graphite (if available). May cause trouble with some buggy compiler versions. Absense of this USE flag does not strip user's *FLAGS /usr/portage/profiles/use.local.desc:media-libs/harfbuzz:graphite - Enable support for non-Roman fonts via media-gfx/graphite2 /usr/portage/profiles/use.local.desc:media-libs/silgraphite:pango - Enables the pango-graphite pango module. /usr/portage/profiles/use.local.desc:sys-devel/gcc:graphite - Add support for the framework for loop optimizations based on a polyhedral intermediate representation
Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon steph...@22decembre.eu wrote: On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote: And if you're adventurous, add USE graphite, reemerge gcc, and reemerge world :) what does graphite add ? Thanks for reminding me; I meant to look it up when I got home. shortcircuit:1@serenity~ Wed Nov 16 02:16 AM !501 #1 j0 ?0 $ euse -i graphite global use flags (searching: graphite) no matching entries found local use flags (searching: graphite) [snip] [- ] graphite sys-devel/gcc: Add support for the framework for loop optimizations based on a polyhedral intermediate representation So, a new, experimental optimization model and framework inside your compiler. If it's specifically for optimizing on loops, I'll venture a guess it's going to be mostly effective for graphics libraries and apps. I've got some slightly riskier educated guesses on how it works and what some numeric side effects and consequences might be, but they scare me, so I think I'll leave it to someone who actually knows more about it... -- :wq
