unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* gcc-10 toolchain does not include string to numeric conversion functions like std::stoull
@ 2020-06-09  9:45 Erik Garrison
  2020-06-10 15:18 ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: Erik Garrison @ 2020-06-09  9:45 UTC (permalink / raw)
  To: guix-devel

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

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

Yields this error:

test-stoull.cpp: In function ‘uint64_t
_parse_number(std::__cxx11::basic_string<char>::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<wchar_t>&’} from
expression of type ‘std::string’ {aka ‘std::__cxx11::basic_string<char>’}
   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

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull
  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
  2020-07-11 11:30   ` Erik Garrison
  0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2020-06-10 15:18 UTC (permalink / raw)
  To: Erik Garrison; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull
  2020-06-10 15:18 ` Ludovic Courtès
@ 2020-07-11 11:30   ` Erik Garrison
  2020-07-13 14:21     ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: Erik Garrison @ 2020-07-11 11:30 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull
  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
  0 siblings, 2 replies; 6+ messages in thread
From: Ludovic Courtès @ 2020-07-13 14:21 UTC (permalink / raw)
  To: Erik Garrison; +Cc: guix-devel

Hi Erik,

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

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

Unfortunately I haven’t dug further.  Help welcome!

Thanks,
Ludo’.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull
  2020-07-13 14:21     ` Ludovic Courtès
@ 2020-07-13 16:37       ` Ekaitz Zarraga
  2020-07-15  6:48       ` Pjotr Prins
  1 sibling, 0 replies; 6+ messages in thread
From: Ekaitz Zarraga @ 2020-07-13 16:37 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel@gnu.org

Hi,

On Monday, July 13, 2020 4:21 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Unfortunately I haven’t dug further. Help welcome!
>
> Thanks,
> Ludo’.

I'd like to help but I don't know where to start (yet).
I've found the same issue in older gcc-toolchains. 9.3.0 and 8.4.0 also fail.

Many functions are affected, strtol, stoi... all have the same issue.

Looks _GLIBCXX_USE_C99_STDLIB is not set as you said so it fails to make any of these conversions from std::string.

Do you know any gcc version where this works?

Thanks


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: gcc-10 toolchain does not include string to numeric conversion functions like std::stoull
  2020-07-13 14:21     ` Ludovic Courtès
  2020-07-13 16:37       ` Ekaitz Zarraga
@ 2020-07-15  6:48       ` Pjotr Prins
  1 sibling, 0 replies; 6+ messages in thread
From: Pjotr Prins @ 2020-07-15  6:48 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

On Mon, Jul 13, 2020 at 04:21:33PM +0200, Ludovic Courtès wrote:
> Hi Erik,
> 
> Erik Garrison <erik.garrison@gmail.com> skribis:
> 
> > 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.
> 
> Unfortunately I haven’t dug further.  Help welcome!

_GLIBCXX_USE_C99_STDLIB is a build setting. This is not failing for
many Guix packages because we are building by default with an older
gcc.  I have been building with newer gcc's for ages, without issue,
and this appears to be recently introduced. 



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-07-15  6:48 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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