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

Reply via email to