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
