T3738 allocation figures for 32-bit

Daniel Fischer daniel.is.fischer at googlemail.com
Sat Apr 2 23:35:14 CEST 2011


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.

Cheers,
Daniel



More information about the Glasgow-haskell-users mailing list