Hi Jerry, Thanks for looking at this. I've tried building on the ARM using those flags and it seems that converting a double (Real.real) to a float (Real32.real) ignores the rounding setting and always uses the nearest.
Real32.fromLarge IEEEReal.TO_NEAREST mp == m32;
val it = true: bool
Real32.fromLarge IEEEReal.TO_ZERO mp == m32;
val it = true: bool
Real32.fromLarge IEEEReal.TO_POSINF mp == m32;
val it = true: bool
Real32.fromLarge IEEEReal.TO_NEGINF mp == m32;
val it = true: bool
I don't know what to do about that. The test is useful on other platforms so it would be a shame to remove it.
So the s390x is big-endian? I don't have access to any big-endian hardware but I managed to find an image for a big-endian Mips machine under Qemu and confirm that there was a problem. Actually finding out what the problem is looks like quite a bit of work especially as it takes a long time to run anything.
Regards, David
On 27/03/2019 02:50, Jerry James wrote:
On Mon, Mar 25, 2019 at 10:00 AM David Matthews <David.Matthews at prolingua.co.uk> wrote:
Hi, Thanks for looking at this. The focus before the release of 5.8 was on the X86 and in particular the 32/64 version. The interpreted version wasn't really tested to the same extent. Since then I've fixed a couple of bugs that affected the interpreted version when I tested it on ARM and Mips development boards. Once of these caused a segfault and the other affected some of the Real32.real arithmetic. These fixed have been pushed to git master and I'm planning to add them to the fixes-5.8 branch.
Sure, probably nearly all polyml installations are x86_64, so it makes sense to focus your efforts there.
It would be very helpful if you could rerun your tests with master so I know whether the bugs you've encountered have actually been fixed.
I just did a test build. The logs will be available here for a few days:
https://koji.fedoraproject.org/koji/taskinfo?taskID=33786018
Don't be fooled that it is still called version 5.8. I swapped out the 5.8 tarball for my own tarball made from git master. Both the s390x endianness issue and the ARM floating point issue appear to still be present in master. Note that Fedora uses these flags when building for 32-bit ARM:
-march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard
Regards,