[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #23 from John David Anglin --- Fixed by last commit.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #22 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:31c3b67dfc6e67773d13260bc38b833663698b74 commit r14-2753-g31c3b67dfc6e67773d13260bc38b833663698b74 Author: Jonathan Wakely Date: Mon Jul 24 11:45:43 2023 +0100 libstdc++; Do not use strtold for hppa-hpux [PR110653] When I switched std::stold to depend on HAVE_STRTOLD that enabled it for hppa-hpux which defines HAVE_BROKEN_STRTOLD. Add a check for that macro so that we don't use strtold, and fall through to the check for double and long double having the same representation. That should mean we define a conforming std::stold in terms of std::stod, instead of trying to use the broken strtold. Also fix a logic error in the fallback definition of std::stod, which should not treat zero as a subnormal number. libstdc++-v3/ChangeLog: PR libstdc++/110653 * include/bits/basic_string.h [!HAVE_STOF] (stof): Do not throw an exception for zero result. [HAVE_BROKEN_STRTOLD] (stold): Do not use strtold.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #21 from Jonathan Wakely --- (In reply to dave.anglin from comment #20) > The stoll and stoull tests pass when dg-require-string-conversions is 1. > The stold test > fails, I think because it returns LDBL_MAX instead of HUGE_VALL (inf). See > _GLIBCXX_HAVE_BROKEN_STRTOLD comment in /config/os/hpux/os_defines.h. Aha. > There is a problem with std::stof. It throws an out of range exception for > 0. It needs to > check for 0 value. Oops :-) I'll fix both of these on Monday - thanks for the testing and analysis.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #20 from dave.anglin at bell dot net --- On 2023-07-19 6:10 a.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 > > --- Comment #17 from Jonathan Wakely --- > (In reply to Jonathan Wakely from comment #16) >> PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc (test for >> excess errors) >> PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc execution >> test > Oops, sorry, not that one! As mentioned, that will be UNSUPPORTED for > hpux11.11 Yes, stoll and stoull tests are UNSUPPORTED. We also have: UNSUPPORTED: 21_strings/basic_string/numeric_conversions/char/stold.cc The rest of the non wide character conversion tests pass. The stoll and stoull tests pass when dg-require-string-conversions is 1. The stold test fails, I think because it returns LDBL_MAX instead of HUGE_VALL (inf). See _GLIBCXX_HAVE_BROKEN_STRTOLD comment in /config/os/hpux/os_defines.h. There is a problem with std::stof. It throws an out of range exception for 0. It needs to check for 0 value.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #19 from Jonathan Wakely --- (In reply to dave.anglin from comment #18) > The stof.cc and stold.cc tests fail in try-catch. Yes, my suggested patch in comment 12 was wrong, because it only set errno on error and didn't throw an exception. What I committed should be OK.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #18 from dave.anglin at bell dot net ---
On 2023-07-19 6:10 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #16 from Jonathan Wakely ---
> This should be fixed now, and you should see these in libstdc++.sum
>
> PASS: 21_strings/basic_string/numeric_conversions/char/stod.cc (test for
> excess
> errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stod.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stof.cc (test for
> excess
> errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stof.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stoi.cc (test for
> excess
> errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stol.cc (test for
> excess
> errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stold.cc (test for
> excess errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stold.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc (test for
> excess errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc execution test
> PASS: 21_strings/basic_string/numeric_conversions/char/stoul.cc (test for
> excess errors)
> PASS: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
>
> The char/stoll.cc and char/stoull.cc tests would actually pass for hpux11.11
> as
> well, but they have the { dg-require-string-conversions "" } check which
> fails.
Had the following fails with attached patch:
Running target unix
FAIL: 20_util/from_chars/4.cc execution test
FAIL: 20_util/from_chars/8.cc execution test
FAIL: 20_util/to_chars/float128_c++23.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stof.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stold.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/dr1261.cc (test for
excess errors)
UNRESOLVED: 21_strings/basic_string/numeric_conversions/wchar_t/dr1261.cc
compilation failed to produce executable
FAIL: 26_numerics/headers/cmath/constexpr_std_c++23.cc (test for excess errors)
FAIL: 26_numerics/headers/cmath/functions_std_c++23.cc (test for excess errors)
FAIL: 26_numerics/headers/cmath/nextafter_c++23.cc (test for excess errors)
UNRESOLVED: 26_numerics/headers/cmath/nextafter_c++23.cc compilation failed to
produce executable
FAIL: 27_io/basic_ofstream/open/char/noreplace.cc execution test
FAIL: 27_io/basic_ofstream/open/wchar_t/noreplace.cc execution test
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc execution test
FAIL: 29_atomics/atomic/compare_exchange_padding.cc execution test
FAIL: 29_atomics/atomic/lock_free_aliases.cc (test for excess errors)
FAIL: 29_atomics/atomic_ref/compare_exchange_padding.cc execution test
=== libstdc++ Summary ===
# of expected passes 14134
# of unexpected failures 15
# of expected failures 106
# of unresolved testcases 2
# of unsupported tests 1014
The stof.cc and stold.cc tests fail in try-catch.
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_co
nversions/char/stof.cc:128: void test01(): Assertion 'test' failed.
FAIL: 21_strings/basic_string/numeric_conversions/char/stof.cc execution test
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/21_strings/basic_string/numeric_co
nversions/char/stold.cc:95: void test01(): Assertion 'test' failed.
FAIL: 21_strings/basic_string/numeric_conversions/char/stold.cc execution test
Will retest with your commit.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #17 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #16) > PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc (test for > excess errors) > PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc execution > test Oops, sorry, not that one! As mentioned, that will be UNSUPPORTED for hpux11.11
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #16 from Jonathan Wakely ---
This should be fixed now, and you should see these in libstdc++.sum
PASS: 21_strings/basic_string/numeric_conversions/char/stod.cc (test for excess
errors)
PASS: 21_strings/basic_string/numeric_conversions/char/stod.cc execution test
PASS: 21_strings/basic_string/numeric_conversions/char/stof.cc (test for excess
errors)
PASS: 21_strings/basic_string/numeric_conversions/char/stof.cc execution test
PASS: 21_strings/basic_string/numeric_conversions/char/stoi.cc (test for excess
errors)
PASS: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
PASS: 21_strings/basic_string/numeric_conversions/char/stol.cc (test for excess
errors)
PASS: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
PASS: 21_strings/basic_string/numeric_conversions/char/stold.cc (test for
excess errors)
PASS: 21_strings/basic_string/numeric_conversions/char/stold.cc execution test
PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc (test for
excess errors)
PASS: 21_strings/basic_string/numeric_conversions/char/stoll.cc execution test
PASS: 21_strings/basic_string/numeric_conversions/char/stoul.cc (test for
excess errors)
PASS: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
The char/stoll.cc and char/stoull.cc tests would actually pass for hpux11.11 as
well, but they have the { dg-require-string-conversions "" } check which fails.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #15 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f07136af570b145fe0df6b142defc9558998bf53 commit r14-2637-gf07136af570b145fe0df6b142defc9558998bf53 Author: Jonathan Wakely Date: Sat Jul 15 20:58:22 2023 +0100 libstdc++: Enable tests for std::stoi etc. unconditionally [PR110653] Since the narrow string versions of std::stoi, std::stol, std::stoul, std::stof and std::stod are now always defined, we don't need to check dg-require-string-conversions in the relevant tests. libstdc++-v3/ChangeLog: PR libstdc++/110653 * testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc: Remove dg-require-string-conversions. * testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stoul.cc: Likewise.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #14 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f0b0c21152b337bc9a8ef3a72a15c8dcdff1d847 commit r14-2636-gf0b0c21152b337bc9a8ef3a72a15c8dcdff1d847 Author: Jonathan Wakely Date: Sat Jul 15 20:41:28 2023 +0100 libstdc++: Define std::stof fallback in terms of std::stod [PR110653] For targets without std::strtof we can define std::stof by calling std::stod and then checking if the result is out of range of float. libstdc++-v3/ChangeLog: PR libstdc++/110653 * include/bits/basic_string.h [!_GLIBCXX_HAVE_STRTOF] (stof): Define in terms of std::stod.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #13 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:58303d42809f0e01f23262f592d37943f7703f71 commit r14-2635-g58303d42809f0e01f23262f592d37943f7703f71 Author: Jonathan Wakely Date: Thu Jul 13 10:44:57 2023 +0100 libstdc++: Check autoconf macros for strtof and strtold [PR110653] As well as the _GLIBCXX_USE_C99_STDLIB check, we also have a separate check in linkage.m4 for just strtof and strtold. We can use that to declare std::strtof and std::strtold in for additional targets. That allows us to enable std::stold on hpux11.11 which is missing strtoll, strtoull and strtof, so doesn't define _GLIBCXX_USE_C99_STDLIB. Although it doesn't help hpux11.11, we can define std::stof for more targets this way too. As with the previous commit for PR110653, this only affects the narrow character overloads. std::stof and std::stold for wstring still requires C99 support. libstdc++-v3/ChangeLog: PR libstdc++/110653 * include/bits/basic_string.h [_GLIBCXX_HAVE_STRTOF] (stof): Define. [_GLIBCXX_HAVE_STRTOLD] (stold): Define. * include/c_global/cstdlib [_GLIBCXX_HAVE_STRTOF] (strtof): Declare in namespace std. [_GLIBCXX_HAVE_STRTOLD] (strtold): Likewise.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #12 from Jonathan Wakely ---
(In reply to dave.anglin from comment #11)
> Yes, this works.
Great, thanks.
> hppa64-hpux does not have have strtof. Could std::stof be implemented using
> strtod in this case?
Maybe something like this:
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -4153,6 +4153,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
inline float
stof(const string& __str, size_t* __idx = 0)
{ return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
+#else
+ inline float
+ stof(const string& __str, size_t* __idx = 0)
+ {
+double __d = std::stod(__str, __idx);
+if (__builtin_isfinite(__d))
+ {
+ double __abs_d = __builtin_fabs(__d);
+ if (__abs_d < __FLT_MIN__)
+ errno = ERANGE;
+ else if (__abs_d > __FLT_MAX__)
+ {
+ errno = ERANGE;
+ float __f = __builtin_huge_valf();
+ return __d > 0.0 ? __f : -__f;
+ }
+ }
+return __d;
+ }
#endif
#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOLD
> I'm thinking a test to check the presence and maybe compliance of these
> routines might be good.
We have some:
testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc
testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc
But they depend on { dg-require-string-conversions "" } which is only true if
we have the full set of them:
return [check_v3_target_prop_cached et_string_conversions {
set cond "_GLIBCXX_USE_C99_STDIO && _GLIBCXX_USE_C99_STDLIB"
set cond "$cond && _GLIBCXX_USE_C99_WCHAR"
set cond "$cond && !defined _GLIBCXX_HAVE_BROKEN_VSWPRINTF"
return [v3_check_preprocessor_condition string_conversions $cond]
}]
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #11 from dave.anglin at bell dot net ---
On 2023-07-14 5:58 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #10 from Jonathan Wakely ---
> And this should fix it:
>
> --- a/libstdc++-v3/include/c_global/cstdlib
> +++ b/libstdc++-v3/include/c_global/cstdlib
> @@ -256,6 +256,20 @@ namespace std
> using ::__gnu_cxx::strtold;
> } // namespace std
>
> +#else // ! _GLIBCXX_USE_C99_STDLIB
> +
> +// We also check for strtof and strtold separately from
> _GLIBCXX_USE_C99_STDLIB
> +
> +#if _GLIBCXX_HAVE_STRTOF
> +#undef strtof
> +namespace std { using ::strtof; }
> +#endif
> +
> +#if _GLIBCXX_HAVE_STRTOLD
> +#undef strtold
> +namespace std { using ::strtold; }
> +#endif
> +
> #endif // _GLIBCXX_USE_C99_STDLIB
>
> } // extern "C++"
Yes, this works.
hppa64-hpux does not have have strtof. Could std::stof be implemented using
strtod in this case?
I'm thinking a test to check the presence and maybe compliance of these
routines might be good.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #10 from Jonathan Wakely ---
And this should fix it:
--- a/libstdc++-v3/include/c_global/cstdlib
+++ b/libstdc++-v3/include/c_global/cstdlib
@@ -256,6 +256,20 @@ namespace std
using ::__gnu_cxx::strtold;
} // namespace std
+#else // ! _GLIBCXX_USE_C99_STDLIB
+
+// We also check for strtof and strtold separately from
_GLIBCXX_USE_C99_STDLIB
+
+#if _GLIBCXX_HAVE_STRTOF
+#undef strtof
+namespace std { using ::strtof; }
+#endif
+
+#if _GLIBCXX_HAVE_STRTOLD
+#undef strtold
+namespace std { using ::strtold; }
+#endif
+
#endif // _GLIBCXX_USE_C99_STDLIB
} // extern "C++"
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #9 from Jonathan Wakely --- (In reply to dave.anglin from comment #8) > or maybe "using::strtold" additions are needed to various cstdlib files in > gcc. Yes, that's the problem.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #8 from dave.anglin at bell dot net ---
On 2023-07-13 2:16 p.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #7 from dave.anglin at bell dot net ---
> On 2023-07-13 1:57 p.m., dave.anglin at bell dot net wrote:
>> ./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36:
>> error:
>> 'strtold' is not a member of 'std'; did you mean 'strtoll'?
> That's a problem with stdlib.h header.
I thought this was because we lack _NAMESPACE_STD_START and _NAMESPACE_STD_END
statements
around the strtold declaration in stdlib.h, but this didn't help. Maybe we lack
a define for _NAMESPACE_STD
/* ANSI C++ namespace std support */
#ifdef _NAMESPACE_STD
#define _NAMESPACE_STD_START namespace std {
#define _NAMESPACE_STD_END }
or maybe "using::strtold" additions are needed to various cstdlib files in gcc.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #7 from dave.anglin at bell dot net --- On 2023-07-13 1:57 p.m., dave.anglin at bell dot net wrote: > ./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36: error: > 'strtold' is not a member of 'std'; did you mean 'strtoll'? That's a problem with stdlib.h header.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #6 from dave.anglin at bell dot net ---
On 2023-07-13 1:09 p.m., redi at gcc dot gnu.org wrote:
> I'm testing this, which should define std::stof and std::stold for hpux11.11:
>
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -4148,12 +4148,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> stod(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtod, "stod", __str.c_str(), __idx); }
>
> -#if _GLIBCXX_USE_C99_STDLIB
> +#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOF
> // NB: strtof vs strtod.
> inline float
> stof(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
> +#endif
>
> +#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOLD
> inline long double
> stold(const string& __str, size_t* __idx = 0)
> { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(), __idx);
> }
> @@ -4161,7 +4163,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> inline long double
> stold(const string& __str, size_t* __idx = 0)
> { return std::stod(__str, __idx); }
> -#endif // _GLIBCXX_USE_C99_STDLIB
> +#endif
We get this error with the above:
bash-5.1$ gcc/xg++ -Bgcc/ -o xxx xxx.cc
-I./hppa64-hp-hpux11.11/libstdc++-v3/include
-I./hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-Lhppa64-hp-hpux11.11/libstdc++-v3/src/.libs -O2
In file included from ./hppa64-hp-hpux11.11/libstdc++-v3/include/string:54,
from xxx.cc:1:
./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h: In function
'long double std::__cxx11::stold(const std::string&, std::size_t*)':
./hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:4161:36: error:
'strtold' is not a member of 'std'; did you mean 'strtoll'?
4161 | { return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(),
__idx); }
| ^~~
| strtoll
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #5 from Jonathan Wakely ---
(In reply to dave.anglin from comment #3)
> On 2023-07-13 9:46 a.m., redi at gcc dot gnu.org wrote:
> > Dave, does this patch work for hppa64-hp-hpux11.11 ?
> Yes.
Great - pushed to trunk.
> On hpux, double and long double have different representations (they are
> same on linux). hpux11.11 has both
> strtod and strtold. strtold is checked for:
>
> /* Define to 1 if you have the `strtof' function. */
> /* #undef HAVE_STRTOF */
>
> /* Define to 1 if you have the `strtold' function. */
> #define HAVE_STRTOLD 1
Ah yes. That comes from libstdc++-v3/linkage.m4 which I think I've never even
looked at before!
> There doesn't seem to be a configure check for strtod.
That's from C89 and we already assume that's available unconditionally e.g. for
this code in :
using ::strtod;
using ::strtol;
using ::strtoul;
I'm testing this, which should define std::stof and std::stold for hpux11.11:
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -4148,12 +4148,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
stod(const string& __str, size_t* __idx = 0)
{ return __gnu_cxx::__stoa(::strtod, "stod", __str.c_str(), __idx); }
-#if _GLIBCXX_USE_C99_STDLIB
+#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOF
// NB: strtof vs strtod.
inline float
stof(const string& __str, size_t* __idx = 0)
{ return __gnu_cxx::__stoa(::strtof, "stof", __str.c_str(), __idx); }
+#endif
+#if _GLIBCXX_USE_C99_STDLIB || _GLIBCXX_HAVE_STRTOLD
inline long double
stold(const string& __str, size_t* __idx = 0)
{ return __gnu_cxx::__stoa(::strtold, "stold", __str.c_str(), __idx); }
@@ -4161,7 +4163,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
inline long double
stold(const string& __str, size_t* __idx = 0)
{ return std::stod(__str, __idx); }
-#endif // _GLIBCXX_USE_C99_STDLIB
+#endif
// DR 1261. Insufficent overloads for to_string / to_wstring
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a1d12752f8d45df5d7962cef6e2a87585002e982 commit r14-2504-ga1d12752f8d45df5d7962cef6e2a87585002e982 Author: Jonathan Wakely Date: Thu Jul 13 10:44:57 2023 +0100 libstdc++: std::stoi etc. do not need C99 support [PR110653] std::stoi, std::stol, std::stoul, and std::stod only depend on C89 functions, so don't need to be guarded by _GLIBCXX_USE_C99_STDLIB std::stoll and std::stoull don't need C99 strtoll and strtoull if sizeof(long) == sizeof(long long). std::stold doesn't need C99 strtold if DBL_MANT_DIG == LDBL_MANT_DIG. This only applies to the narrow character overloads, the wchar_t overloads depend on a separate _GLIBCXX_USE_C99_WCHAR macro and none of them can be implemented in C89 easily. libstdc++-v3/ChangeLog: PR libstdc++/110653 * include/bits/basic_string.h (stoi, stol, stoul, stod): Do not depend on _GLIBCXX_USE_C99_STDLIB. [__LONG_WIDTH__ == __LONG_LONG_WIDTH__] (stoll, stoull): Define in terms of stol and stoul respectively. [__DBL_MANT_DIG__ == __LDBL_MANT_DIG__] (stold): Define in terms of stod.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #3 from dave.anglin at bell dot net ---
On 2023-07-13 9:46 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #2 from Jonathan Wakely ---
> Created attachment 55534
>--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55534=edit
> libstdc++: std::stoi etc. do not need C99 support
>
> Dave, does this patch work for hppa64-hp-hpux11.11 ?
Yes.
>
> It should allow you to compile + run the code below:
>
> #include
> int main()
> {
>std::string z = "0";
>return std::stoi(z) + std::stol(z) + std::stoul(z) + std::stoll(z)
> + std::stoull(z) + std::stod(z);
> }
The above code compiles and runs successfully on hppa64-hp-hpux11.11 with the
patch.
>
> I'm not sure if double and long double are the same representation on this
> target, but if they are then std::stold("0.0") should work too.
Adding std::stold("0.0") to test, we get:
bash-5.1$ gcc/xg++ -Bgcc/ -o xxx xxx.cc
-I./hppa64-hp-hpux11.11/libstdc++-v3/include
-I./hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-Lhppa64-hp-hpux11.11/libstdc++-v3/src/.libs -O2
xxx.cc: In function 'int main()':
xxx.cc:6:48: error: 'stold' is not a member of 'std'
6 | + std::stoull(z) + std::stod(z) + std::stold("0.0");
| ^
xxx.cc:2:1: note: 'std::stold' is defined in header ''; this is
probably fixable by adding '#include '
1 | #include
+++ |+#include
2 | int main()
On hpux, double and long double have different representations (they are same
on linux). hpux11.11 has both
strtod and strtold. strtold is checked for:
/* Define to 1 if you have the `strtof' function. */
/* #undef HAVE_STRTOF */
/* Define to 1 if you have the `strtold' function. */
#define HAVE_STRTOLD 1
There doesn't seem to be a configure check for strtod.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #2 from Jonathan Wakely ---
Created attachment 55534
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55534=edit
libstdc++: std::stoi etc. do not need C99 support
Dave, does this patch work for hppa64-hp-hpux11.11 ?
It should allow you to compile + run the code below:
#include
int main()
{
std::string z = "0";
return std::stoi(z) + std::stol(z) + std::stoul(z) + std::stoll(z)
+ std::stoull(z) + std::stod(z);
}
I'm not sure if double and long double are the same representation on this
target, but if they are then std::stold("0.0") should work too.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-07-13 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- std::stoi, std::stol and stoul only depend on strtol and strtoul which are in C89, so don't need to be guarded by _GLIBCXX_USE_C99_STDLIB std::stoll and std::stoull can be implemented without C99 strtoll and strtoull if sizeof(long) == sizeof(long long). std::stod only depends on strtod which is in C89. std::stold can be implemented without C99 strtold if DBL_MANT_DIG == LDBL_MANT_DIG.
