[commit: testsuite] master: Fix remaining test failures on OS X/x86_64 (bea1187)

[Manuel M T Chakravarty]

Simon Marlow:
> On 05/08/2011 04:07, Manuel Chakravarty wrote:
>> Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
>> 
>> On branch  : master
>> 
>> http://hackage.haskell.org/trac/ghc/changeset/bea1187888f3a558e1e135e4d8ad12698c2f7d90
>> 
>>> ---------------------------------------------------------------
>> 
>> commit bea1187888f3a558e1e135e4d8ad12698c2f7d90
>> Author: Manuel M T Chakravarty<chak at cse.unsw.edu.au>
>> Date:   Fri Aug 5 13:01:05 2011 +1000
>> 
>>     Fix remaining test failures on OS X/x86_64
>> 
>>     * Adapted the limits of two performance tests for OS X/x86_64
> 
> Some of these limits had to be bumped by 10% or more.  Can you think of a reason why GHC on OS X might need to allocate 10% more memory than Linux?  It seems suspicious to me at least.  Was this with the standard validate settings?

Yes, I used standard validate settings.  Judging by the timestamps, the Linux numbers are from a while ago.  They may be closer to the (old) limit than they used to be when the limits were set.

Otherwise, I have no idea where the difference comes from.  However, as far as I can remember, the tests never passed on OS X/x86_64, so I don't think it is a recent change.

Are there any differences in the RTS between OS X and Linux that could explain the difference?

Manuel


>>> ---------------------------------------------------------------
>> 
>>  tests/ghci/linking/Makefile |    2 ++
>>  tests/perf/compiler/all.T   |   11 +++++++----
>>  2 files changed, 9 insertions(+), 4 deletions(-)
>> 
>> diff --git a/tests/ghci/linking/Makefile b/tests/ghci/linking/Makefile
>> index 60d60e6..0f5b1ed 100644
>> --- a/tests/ghci/linking/Makefile
>> +++ b/tests/ghci/linking/Makefile
>> @@ -20,6 +20,8 @@ ghcilink001 :
>> 
>>  ifeq "$(WINDOWS)" "YES"
>>  DLL = $1.dll
>> +else ifeq "$(DARWIN)" "YES"
>> +DLL = lib$1.dylib
>>  else
>>  DLL = lib$1.so
>>  endif
>> diff --git a/tests/perf/compiler/all.T b/tests/perf/compiler/all.T
>> index 80b5076..8d20d36 100644
>> --- a/tests/perf/compiler/all.T
>> +++ b/tests/perf/compiler/all.T
>> @@ -27,10 +27,11 @@ test('T1969',
>>                                      #                 221667908 (x86/OS X)
>>        if_wordsize(64,
>>            compiler_stats_num_field('bytes allocated', 420000000,
>> -                                                      550000000)),
>> +                                                      580000000)),
>>                                      # 17/11/2009:     434,845,560 (amd64/Linux)
>>                                      # 08/12/2009:     459,776,680 (amd64/Linux)
>>                                      # 17/05/2010:     519,377,728 (amd64/Linux)
>> +                                    # 05/08/2011:     561,382,568 (amd64/OS X)
>>        only_ways(['normal'])
>>        ],
>>       compile,
>> @@ -79,16 +80,18 @@ test('T4801',
>>        if_wordsize(32,
>>            compiler_stats_num_field('peak_megabytes_allocated', 30, 40)),
>>        # expected value: 66 (amd64/Linux):
>> +      # expected value: 72 (amd64/OS X):
>>        if_wordsize(64,
>> -          compiler_stats_num_field('peak_megabytes_allocated', 55, 70)),
>> +          compiler_stats_num_field('peak_megabytes_allocated', 55, 75)),
>>        # expected value: 353463196 (x86/Windows)
>>        if_wordsize(32,
>>            compiler_stats_num_field('bytes allocated', 330000000,
>>                                                        370000000)),
>> -      # expected value: 145038576 (amd64/Linux):
>> +      # expected value: 145038576 (amd64/Linux):  ?? makes no sense -=chak
>> +      # expected value: 813714032 (amd64/OS X):
>>        if_wordsize(64,
>>            compiler_stats_num_field('bytes allocated', 600000000,
>> -                                                      750000000)),
>> +                                                      850000000)),
>>        # expected value: 14181360 (x86/Linux)
>>        if_wordsize(32,
>>            compiler_stats_num_field('max_bytes_used', 11000000,
>> 
>> 
>> 
>> _______________________________________________
>> Cvs-ghc mailing list
>> Cvs-ghc at haskell.org
>> http://www.haskell.org/mailman/listinfo/cvs-ghc
>