On Mon, Mar 28, 2011 at 09:03:10PM -0400, David Fang wrote:
>> 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.
The gcc 4.4.x releases and earlier can't be built against ppl9. As I mentioned
before, the only sane approach is to update gcc44 to 4.4.5 and depreciate
building
graphite in gcc44 at the same time with --without-ppl --without-cloog. This will
free us to update gcc45 and later to ppl9 and update legacy cloog to 0.15.10
which
can be built against ppl9.
Jack
ps I am holding off on gcc46 packages until Iain Sandoe finishes the gnu lto
containerization patch so that we can re-enable lto on darwin10. There are also
a few other minor testsuite failures introduced by Xcode 4.0 that might get
fixed
as well.
>
> 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
