Hi David, I’ve tested on amd64, armel and armhf, and all the tests pass. Going back to the streamNo change, are all the warnings just from assigning streamNo to local unsigned variables leading to a potential truncation? It seems GCC oddly doesn’t enable -Wconversion by default with -Wall (or even -Wextra), so I missed this, although of course you would need to have 2^32 streams open to run into any issues with this (and that’s not a regression given that streamNo used to be unsigned itself).
Regards, James > On 26 Jan 2016, at 16:50, David Matthews <[email protected]> > wrote: > > 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 >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
