I've applied your patch rather than use the whole pull request. I've
also fixed the problem with evaluating real operations on constants at
compile-time so the tests again work. There's a problem with the test
in Visual C Windows 64-bit. I think it's only setting the rounding mode
for the SSE2 floating point unit. Currently Poly/ML uses the legacy x87
floating point unit even in 64-bit mode. That's on my TODO list.
If you can check that it all works on the machines you were testing that
would be helpful.
Regards,
David
On 26/01/2016 14:17, James Clarke wrote:
Hi David (cc’d mailing list back in),
Of course "bytes 00 00 00 00 00 followed by 00 00 00/01/02" is meant to be "bytes 00
00 00 00 followed by 00 00 00 00/01/02".
Regards,
James
On 26 Jan 2016, at 14:13, James Clarke <[email protected]> wrote:
Hi David,
I initially tried to do something like you did (I had val supported =
(setRoundingMode TO_NEAREST; true) handle Fail _ => false or similar, and
wrapped the whole thing in one if succeeded let ... in () end else ()), but ran
into issues where it was failing on x86; I imagine that was because the compiler
was performing the operations on constants at compile-time like you said, as it
didn’t seem to be following the rounding mode.
Yes, when I was making the S/390 port, all the streams had streamNo 0 (bytes 00
00 00 00 00 followed by 00 00 00/01/02), so it thought fd 1 and 2 had closed
early, causing polyimport to exit with status code 1 without printing anything.
The same thing was happening on big-endian 64-bit PPC.
Regards,
James
On 26 Jan 2016, at 14:05, David Matthews <[email protected]> wrote:
Hi James,
I was trying to separate out the change to the tests from the change to
reals.cpp. I don't like the idea of changing the test driver and I'd prefer to
alter the test itself to deal correctly with the fact that setRoundingMode may
raise an exception. I'm aware that it doesn't do that at the moment and it
will need your patch or something like it.
You're right that the change I've made is wrong and will also catch the exception raised
in "check". Fixing that has, though, shown up a different bug where the
compiler is trying to perform the real operations on constants at compile-time before the
rounding mode has been set. That didn't show up when they were all top-level expressions.
On your other patch: Was there an issue with the "streamNo" that caused you to
make that change? I can see the possibility that unsigned might be different from
POLYUNSIGNED (it certainly is on Windows/X64) and that the effect could be to set the
wrong part of a word. I'll have to make some further changes because there are now
warnings on Windows/64-bit.
Regards,
David
On 26/01/2016 12:43, James Clarke wrote:
Hi,
I notice you committed
https://github.com/polyml/polyml/commit/891e8122dcca36f9c2e9eea5a3eca7cf5de9f191.
However, as it stands, on armel the calls do not raise an exception like
https://github.com/polyml/polyml/pull/16, which could be misleading for the
user, as as far as they are aware setting the mode has succeeded (and getting
the mode may return the new mode). Also, unless I’m mistaken, you have
effectively just completely disabled that test on every platform, as any
failure will be caught.
Regards,
James
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
