Hi, > 1/3 can’t be represented exactly, so when rounding to +Inf, you get a little > bit more than 1/3. 3 can be represented exactly, so 3 * 1/3 is a little more > than 1, >and since the rounding mode is set to +Inf it should therefore round > to a little over 1. I’m pretty sure the test is correct; certainly it works > on every other >supported platform.
ok >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 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. cheers, Gianfranco -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers