This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
- From: "amylaar at spamcop dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 May 2007 15:40:01 -0000
- Subject: [Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
- References: <bug-31836-276@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #32 from amylaar at spamcop dot net 2007-05-14 16:39 -------
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
Quoting pcarlini at suse dot de <gcc-bugzilla@gcc.gnu.org>:
>
> safely when the target doesn't have infinities. Therefore, I would ask you to
> untangle a bit this thing... Apparently, for some reason, for your target
> onte
> of the checks (which one? !finitef? !finite?) is not working, instead the
> final
> f != __builtin_huge_valf() catches it.
These are excepts from
arc-elf32/arc700/libstdc++-v3/include/arc-elf32/bits/c++config.h:
/* Define to 1 if you have the `finitef' function. */
/* #undef _GLIBCXX_HAVE_FINITEF */
/* Define to 1 if you have the `_finitef' function. */
/* #undef _GLIBCXX_HAVE__FINITEF */
/* Define to 1 if you have the `finite' function. */
/* #undef _GLIBCXX_HAVE_FINITE */
/* Define to 1 if you have the `_finite' function. */
/* #undef _GLIBCXX_HAVE__FINITE */
/* Define to 1 if you have the `isinf' function. */
/* #undef _GLIBCXX_HAVE_ISINF */
/* Define to 1 if you have the `_isinf' function. */
/* #undef _GLIBCXX_HAVE__ISINF */
Thus, the test that should be performed in
_ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi should be:
if (fabs(__d) > numeric_limits<float>::max())
errno = ERANGE;
Disassembly of that method shows that the test has been
optimized away.
This is not actually surprising, because _GLIBCXX_HAVE_STRTOF
has been set, and hence strtof has been used, and
__d remained uninitalized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836