> On Wed, Mar 23, 2011 at 12:36:44PM -0400, David Fang wrote: >>> On Wed, Mar 23, 2011 at 10:28:04AM -0400, David Fang wrote: >>>>> It was originally thought that the failure was due to 10.5 using >>>>> gcc-4.0, but the test still fails the same way with revision -4 which >>>>> forces gcc-4.2. >>>>> >>>>> For the record, ppl9-0.11.2-1 does pass tests OK. Would it make sense >>>>> to update gcc-4(4/5) to use ppl9? >>>> >>>> Jack and I recently discussed a strategy for upgrading the >>>> gmp/mpfr/mpc/ppl/cloog dependencies offline. Jack, care to summarize? >>>> >>>> Fang >>> >>> Currently mpc and ppl9 are built against ppl9. The gcc44-4.4.5 package >>> however is incompatible with ppl9 and must be built against ppl for its >>> graphite >>> support. The gcc45-4.5.3 (unreleased) package can be built against ppl9 but >>> requires the legacy cloog-ppl which is currently built against ppl. So we >>> have >>> two options to complete the migration to gmp5/libmpfr4... >>> >>> 1) Patch ppl so it can be built against gmp5 and rebuild cloog against gmp5 >>> as well as gcc44-4.4.5 and gcc45-4.5.3 against gmp5/libmpfr4. >> >> So ppl in my experimental tree is built against gmp5 and exhibits the >> exact same test failures that people are seeing. [Need to report this >> upstream to ppl-devel.] If you accept (?) that this new ppl-gmp5 is no >> worse than ppl-gmp4, then 1) is feasible.
Following up on my end: I've reported the 0.10.2 test failure to ppl-devel, also observing that gmp vs gmp5 makes no difference in the test results. Since ppl development seems focused on 0.11+, I kind of doubt any fixes would come to 0.10. Jack, would it be acceptable for me to bump ppl to use gmp5 (as-is, in my experimental tree)? Along with it, older gcc4x's would need to inherit ppl's updated dependencies for coherence. AFAICS, gcc4x is the only anti-dep of ppl. Fang > I'm agnostic on the issue really. Hopefully, once I have final patches > in hand from gcc-4_6-branch to fix lto against Xcode 3.2.6/4.0's > assembler, we can get gcc46 in fink and push for a migration to it. The > gcc46 package will have many advantages including 1) usable lto, 2) > usable objc/obj-c++ at -m64, 3) core2 tuning as default and 4) excellent > graphite performance (ie no vectorization loss). > Jack ps I posted this to the MacPorts list already. We had > to disable lto in gcc 4.6.0 on darwin10 due to an unfortunate change by > Apple in their assembler for Xcode 3.2.6 and 4.0 (which was self > inflicted since it came from one of my radar reports). The issue was > that lto requires an unlimited number of sections in a mach-o file. The > mach-o spec is silent on that except for sections with relocations which > are limited to 255. We found that by placing the GNU LTO sections at the > end of the mach-o file we could avoid any issues with that limitation. > However in Xcode 3.2.6/4.0, a hard limit of 255 sections of any time was > introduced in the assembler which makes lto unusable for larger projects > and fails parts of the lto testsuite. We have a work in progress patch > in hand but it will likely be several more weeks before it goes into gcc > trunk and gcc-4_6-branch. I plan on delaying the gcc46 package until I > can back port that and any other fixes for Xcode 4.0. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48096 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 > >> >>> 2) Disable graphite in gcc44-4.4.5 using --without-ppl --without-cloog >>> and rebuild cloog against ppl9/gmp5 and gcc45-4.5.3 against >>> ppl9/gmp5/libmpfr4/cloog. >>> >>> I favor the second option myself since graphite is barely usable in gcc44. >>> In >>> gcc45, graphite works reasonably well but it won't be until gcc46 that >>> graphite >>> never misses vertorization opportunities. >>> Jack >> >> >> >> David Fang >> http://www.csl.cornell.edu/~fang/ >> http://www.achronix.com/ > David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/ ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
