Summary: | sys-devel/gcc-4.4.0 released | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Arfrever Frehtes Taifersar Arahesis (RETIRED) <arfrever> |
Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | alexxy, auke, bernhard.hartleb, chr.paccolat, crurik, dschridde+gentoobugs, electricityispower, gentoo.cart9, genzilla, jrmalaq, kanelxake, kyron, mario.fetka, Martin.Jansa, orzel, patrizio.bassi, tdalman |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Arfrever Frehtes Taifersar Arahesis (RETIRED)
2009-04-23 21:36:22 UTC
I have an ebuild for this locally. I should have something in a day or so that I'll add to the tree and p.mask. are we enabling graphite? (In reply to comment #2) > are we enabling graphite? > this will be at least intresting. I can test it on my systems Like quiete everyone I would also be pleased to try graphite, but I was lost in http://gcc.gnu.org/wiki/Graphite which isn't that clear : are dev-libs/ppl-0.10.2 and dev-libs/cloog-ppl-0.15.3 enough up to date for gcc-4.4.0 with graphite ? (In reply to comment #1) > I have an ebuild for this locally. I should have something in a day or so that > I'll add to the tree and p.mask. > and where is gcc-4.4.0? what is the current status? (In reply to comment #5) > and where is gcc-4.4.0? > what is the current status? > Sorry, got sidetracked. I was trying to get a new version of ecj on the upstream mirrors. The first ebuild isn't going to have the graphite stuff in it yet. I'm not sure if we should add that unconditionally or via a use flag. Any opinions on that? I'll add the initial ebuild I have to the tree later tonight when I get home. (In reply to comment #6) > Sorry, got sidetracked. I was trying to get a new version of ecj on the > upstream mirrors. > > The first ebuild isn't going to have the graphite stuff in it yet. I'm not > sure if we should add that unconditionally or via a use flag. Any opinions on > that? > > I'll add the initial ebuild I have to the tree later tonight when I get home. > I think better to have graphite via use flag since its realy very experimental stuff like openmp 1 vote for graphite via USE flag. I use bleeding edge GCC for HPC so I really am interested in having all the new features accessible to gage the actual availability of the said features. i think it needs to be a USE flag. we shouldn't force people to install a bunch of speciality math libraries just to use the compiler. the gcc-4.4.1_pre9999 ebuild in the gcc-porting overlay has had graphite support for a few months now. i don't use it myself but i have a few users that have tested it extensively (and found a few upstream bugs in the process ;)). in short we'll need to get >=dev-libs/ppl-0.10 and >=dev-libs/cloog-ppl-0.15 keyworded on all archs, which i can take care of, and then just $(use_with graphite ppl) $(use_with graphite cloog) (In reply to comment #9) > in short we'll need to get >=dev-libs/ppl-0.10 and >=dev-libs/cloog-ppl-0.15 > keyworded on all archs, which i can take care of, and then just > $(use_with graphite ppl) > $(use_with graphite cloog) I agree, graphite support should definitely be a USE flag. however, may I ask, as a non-developer, why we wouldn't use EAPI 2's USE dependencies? he he =) gcc-4.4.0 added one issue man gcc shows nothing (In reply to comment #11) > one issue > man gcc shows nothing The issue is known, a patch exists: bug #256608 Added graphite support as well (graphite use flag). Open a new bug if things blow up for you. Have fun testing. |