From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id mFszATL84F6rawAA0tVLHw (envelope-from ) for ; Wed, 10 Jun 2020 15:28:50 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 2AGJODH84F66FAAA1q6Kng (envelope-from ) for ; Wed, 10 Jun 2020 15:28:49 +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 6DB039404C5 for ; Wed, 10 Jun 2020 15:28:49 +0000 (UTC) Received: from localhost ([::1]:44752 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jj2em-0005qg-0N for larch@yhetil.org; Wed, 10 Jun 2020 11:28:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jj2Us-0007GM-G7 for guix-devel@gnu.org; Wed, 10 Jun 2020 11:18:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42340) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jj2Us-0002GV-4A; Wed, 10 Jun 2020 11:18:34 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=37060 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jj2Ur-0005rw-GH; Wed, 10 Jun 2020 11:18:33 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Erik Garrison Subject: Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull References: X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 23 Prairial an 228 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Wed, 10 Jun 2020 17:18:31 +0200 In-Reply-To: (Erik Garrison's message of "Tue, 9 Jun 2020 11:45:52 +0200") Message-ID: <87eeqndk54.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=none; dmarc=none; 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: -1.01 X-TUID: nazE5hEVxbgu 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 toolchai= ns > 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 wst= ring&' {aka 'const std::__cxx11::basic_string&'} from expression o= f type 'std::string' {aka 'std::__cxx11::basic_string'}=20=20=20 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_S= TDLIB=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 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 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_cxx1= 1=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 imported 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.