On Sun Apr 19 03:49:20 2020, SREZIC wrote:
Show quoted text> On 2020-04-19 03:41:49, SREZIC wrote:
> > t/03arith.t and t/13constants.t fail on my Fedora 31 smoker:
> >
> > ...
> >
> > Expected 1
> > Got 8
> > t/03arith.t ..................
> > Failed 1/20 subtests
> > ...
> > M_1_PIq: 3.18309886183790671537767526745028737e-01
> > M_2_PIq: 6.36619772367581343075535053490057474e-01
> > M_SQRT2q: 1.41421356237309504880168872420969798e+00
> > t/13constants.t ..............
> > Failed 3/23 subtests
> > ...
> >
> > The t/03arith.t failure also happens of Ubuntu 19.10.
>
> On debian/testing (bullseye, version 11) both tests also fail.
Hi Slaven,I got the same FAIL reports from Peter Acklam's smoke a few days ago.
The 03arith.t failure is a bug in that test script. I've assumed that signbit() will return 1 if the signbit is set ... but I should instead be checking whether it returns a true value or not.
Looks to me that the values quoted in your test report for M_1_PIq, M_2_PIq and M_SQRT2q are correct, whereas other versions of quadmath.h are assigning less precise (and therefor incorrect, IMO) approximations.I'll take steps to address those anomalies.My initial thoughts were to simply increase $eps (in t/13constants.t) from 0 to 1e-33, but there's probably a more open and honorable way to deal with it ;-)
I reported the issue regarding M_SQRT2q a while back at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83800.
The gcc developers seemed to take a somewhat hazy view as to whether it should be considered a bug, but it seems that it has now been fixed - in some places, at least.
Thanks for the report
Cheers,Rob