T3738 allocation figures for 32-bit

Simon Marlow marlowsd at gmail.com
Thu Apr 7 11:18:40 CEST 2011


On 02/04/2011 22:35, Daniel Fischer wrote:
> Hit send too soon:
>
>> Apparently the allocation figures drastically vary by arch and OS, it
>> would probably be necessary to test on several such and be more
>> generous with the limits.
>
> The same holds for other tests, of course. I had unexpected failures due to
> allocation figures also for space_leak001, T4801 and T3064.
>
> space_leak001 failing with
> bytes allocated 9328745840 is more than maximum allowed 9100000000
> (allocation figures slightly vary among the different ways)
> which is close enough to not worry about, considering the minimum allowed
> is 9050000000.
>
> T4801 with
> peak_megabytes_allocated 41 is less than minimum allowed 70
> If this is because you have improved GHC, please
> update the test so that GHC doesn't regress again
> bytes allocated 358364424 is more than maximum allowed 80000000
> max_bytes_used 17406288 is more than maximum allowed 4000000
>
> and T3064 with
> peak_megabytes_allocated 9 is less than minimum allowed 14
> If this is because you have improved GHC, please
> update the test so that GHC doesn't regress again
> bytes allocated 69984336 is less than minimum allowed 150000000
> If this is because you have improved GHC, please
> update the test so that GHC doesn't regress again
> max_bytes_used 3368652 is less than minimum allowed 6000000
> If this is because you have improved GHC, please
> update the test so that GHC doesn't regress again
>
> The figures in HEAD's testsuite are again close to what I get, while the
> 7.0.3 figures are way off.

The testsuite wasn't fully updated in the 7.0 branch, so there are a few 
failures there.  They don't indicate any actual problems as far as I'm 
aware.  Next time we'll make sure to clean up any failures in the branch 
before releasing.

Cheers,
	Simon



More information about the Glasgow-haskell-users mailing list