This is the mail archive of the gcc-testresults@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] ppc64 native target for gcc


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]