Hi, you are the maintainer, so it should be only up to you to make the final decision about architectures to support.<div id="yMail_cursorElementTracker_0.2170830813702196">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) :-)</div><div id="yMail_cursorElementTracker_0.2170830813702196"><br></div><div id="yMail_cursorElementTracker_0.2170830813702196">Just jocking, I always found a common agreement prior to sponsor a package :)</div><div id="yMail_cursorElementTracker_0.2170830813702196"><br></div><div id="yMail_cursorElementTracker_0.2170830813702196">So, at the end, please tell me your solution, or even better give me a dsc to sponsor :)</div><div id="yMail_cursorElementTracker_0.2170830813702196"><br></div><div id="yMail_cursorElementTracker_0.2170830813702196">If the bug is in glibc seems rather good to report it and disable the test.</div><div id="yMail_cursorElementTracker_0.2170830813702196">(Remember to reenable it if glibc gets fixed)</div><div id="yMail_cursorElementTracker_0.2170830813702196"><br></div><div id="yMail_cursorElementTracker_0.2170830813702196">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.</div><div id="yMail_cursorElementTracker_0.2170830813702196"><br></div><div id="yMail_cursorElementTracker_0.2170830813702196">But again you are the maintainer, I trust your opinion after sponsoring 4 times already the package!<br></div><div id="yMail_cursorElementTracker_0.2170830813702196"><br></div><div id="yMail_cursorElementTracker_0.2170830813702196">Cheers,</div><div id="yMail_cursorElementTracker_0.2170830813702196"><br></div><div id="yMail_cursorElementTracker_0.2170830813702196">Gianfranco<br><br><div><a href="https://overview.mail.yahoo.com/mobile/?.src=Android">Sent from Yahoo Mail on Android</a></div> <br> <blockquote style="margin: 0 0 20px 0;"> <header style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Mon, 25 Jan, 2016 at 20:55, James Clarke</div><div><jrtc27@jrtc27.com> wrote:</div> </header> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> <div id="msgSandbox_ACIJDNkAABB1VqZ91gkcCElsrqM_1" class="msgSandbox" style="padding: 1.5em 0.5em 0.5em 1.2em; word-wrap: break-word;">Hi Gianfranco,<div class="yQTDBase yqt6147489910" id="yqtfd27447"><br clear="none"><br clear="none">>> I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are. Should I get in touch with debian-arm?<br clear="none">> <br clear="none">> probably yes, even if I don't care there are much armel porters there...<br clear="none">> <br clear="none">> You might end up in asking ftpmaster to remove the armel binary.</div><br clear="none"><br clear="none">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.<br clear="none"><br clear="none">On cortex-r5:<br clear="none"><br clear="none">    Current rounding: 0<br clear="none">    Setting to FE_UPWARD (4194304): 1     <- rounding mode not supported<br clear="none">    Current rounding: 0<br clear="none">    1.0 / 3.0: 0.333333333333333315<br clear="none">    1.0 / 3.0 * 1.0: 1.000000000000000000<br clear="none">    Current rounding: 0<br clear="none"><br clear="none">On cortex-a8:<br clear="none"><br clear="none">    Current rounding: 0<br clear="none">    Setting to FE_UPWARD (4194304): 0<br clear="none">    Current rounding: 4194304<br clear="none">    1.0 / 3.0: 0.333333333333333315<br clear="none">    1.0 / 3.0 * 1.0: 1.000000000000000000<br clear="none">    Current rounding: 4194304<br clear="none"><br clear="none">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.<br clear="none"><br clear="none">Regards,<br clear="none">James</div> </div> </blockquote></div>