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.

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/

------------------------------------------------------------------------------
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
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to