> fc is built with: > mov r0, #0 > movt r0, 24448 > so r0=0x5f800000 (1.8446744E19) which looks ok
this is correct. My x86_64 yields the same value > but then cosatanf is computed as (ie there's not call to cosatanf()): > movw r3, #48430 > movt r3, 45883 > so r3=0xb33bbd2e (-4.371139E-8) which is not zero. Ugh. So GCC replaced the function call with a precomputed value? This does not happens in my x86_64. Maybe it is Ofast's fault? Also, it seems that GCC is precomputing cos(atan(x)) before the substitution, as the following python script yields the same result: import numpy as np x = np.float32 (1.8446744e19) print (np.cos (np.arctan (x)) I would also like to add that -4.371139E-8 is very far away from 5.421011E-20, which is a "more" correct value for this computation. So returning 0 may be a better option? On Fri, Oct 12, 2018 at 12:57 PM Jeff Law <l...@redhat.com> wrote: > > On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote: > > Hello > > What is the output of these functions on such arch? Since the > > test didn't fail for the sinatan counterpart, an possible explanation > > would be that the calculation of the sqrf, sqrt and sqrtl (lines > > 62-64) yielded a number that is far behind of what it should be. > > However, I am still not sure about this, so I will investigate > > further. > > How about I write a small program to check if the result > > obtained by this calculation is what it should be? > I suspect it's less the architecture and more the underlying library. > As Christophe mentioned, both issues are with newlib which is an C > library primarily used in the emebedded space. I believe it's math code > derives from early BSD libm and likely hasn't been stressed for this > kind of correctness. It's lightly maintained (primarily for cygwin). > > I'm going to run the testcases in my arm linux chroots. That should > allow us to rule out codegen issues as those chroots will be using glibc > for their math library. > > jeff