Phil, Thank you for testing this and reporting the problem. It actually turned out to be a bug in the compact 32-bit version. The compilation happened to allocate an array of a particular size that was wrongly copied in the minor garbage collection resulting in a crash either in the GC itself or later on. I've pushed a fix to master and I'm copying this message to the mailing list since this represents a change that others may need to be aware of.
Regards, David
On 03/03/2019 00:27, Phil Clayton wrote:
David,
I have been trying out the latest candidate for Poly/ML 5.8 (c3a630f) with --enable-compact32bit and have not found any issues.? I was pleased to see a space saving with saved state files, which appear to be around 62-68% of their size compared with not using compact32bit.? I haven't measured any other performance though.
In one obscure respect, compact32bit fails where the full 64 bit version does not: the exponential blow-up described in this example from a few years ago now fails to compile code where the full 64 bit version would take around 8 s on my machine.? Presumably some internal limit is hit sooner with 32 bits.? I have seen two different failure messages as shown in the following log.
Regards, Phil