Great, thanks! And yes, the ABI bump annoyingly slows things down a little...
Regards,
James
> On 26 Jan 2016, at 10:26, Gianfranco Costamagna
> <costamagnagianfra...@yahoo.it> wrote:
>
> Hi, sponsoring in a few moments.
>
> note: it will go through binNEW queue :)
>
> cheers,
>
> G.
>
>
>
>
>
> Il Martedì 26 Gennaio 2016 10:12, James Clarke <jrt...@jrtc27.com> ha scritto:
> Hi Gianfranco,
> I have uploaded 5.6-1 to mentors; could you please review it?
>
> Thanks,
> James
>
>
>> On 25 Jan 2016, at 21:08, James Clarke <jrt...@jrtc27.com> wrote:
>>
>> Ok, hopefully my s390x build will finish soon and I can then upload 5.6-1 to
>> mentors including S/390 support (and thus, barring any regressions, have
>> support for every release architecture!).
>>
>> Thanks,
>> James
>>
>>> On 25 Jan 2016, at 21:07, Gianfranco Costamagna
>>> <costamagnagianfra...@yahoo.it> wrote:
>>>
>>> Again, I think I'll trust your dsc file, but unfortunately I need to prior
>>> have one to test and double check/report back in case of issues.
>>>
>>> So if you have a dsc, please share, I think it will be fine!
>>>
>>> Cheers,
>>> G.
>>>
>>> Sent from Yahoo Mail on Android
>>>
>>> On Mon, 25 Jan, 2016 at 22:00, James Clarke
>>> <jrt...@jrtc27.com> wrote:
>>> Hi Gianfranco,
>>> For platforms where fe{g,s}etround (and other equivalent functions for
>>> different platforms), the implementation of {g,s}etRoundingMode is to raise
>>> an exception saying “Unable to set floating point rounding control” which
>>> can be either be caught in the user’s ML code or left to propagate up to
>>> the top level leading to an uncaught exception.
>>>
>>> My proposal is this:
>>>
>>> * On systems with __SOFTFP__ defined, raise an exception as above stating
>>> that {g,s}etRoundingMode is not supported for software-based floating point
>>> implementations.
>>> * Modify the test case to catch this exception, in effect skipping it on
>>> armel.
>>>
>>> What do you think?
>>>
>>> Upstream has also just released 5.6 (it’s been on the horizon for a month
>>> but no date was given; if only they could have done so yesterday!). I have
>>> already updated locally and got it working for amd64. I also potentially
>>> have a working s390x patch (had to fix some assumptions in the code that
>>> break on a 64-bit big-endian architecture); just waiting for it to finish
>>> building in the emulator. Assuming my s390x patch works and you approve of
>>> my armel proposal, I will go ahead and add those to the package and then
>>> upload 5.6-1 to mentors.
>>>
>>> Thanks,
>>> James
>>>
>>>> On 25 Jan 2016, at 20:49, Gianfranco Costamagna
>>>> <costamagnagianfra...@yahoo.it> wrote:
>>>>
>>>> Hi, you are the maintainer, so it should be only up to you to make the
>>>> final decision about architectures to support.
>>>> You need to understand the use case of this particular test, what is the
>>>> probability to hit this with real code running on an armel machine? In
>>>> fact since this has almost never worked on armel it wouldn't be a real
>>>> regression, but I'll leave to you the decision about the topic, and to me
>>>> eventually to complain if I don't like your solution (and you are free to
>>>> find a sponsor that likes better your approach) :-)
>>>>
>>>> Just jocking, I always found a common agreement prior to sponsor a package
>>>> :)
>>>>
>>>> So, at the end, please tell me your solution, or even better give me a dsc
>>>> to sponsor :)
>>>>
>>>> If the bug is in glibc seems rather good to report it and disable the test.
>>>> (Remember to reenable it if glibc gets fixed)
>>>>
>>>> If it is by design broken on armel you might want to add a pointer
>>>> somewhere for the user, or a note in the manpage.
>>>>
>>>> But again you are the maintainer, I trust your opinion after sponsoring 4
>>>> times already the package!
>>>>
>>>> Cheers,
>>>>
>>>> Gianfranco
>>>>
>>>> Sent from Yahoo Mail on Android
>>>>
>>>> On Mon, 25 Jan, 2016 at 20:55, James Clarke
>>>> <jrt...@jrtc27.com> wrote:
>>>> Hi Gianfranco,
>>>>
>>>>
>>>>>> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround
>>>>>> are. Should I get in touch with debian-arm?
>>>>>
>>>>> probably yes, even if I don't care there are much armel porters there...
>>>>>
>>>>> You might end up in asking ftpmaster to remove the armel binary.
>>>>
>>>>
>>>> Ok, I think I’ve worked out what’s going on. The software floating-point
>>>> implementation seems to only support FE_NEAREST. On an ARM device without
>>>> an FPU, fe{g,s}etround are not supported and should return 1. However, if
>>>> you are running on an ARM device which has an FPU, fe{g,s}etround will
>>>> change the FPU’s rounding mode and return 0 for success, but because the
>>>> floating-point operations are done in software, the rounding mode has no
>>>> effect. In short, there’s no way for polyml to have proper rounding
>>>> support on armel. Evidence supporting this is below.
>>>>
>>>> On cortex-r5:
>>>>
>>>> Current rounding: 0
>>>> Setting to FE_UPWARD (4194304): 1 <- rounding mode not supported
>>>> Current rounding: 0
>>>> 1.0 / 3.0: 0.333333333333333315
>>>> 1.0 / 3.0 * 1.0: 1.000000000000000000
>>>> Current rounding: 0
>>>>
>>>> On cortex-a8:
>>>>
>>>> Current rounding: 0
>>>> Setting to FE_UPWARD (4194304): 0
>>>> Current rounding: 4194304
>>>> 1.0 / 3.0: 0.333333333333333315
>>>> 1.0 / 3.0 * 1.0: 1.000000000000000000
>>>> Current rounding: 4194304
>>>>
>>>> Given that libc ships on armel but does not conform to the standard for
>>>> rounding, would it make sense to ship polyml for armel with this test
>>>> disabled? It seems a shame not to support armel at all.
>>>>
>>>> Regards,
>>>> James
>>
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
