Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull

[Erik Garrison <erik.garrison@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5163 bytes --]

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ès <ludo@gnu.org> wrote:

> 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’.
>

[-- Attachment #2: Type: text/html, Size: 6870 bytes --]