[Bug libstdc++/15088] 27_io/ostream_inserter_arith test05/06 failures

["jifl-bugzilla at jifvik dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jifl-bugzilla at jifvik dot org  2004-05-13 23:07 -------
For what was test05() and is now 5.cc after a testsuite reorg, I've attached a
patch which gives the system a bit more tolerance.

2004-05-13  Jonathan Larmour  <jifl@eCosCentric.com>

	* testsuite/27_io/basic_ostream/inserters_arithmetic/char/5.cc (test05):
        Allow the underlying system a bit more tolerance with FP accuracy.


However I'm not sure what to do about test06(). On my system DBL_MIN was such an
extreme limit, that strtod was several powers of 10 off. Given the original
purpose of this test at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9151 adding
more tolerance may defeat the purpose.

If there's some way to accurately determine if we're using software FP, then I'm
sure that would help and we could conditionalise the degree by which we relax
things on that. However there appears to be no consistent way to do that. For
example ARM tools define __SOFTFP__ but it looks like SPARC and PowerPC define
_SOFT_FLOAT , Xtensa defines __XTENSA_SOFT_FLOAT__ and there are some which
clearly don't define anything at all.

Maybe all that can be done is conditionalise on any of the above defines and
deal with any remainder on a case-by-case basis. I wonder if there's some way
for a test to use preprocessor defines to decide whether to do an XFAIL though?

I've now tested with some ARM tools for newlib I had around, and you can
reproduce the failure I experienced with both 5.cc and 6.cc with the ARM
simulator, although 6.cc doesn't require as much adjustment as I had to with the
strtod implementation on my system. With newlib, abs(oval-ival)/oval==6.66e-16
versus DBL_EPSILON==2.22e-16 so pretty close. newlib's strtod() implementation
is quite "expensive", at least for an embedded system, though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15088