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
