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 [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
