From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id cOf6FvmiCV8wVwAA0tVLHw (envelope-from ) for ; Sat, 11 Jul 2020 11:31:05 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id Na28EvmiCV9+QgAAbx9fmQ (envelope-from ) for ; Sat, 11 Jul 2020 11:31:05 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BB166940B75 for ; Sat, 11 Jul 2020 11:31:04 +0000 (UTC) Received: from localhost ([::1]:58430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1juDih-0002iy-Jm for larch@yhetil.org; Sat, 11 Jul 2020 07:31:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56088) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1juDiY-0002io-2J for guix-devel@gnu.org; Sat, 11 Jul 2020 07:30:54 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:55297) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1juDiV-0000WK-Tx; Sat, 11 Jul 2020 07:30:53 -0400 Received: by mail-wm1-x330.google.com with SMTP id g75so8652753wme.5; Sat, 11 Jul 2020 04:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KPDYXAu+8esofLpKYwMD4aNTmJgqFS7dUMBziLIPD/o=; b=bBEc1jCnnHinYsZNKGD83rP8Jhxr40hXq1EwbVFJXU3skHB76GVEpNEFXLgEbpL2Z+ RtM0J/arIhtbOTXiQWm/bTzZcSiIV7nNP8cWn9pQCavsbPvqTlpAcyZWs5QhCkp62PCk SNldU3ELvu8g975052demkLNiyKKRnXZ1FaEahWcQUCAbeOxfaGuyj5il34clAtMgO1R rSS/0TNqfw5fbEoK5/WU17FqoBHVklKy8K3/6Gy9fYykSsdky404N210ykzj88raVqbs P/Bc3uYPeWWfYg2kNapPYR8mJofrg1vG6iBnxV67ZRjTNtmewG5eosJubSiqHYibbdAO hiXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KPDYXAu+8esofLpKYwMD4aNTmJgqFS7dUMBziLIPD/o=; b=dwjHswN9LHxq/i9O012zJwJCDoQVM2fLd02Vr7XrjPnqBmzEL61L482h3tijGnagk7 rLGR15JR6sycwQWAMM48ut9q7P1qUc7FRkV1phq7LMExpuFYNLBiMxiSApxCPb+E1aVj Nq02V7dTatvwJUTaHfG6XIp30FXBdQtQIuhK1eqUI+6AGJ3nECvPWDh75+xRoXVVT/Cw ffUZ+9jTjTa9OT0O87kklgi7zgQUx15TjZ1NBOHm/T4Ex/icxV4bvc0OjJ/6alp2V8Wj lGGHRW3xprvMEiTt51YU4dwmNG1KxjJoMtkX18uDdSVjm43F0Kg2N0kVWrVYuJwUbg3N C72Q== X-Gm-Message-State: AOAM532MeCFa1rctBi98UVpgW8Irufn/2TM8u2Cxiey9NQn16s6KHSG6 i9UtUnP5SXwl+gH4u4q23l/3clkH47FaeGpFwF/453cQ X-Google-Smtp-Source: ABdhPJydYvcaM5EYjNUau6ANBF2GVKkW3iZbH/ZVBZaUr27encvVLIKjj3IzSHI1fqR63jy5RYimH1YGRul1bo+oh+A= X-Received: by 2002:a05:600c:2907:: with SMTP id i7mr9286916wmd.40.1594467048555; Sat, 11 Jul 2020 04:30:48 -0700 (PDT) MIME-Version: 1.0 References: <87eeqndk54.fsf@gnu.org> In-Reply-To: <87eeqndk54.fsf@gnu.org> From: Erik Garrison Date: Sat, 11 Jul 2020 13:30:36 +0200 Message-ID: Subject: Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: multipart/alternative; boundary="000000000000090abf05aa28ca97" Received-SPF: pass client-ip=2a00:1450:4864:20::330; envelope-from=erik.garrison@gmail.com; helo=mail-wm1-x330.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=bBEc1jCn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -0.71 X-TUID: 2jdG00jN2cZv --000000000000090abf05aa28ca97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ludo, Thanks for reproducing this. Did you take a look at a resolution beyond your analysis in this message? It would seem that the attempted compilation isn't working during the configure phase. Erik On Wed, Jun 10, 2020, 17:18 Ludovic Court=C3=A8s wrote: > Hi, > > Erik Garrison 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 > > #include > > > > uint64_t _parse_number(std::string::const_iterator& c, const > > std::string::const_iterator& end) { > > std::string::const_iterator s =3D c; > > while (c !=3D 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 =3D s.begin(); > > std::string::const_iterator e =3D s.end(); > > std::cout << _parse_number(b, e) << std::endl; > > return 0; > > } > > > > Compiling with (g++ --version =3D=3D 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::const_iterator&, const > const_iterator&)': > num.cpp:9:33: error: invalid initialization of reference of type 'const > wstring&' {aka 'const std::__cxx11::basic_string&'} from > expression of type 'std::string' {aka 'std::__cxx11::basic_string'} > 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=3D1 num.cpp > > > This behavior appears to be similar to this issue: > > > http://freebsd.1045724.x6.nabble.com/base-gcc-and-GLIBCXX-USE-C99-td57816= 97.html > . > > It's also similar to this report, > > > https://stackoverflow.com/questions/40779611/g-compile-error-invalid-init= ialization-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 librari= es > > 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 should be imported in > 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 of lldiv_t, et. al. > AC_MSG_CHECKING([for ISO C99 support in for C++11]) > AC_CACHE_VAL(glibcxx_cv_c99_stdlib_cxx11, [ > GCC_TRY_COMPILE_OR_LINK( > [#include > volatile float f; > volatile long double ld; > volatile unsigned long long ll; > lldiv_t mydivt;], > [char* tmp; > f =3D strtof("gnu", &tmp); > ld =3D strtold("gnu", &tmp); > ll =3D strtoll("gnu", &tmp, 10); > ll =3D strtoull("gnu", &tmp, 10); > ll =3D llabs(10); > mydivt =3D lldiv(10,1); > ll =3D mydivt.quot; > ll =3D mydivt.rem; > ll =3D atoll("10"); > _Exit(0); > ], [glibcxx_cv_c99_stdlib_cxx11=3Dyes], > [glibcxx_cv_c99_stdlib_cxx11=3Dno]) > ]) > AC_MSG_RESULT($glibcxx_cv_c99_stdlib_cxx11) > if test x"$glibcxx_cv_c99_stdlib_cxx11" =3D x"yes"; then > AC_DEFINE(_GLIBCXX11_USE_C99_STDLIB, 1, > [Define if C99 functions or macros in should be import= ed > in in namespace std for C++11.]) > fi > --8<---------------cut here---------------end--------------->8--- > > We should check what=E2=80=99s going on! > > Thanks, > Ludo=E2=80=99. > --000000000000090abf05aa28ca97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ludo,

Tha= nks for reproducing this. Did you take a look at a resolution beyond your a= nalysis in this message? It would seem that the attempted compilation isn&#= 39;t working during the configure phase.=C2=A0

<= /div>
Erik

On Wed, Jun 10, 2020, 17:18 Ludovic= Court=C3=A8s <ludo@gnu.org> wrot= e:
Hi,

Erik Garrison <erik.garrison@gmail.com> skribis:

> I've run into a quirk in the various gcc toolchains that seems som= ewhat
> 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 ar= e
> enabled by _GLIBCXX_USE_C99_STDLIB are not available on guix gcc toolc= hains
> 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) {
>=C2=A0 =C2=A0 =C2=A0std::string::const_iterator s =3D c;
>=C2=A0 =C2=A0 =C2=A0while (c !=3D end and isdigit(*c)) ++c;
>=C2=A0 =C2=A0 =C2=A0if (c > s) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return std::stoull(std::string(s,c));=
>=C2=A0 =C2=A0 =C2=A0} else {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0;
>=C2=A0 =C2=A0 =C2=A0}
> }
>
> int main(int argc, char** argv) {
>=C2=A0 =C2=A0 =C2=A0std::string s(argv[1]);
>=C2=A0 =C2=A0 =C2=A0std::string::const_iterator b =3D s.begin();
>=C2=A0 =C2=A0 =C2=A0std::string::const_iterator e =3D s.end();
>=C2=A0 =C2=A0 =C2=A0std::cout << _parse_number(b, e) << std= ::endl;
>=C2=A0 =C2=A0 =C2=A0return 0;
> }
>
> Compiling with (g++ --version =3D=3D 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=C2=A0 =C2=A0Jun 08 2020 00:30:31=C2=A0 =C2=A0 (nuna)
=C2=A0 guix e782756
=C2=A0 =C2=A0 repository URL: https://git.savann= ah.gnu.org/git/guix.git
=C2=A0 =C2=A0 branch: master
=C2=A0 =C2=A0 commit: e78275608065ef073775fabb9f1a757da65851f2
$ guix environment=C2=A0 --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>'}=C2=A0 =C2=A0
=C2=A0 =C2=A0 9 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return std::stoull(std::= string(s,c));
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~= ~~
--8<---------------cut here---------------end--------------->8---

This is indeed fixed with:

=C2=A0 guix environment=C2=A0 --ad-hoc gcc-toolchain@9 -C -- g++ -D_GLIBCXX= _USE_C99_STDLIB=3D1 num.cpp

> This behavior appears to be similar to this issue:
> http= ://freebsd.1045724.x6.nabble.com/base-gcc-and-GLIBCXX-USE-C99-td5781697.htm= l.
> 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 conversion= s.
> However, I'm concerned that if gcc is built differently in guix th= an it
> typically is in other distributions, we will need to patch many librar= ies
> when building them on guix. It's probably better to match typical<= br> > expectations of developers about the behavior of gcc.

I agree, it seems we have a misconfiguration issue leading to=C2=A0 this in=
our c++config.h:

--8<---------------cut here---------------start------------->8---
/* Define if C99 functions or macros in <stdlib.h> should be imported= in
=C2=A0 =C2=A0<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---
=C2=A0 =C2=A0 # Check for the existence in <stdlib.h> of lldiv_t, et.= al.
=C2=A0 =C2=A0 AC_MSG_CHECKING([for ISO C99 support in <stdlib.h> for = C++11])
=C2=A0 =C2=A0 AC_CACHE_VAL(glibcxx_cv_c99_stdlib_cxx11, [
=C2=A0 =C2=A0 =C2=A0 GCC_TRY_COMPILE_OR_LINK(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [#include <stdlib.h>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0volatile float f;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0volatile long double ld;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0volatile unsigned long long ll;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lldiv_t mydivt;],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [char* tmp;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f =3D strtof("gnu", &tmp);<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ld =3D strtold("gnu", &tmp)= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ll =3D strtoll("gnu", &tmp,= 10);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ll =3D strtoull("gnu", &tmp= , 10);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ll =3D llabs(10);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mydivt =3D lldiv(10,1);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ll =3D mydivt.quot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ll =3D mydivt.rem;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ll =3D atoll("10");
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_Exit(0);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ], [glibcxx_cv_c99_stdlib_cxx11=3Dyes], [glibcx= x_cv_c99_stdlib_cxx11=3Dno])
=C2=A0 =C2=A0 ])
=C2=A0 =C2=A0 AC_MSG_RESULT($glibcxx_cv_c99_stdlib_cxx11)
=C2=A0 =C2=A0 if test x"$glibcxx_cv_c99_stdlib_cxx11" =3D x"= yes"; then
=C2=A0 =C2=A0 =C2=A0 AC_DEFINE(_GLIBCXX11_USE_C99_STDLIB, 1,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Define if C99 functions or macros in <stdli= b.h> should be imported
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in <cstdlib> in namespace std for C++11.]= )
=C2=A0 =C2=A0 fi
--8<---------------cut here---------------end--------------->8---

We should check what=E2=80=99s going on!

Thanks,
Ludo=E2=80=99.
--000000000000090abf05aa28ca97--