[patch] ppc64 native target for gcc

[Jack Howarth]

Brad,
   Did you verify that your gmp/mpfr builds really pass their make check.
What worked for me was the gmp-64bit package from fink 10.4 unstable and the
libmpfr1-64bit packaging that I created...

http://sourceforge.net/tracker/index.php?func=detail&aid=1594782&group_id=17203&atid=414256

setenv gcc "gcc -m64"
setenv CFLAGS -I/sw/include
setenv LDFLAGS -L/sw/lib64

../gcc/configure   --prefix=/Users/howarth/work/gcc42 --host=powerpc64-apple-darwin8 --target=powerpc64-apple-darwin8 --disable-multilib --with-gmp=/sw --with-mpfr=/sw --enable-languages=c,c++,fortran

Make sure you install the build in your prefix before you run make check.
This should give you something like...

                === g++ Summary ===

# of expected passes            13014
# of unexpected failures        26
# of expected failures          67
# of unsupported tests          131
/Users/howarth/darwin_obj/gcc/testsuite/g++/../../g++  version 4.2.0 20061110 (prerelease)

                === gcc Summary ===

# of expected passes            41955
# of unexpected failures        37
# of unexpected successes       3
# of expected failures          106
# of untested testcases         28
# of unsupported tests          516
/Users/howarth/darwin_obj/gcc/xgcc  version 4.2.0 20061110 (prerelease)

                === gfortran Summary ===

# of expected passes            14829
# of unexpected failures        32
# of expected failures          7
# of unsupported tests          41
/Users/howarth/darwin_64bit/gcc/testsuite/gfortran/../../gfortran  version 4.2.0 20061110 (prerelease)

which is very close to what I see with -m64 on a normal build.

On Sun, Nov 12, 2006 at 05:33:21PM -0500, Bradley Lucier wrote:
> Regarding my earlier comment:
> 
> >I've just put my mainline results at
> >
> >http://www.math.purdue.edu/~lucier/gcc/test-results/ 
> >4_3_0_2006-11-11.gz
> >
> >because it was too large to be accepted by gcc-testresults.
> 
> I don't seem to be getting very good test results:
> 
> 		=== g++ Summary ===
> 
> # of expected passes		13019
> # of unexpected failures	27
> # of expected failures		67
> # of unsupported tests		132
> 
> 		=== gcc Summary ===
> 
> # of expected passes		42471
> # of unexpected failures	44
> # of unexpected successes	1
> # of expected failures		108
> # of unresolved testcases	1
> # of untested testcases		28
> # of unsupported tests		516
> 
> 		=== gfortran Summary ===
> 
> # of expected passes		9958
> # of unexpected failures	4925
> # of expected failures		7
> # of unsupported tests		113
> 
> 		=== objc Summary ===
> 
> # of expected passes		1654
> # of unexpected failures	118
> # of expected failures		17
> # of unresolved testcases	1
> # of unsupported tests		2
> 
> 		=== libgomp Summary ===
> 
> # of expected passes		734
> # of unexpected failures	590
> # of unsupported tests		111
> 
> 		=== libstdc++ Summary ===
> 
> # of expected passes		3806
> # of unexpected failures	11
> # of unexpected successes	2
> # of expected failures		14
> # of unsupported tests		318
> 
> Are these what you expected?
> 
> It does allow me to compile the things I couldn't before---mainline  
> used about 4GB of memory and took about 15 minutes on my 2GHz G5.   
> (That was with --enable-checking on the mainline.)
> 
> The only anomalous behavior I saw was a string of
> 
> cc1(5813) malloc: ***  Deallocation of a pointer not malloced:  
> 0x20e000000; This could be a double free(), or free() called with the  
> middle of an allocated block; Try setting environment variable  
> MallocHelp to see tools to help debug
> cc1(5813) malloc: ***  Deallocation of a pointer not malloced:  
> 0x20c000000; This could be a double free(), or free() called with the  
> middle of an allocated block; Try setting environment variable  
> MallocHelp to see tools to help debug
> cc1(5813) malloc: ***  Deallocation of a pointer not malloced:  
> 0x20a000000; This could be a double free(), or free() called with the  
> middle of an allocated block; Try setting environment variable  
> MallocHelp to see tools to help debug
> ...
> 
> when the compile of the largest file finished.
> 
> Brad