Any advice, generic or specific, would be welcome.Have you looked at the specific failing reports ?
For example,
this one (MS Windows, perl-5.16.0) shows that all of the failures are related to the way that NaN is being displayed.
MS Windows has a myriad of ways of displaying NaN.
Interestingly, the module passes all tests on 5.16.0 for me (on Windows) but I'm not using the precise Strawberry build that produced that FAIL report.
You
could grab the perl that produced that FAIL report and give it a spin yourself.
(My perl-5.16.0 was built with a different version of gcc from a different vendor.)
Similarly, the other FAIL reports I looked at arose because an expected 'nan' turned out to be '-nan' (or vice-versa).
It seems to me that there's a diversity in the way that the sign of the NaN is determined.
If IEEE-754 decrees that such diversity should not exist then you're obviously up against a number of perl builds that are not compliant with IEEE-754 in that regard.
And it's quite likely not perl's fault - rather the fault of the underlying system/compiler/libc.
If you really want to test the sign of NaN I would suggest that, at the 'perl Makefile.PL' step, you run a C program that determines whether NaN's signedness is being treated as you expect.
Then proceed to act on that determination as you wish.
(That is, if there's a problem with the setting of the sign, do you want to provide a workaround ? ... or do you want to skip the tests regarding the sign ? ... or do you want to do something else ?)
As a ghastly example of what I'm alluding to, you could look at what I do in
Math::LongDouble to determine such things as whether
nan**0 is evaluated correctly.
Cheers,
Rob