From: "Ludovic Courtès" <ludo@gnu.org>
To: Erik Garrison <erik.garrison@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull
Date: Wed, 10 Jun 2020 17:18:31 +0200 [thread overview]
Message-ID: <87eeqndk54.fsf@gnu.org> (raw)
In-Reply-To: <CALykB6=bDEqr53SRTD82z4kO4u+kkYHh1f8=C0AiCWHodL5Eww@mail.gmail.com> (Erik Garrison's message of "Tue, 9 Jun 2020 11:45:52 +0200")
Hi,
Erik Garrison <erik.garrison@gmail.com> skribis:
> I've run into a quirk in the various gcc toolchains that seems somewhat
> unique to guix builds of them. I'd like to understand if this is
> intentional.
>
> Initially, I found that string to numeric conversion functions that are
> enabled by _GLIBCXX_USE_C99_STDLIB are not available on guix gcc toolchains
> for gcc 8, 9, and 10.
>
> This is a minimal test case to reproduce the problem:
>
> Code:
>
> #include <iostream>
> #include <string>
>
> uint64_t _parse_number(std::string::const_iterator& c, const
> std::string::const_iterator& end) {
> std::string::const_iterator s = c;
> while (c != end and isdigit(*c)) ++c;
> if (c > s) {
> return std::stoull(std::string(s,c));
> } else {
> return 0;
> }
> }
>
> int main(int argc, char** argv) {
> std::string s(argv[1]);
> std::string::const_iterator b = s.begin();
> std::string::const_iterator e = s.end();
> std::cout << _parse_number(b, e) << std::endl;
> return 0;
> }
>
> Compiling with (g++ --version == 10.1.0),
> /gnu/store/3kvnslc16sy7kwi2c5r7r5k6bbv2p03f-gcc-toolchain-10.1.0/bin/g++
>
> g++ test-stoull.cpp -o test-stoull
I can reproduce it:
--8<---------------cut here---------------start------------->8---
$ guix describe
Generacio 147 Jun 08 2020 00:30:31 (nuna)
guix e782756
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: e78275608065ef073775fabb9f1a757da65851f2
$ guix environment --ad-hoc gcc-toolchain -C -- g++ num.cpp
num.cpp: In function 'uint64_t _parse_number(std::__cxx11::basic_string<char>::const_iterator&, const const_iterator&)':
num.cpp:9:33: error: invalid initialization of reference of type 'const wstring&' {aka 'const std::__cxx11::basic_string<wchar_t>&'} from expression of type 'std::string' {aka 'std::__cxx11::basic_string<char>'}
9 | return std::stoull(std::string(s,c));
| ^~~~~~~~~~~
--8<---------------cut here---------------end--------------->8---
This is indeed fixed with:
guix environment --ad-hoc gcc-toolchain@9 -C -- g++ -D_GLIBCXX_USE_C99_STDLIB=1 num.cpp
> This behavior appears to be similar to this issue:
> http://freebsd.1045724.x6.nabble.com/base-gcc-and-GLIBCXX-USE-C99-td5781697.html.
> It's also similar to this report,
> https://stackoverflow.com/questions/40779611/g-compile-error-invalid-initialization-of-reference-of-type-stdstod
> .
>
> It may be more correct to require wstring in these kinds of conversions.
> However, I'm concerned that if gcc is built differently in guix than it
> typically is in other distributions, we will need to patch many libraries
> when building them on guix. It's probably better to match typical
> expectations of developers about the behavior of gcc.
I agree, it seems we have a misconfiguration issue leading to this in
our c++config.h:
--8<---------------cut here---------------start------------->8---
/* Define if C99 functions or macros in <stdlib.h> should be imported in
<cstdlib> in namespace std for C++11. */
/* #undef _GLIBCXX11_USE_C99_STDLIB */
--8<---------------cut here---------------end--------------->8---
The check appears to be this:
--8<---------------cut here---------------start------------->8---
# Check for the existence in <stdlib.h> of lldiv_t, et. al.
AC_MSG_CHECKING([for ISO C99 support in <stdlib.h> for C++11])
AC_CACHE_VAL(glibcxx_cv_c99_stdlib_cxx11, [
GCC_TRY_COMPILE_OR_LINK(
[#include <stdlib.h>
volatile float f;
volatile long double ld;
volatile unsigned long long ll;
lldiv_t mydivt;],
[char* tmp;
f = strtof("gnu", &tmp);
ld = strtold("gnu", &tmp);
ll = strtoll("gnu", &tmp, 10);
ll = strtoull("gnu", &tmp, 10);
ll = llabs(10);
mydivt = lldiv(10,1);
ll = mydivt.quot;
ll = mydivt.rem;
ll = atoll("10");
_Exit(0);
], [glibcxx_cv_c99_stdlib_cxx11=yes], [glibcxx_cv_c99_stdlib_cxx11=no])
])
AC_MSG_RESULT($glibcxx_cv_c99_stdlib_cxx11)
if test x"$glibcxx_cv_c99_stdlib_cxx11" = x"yes"; then
AC_DEFINE(_GLIBCXX11_USE_C99_STDLIB, 1,
[Define if C99 functions or macros in <stdlib.h> should be imported
in <cstdlib> in namespace std for C++11.])
fi
--8<---------------cut here---------------end--------------->8---
We should check what’s going on!
Thanks,
Ludo’.
next prev parent reply other threads:[~2020-06-10 15:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-09 9:45 gcc-10 toolchain does not include string to numeric conversion functions like std::stoull Erik Garrison
2020-06-10 15:18 ` Ludovic Courtès [this message]
2020-07-11 11:30 ` Erik Garrison
2020-07-13 14:21 ` Ludovic Courtès
2020-07-13 16:37 ` Ekaitz Zarraga
2020-07-15 6:48 ` Pjotr Prins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eeqndk54.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=erik.garrison@gmail.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.