Hi, >> Besides FE_UPWARD having a different value (given that it’s >> platform-specific), armel calculates 1.0 / 3.0 as 0.333333333333333315, >> which is wrong for FE_UPWARD (but correct for FE_NEAREST), and I imagine >> there are similar issues for the other rounding modes (other than >> FE_NEAREST). Any thoughts as to what could be going >on? > sorry but I didn't even understand what you said here :) you have a knowledge > on the rounding model order of magnitude higher than mine :) > I don't think I can help here, but BTW
That’s ok.
>
> IIRC armel doesn't have floating point instructions, but only emulated in
> software (this should be the difference with armhf), so can this be
>
> just a gcc-5 bug? you might want to try and use gcc-4.9 or gcc-6 from
> experimental to see if the bug is still there
>
> I did a few seconds ago a build with CC=gcc-4.9 CXX=g++-4.9 in rules file
> and also with gcc-6, it fails on all of them.
I think it’s implemented in glibc, not gcc; certainly fe{g,s}etround are.
Should I get in touch with debian-arm?
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
