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
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
