unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
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’.


  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

  List information: https://guix.gnu.org/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).