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

2020-07-11 Thread Erik Garrison
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  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 = 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::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=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  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 = strtof("gnu", );
>  ld = strtold("gnu", );
>  ll = strtoll("gnu", , 10);
>  ll = strtoull("gnu", , 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  should be imported
> in  in namespace std for C++11.])
> fi
> --8<---cut here---end--->8---
>
> We should check what’s going on!
>
> Thanks,
> Ludo’.
>


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

2020-06-09 Thread Erik Garrison
Hello guix-devel,

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 = 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

Yields this error:

test-stoull.cpp: In function ‘uint64_t
_parse_number(std::__cxx11::basic_string::const_iterator&, const
const_iterator&)’:
test-stoull.cpp:13: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’}
   13 | return std::stoull(std::string(s,c));
  | ^~~
In file included from /home/erikg/.guix-profile/include/c++/string:55,
 from
/home/erikg/.guix-profile/include/c++/bits/locale_classes.h:40,
 from
/home/erikg/.guix-profile/include/c++/bits/ios_base.h:41,
 from /home/erikg/.guix-profile/include/c++/ios:42,
 from /home/erikg/.guix-profile/include/c++/ostream:38,
 from /home/erikg/.guix-profile/include/c++/iostream:39,
 from test-stoull.cpp:1:
/home/erikg/.guix-profile/include/c++/bits/basic_string.h:6697:25: note: in
passing argument 1 of ‘long long unsigned int std::__cxx11::stoull(const
wstring&, std::size_t*, int)’
 6697 |   stoull(const wstring& __str, size_t* __idx = 0, int __base = 10)
  |  ~~~^

I understand that there might be concern about my particular .guix-profile,
but it's possible to reproduce this in containers. I can provide more test
cases if needed, but I just wanted to clarify in general what I'm seeing.

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.

Thanks in advance,

Erik