Bug 52015 - std::to_string does not work under MinGW
Summary: std::to_string does not work under MinGW
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.6.1
: P3 normal
Target Milestone: 4.8.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 59076 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-01-27 09:11 UTC by Nathan Ridge
Modified: 2014-02-27 07:21 UTC (History)
7 users (show)

See Also:
Host:
Target: *-*-mingw32
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-02-27 00:00:00


Attachments
Enabling string conversion functions in MinGW (11.57 KB, application/octet-stream)
2012-09-13 17:33 UTC, Lukas Dürrenberger
Details
initilal file (278 bytes, text/x-csrc)
2014-02-27 07:16 UTC, Roman
Details
yeld without -std=c++11 (51.74 KB, text/plain)
2014-02-27 07:19 UTC, Roman
Details
yeld with -std=c++11 (61.14 KB, text/plain)
2014-02-27 07:20 UTC, Roman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Ridge 2012-01-27 09:11:46 UTC
The std::to_string functions are guarded by !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF). MinGW defines this symbol as 1 in its os_defines.h, with a comment pointing to:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522

That bug was marked as "resolved" over three years ago, but the fix was just to add this guard, not to actually get the functions to work.

Can this be fixed so that the to_string functions work on MinGW?
Comment 1 Paolo Carlini 2012-01-27 10:47:04 UTC
Kai, is this fixed for 4.7.0?
Comment 2 Nathan Ridge 2012-02-27 16:48:41 UTC
*Ping*

Could this please be fixed for 4.7?
Comment 3 Jonathan Wakely 2012-02-27 17:18:41 UTC
Probably not since the trunk is in stage4. This isn't a regression and mingw isn't a primary target.

Someone with access to a mingw system would have to do it anyway, which as far as I know rules out all the libstdc++ maintainers.
Comment 4 Paolo Carlini 2012-02-27 18:00:55 UTC
I'm pretty sure that Kai / the target maintainers did some work to actually make available the underlying libc function on those systems, thus I can imagine that just tweaking a bit the configury could do the trick, and in that case a fix could go in for 4.7.1. Well, if Kai can tell us that the tweak is *really* trivial and totally restricted to MinGW, maybe even 4.7.0, conditional to release managers approval, of course.
Comment 5 Paolo Carlini 2012-02-27 18:06:52 UTC
PS (note to the library maintainers): if I remember correctly the resolution of some relatively recent DRs, these conversion functions have to do the work in any case in the C locale, thus we'll have to adopt here too the dance used in c_locale.cc / c_locale.h.
Comment 6 Kai Tietz 2012-02-27 18:14:55 UTC
(In reply to comment #4)
> I'm pretty sure that Kai / the target maintainers did some work to actually
> make available the underlying libc function on those systems, thus I can
> imagine that just tweaking a bit the configury could do the trick, and in that
> case a fix could go in for 4.7.1. Well, if Kai can tell us that the tweak is
> *really* trivial and totally restricted to MinGW, maybe even 4.7.0, conditional
> to release managers approval, of course.

Well, I thought about fixing this issue for 4.7 using mingw-w64's runtime.  It should be doable, as mingw-w64 provides also wide printf/scanf (and ansi scanf) functions with glibc behavior.  The dfp aren't supported there right now, but this is something we will come up in future. Also for 4.7 libstdc++ uses for mingw-w64 configure variant by default posix-compatible printf/scanf API.

I didn't found time to dive in more detail into this issue.
Comment 7 Paolo Carlini 2012-02-27 18:41:36 UTC
I see. Definitely post 4.7.0 then.
Comment 8 Lukas Dürrenberger 2012-09-13 17:31:13 UTC
As mentioned before this bug is still active in GCC 4.7.0.

The issue got additionally mentioned in the MinGW bug tracker: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3413241&group_id=2435

There's a possible patch for it at: http://tehsausage.com/mingw-to-string

Since it's not clear how long that website will be up, I'll post it here again:

______________________________________

24 August 2012, 11:16 UTC
This patch enables the following list of C++11 functions and templates in the std namespace:
stoi, stol, stoul, stoll, stof, stod, stold, to_string, to_wstring

This assumes you are using the official MinGW distribution.
If you are applying this patch to a version of MinGW GCC later than 4.7, you should examine and apply the patches rather than using the zip file.

* Download mingw-to-string-gcc47.zip which contains three patched header files.
(Original patches: wchar.h, stdio.h, os_defines.h)

* Copy wchar.h and stdio.h from the include directory in the zip file to the following directory (overwrite):
C:\mingw\include
(replace C:\mingw\ with the appropriate directory)

* Copy os_defines.h to the following directory (overwrite):
C:\mingw\lib\gcc\mingw32\4.7.0\include\c++\mingw32\bits
(replace C:\mingw\ with the appropriate directory)
(replace 4.7.0 with the correct version number)

Author: Julian Smythe
Comment 9 Lukas Dürrenberger 2012-09-13 17:33:51 UTC
Created attachment 28191 [details]
Enabling string conversion functions in MinGW

Patch from: http://tehsausage.com/mingw-to-string
Comment 10 Paolo Carlini 2012-09-13 22:14:32 UTC
Patch should be sent to the gcc-patches (and libstdc++) mailing list (any contributor must have a Copyright assignment on file, of course)
Comment 11 Earnie 2012-10-23 12:44:35 UTC
Ping.  What is the status of this issue?  Will it ever get any resolution?
Comment 12 Manuel López-Ibáñez 2012-10-23 13:05:40 UTC
(In reply to comment #11)
> Ping.  What is the status of this issue?  Will it ever get any resolution?

Only if someone who cares enough about this issue steps up and does the work. That could be you: http://gcc.gnu.org/contribute.html

The patch attached here is not a proper fix, as stated by its author:

"Also as stated in an email reply sent to someone regarding gcc bug #52015, this is not a proper MinGW patch. It can break existing programs using the Windows versions of [v]swprintf (as it replaces them with the standard signatures), might(?) cause problems if the functions aren't inlined, and it is applied to post-build MinGW so it cannot be guaranteed that future libstdc++ changes won't make enabling this impossible. The patch is also missing a call to __builtin_va_end." http://tehsausage.com/mingw-to-string
Comment 13 Jonathan Wakely 2012-10-23 13:10:40 UTC
(In reply to comment #9)
> Created attachment 28191 [details]
> Enabling string conversion functions in MinGW
> 
> Patch from: http://tehsausage.com/mingw-to-string

That's a zip file, not a patch. I've fixed the attachment details.

Maybe tehsausage's alternative implementations could be used under different names so they don't replace the system functions, and have mingw use those alternative names. The changes don't look significant enough to need a copyright assignment/disclaimer anyway, they just forward from one function to another.

The configure check that sets _GLIBCXX_HAVE_BROKEN_VSWPRINTF could check for working _vsnwprintf and make that usable instead.
Comment 14 Jonathan Wakely 2012-10-31 11:20:08 UTC
patch posted to http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02544.html

stay tuned
Comment 15 Kai Tietz 2012-11-29 14:17:37 UTC
My ok JonY has for the patch of 4.8.  It is related to a fix present upstream in mingw-w64 about snprintf-arguments for POSIX-mode.  So I don't intend to have this patch backported to 4.7, nor I think we can enable feature for none mingw-w64 targets due differences in venture's implementations.

It would be good if a c++-maintainer could comment on http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02711.html

Kai
Comment 16 Paolo Carlini 2012-11-29 14:24:44 UTC
Already in mainline:

2012-10-31  Jonathan Yong  <jon_y@users.sourceforge.net>

	* config/os/mingw32-w64/os_defines.h: Do not define anymore
	_GLIBCXX_HAVE_BROKEN_VSWPRINTF.

If a backport isn't expected, please just close as fixed for 4.8.0.
Comment 17 Kai Tietz 2012-11-29 14:30:15 UTC
(In reply to comment #16)
> Already in mainline:
> 
> 2012-10-31  Jonathan Yong  <jon_y@users.sourceforge.net>
> 
>     * config/os/mingw32-w64/os_defines.h: Do not define anymore
>     _GLIBCXX_HAVE_BROKEN_VSWPRINTF.

Thanks for the head's up.  I was just looking at ML's thread and thought it would be still pending.
 
> If a backport isn't expected, please just close as fixed for 4.8.0.

Yes, there won't be a backport from my side, so closing report.
Comment 18 Jonathan Wakely 2012-11-29 14:40:50 UTC
(In reply to comment #17)
> Thanks for the head's up.  I was just looking at ML's thread and thought it
> would be still pending.

Sorry, I broke the thread by replying to a different post, because the patch wasn't originally posted to the libstdc++ list.
It continued at http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02886.html
Comment 19 niXman 2013-01-05 21:24:03 UTC
Why not apply to gcc-4_7-branch?
Comment 20 Jonathan Wakely 2013-01-06 01:44:28 UTC
(In reply to comment #19)
> Why not apply to gcc-4_7-branch?

A user who can build 4.7.2 successfully should not have to update their OS to build 4.7.3
Comment 21 Nathan Ridge 2013-01-06 02:07:40 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > Why not apply to gcc-4_7-branch?
> 
> A user who can build 4.7.2 successfully should not have to update their OS to
> build 4.7.3

Huh? What requires updating your OS?
Comment 22 Jonathan Wakely 2013-01-06 11:31:03 UTC
OS wasn't the right term, but you need to update mingw32-w64 to a recent version from trunk. That requirement is not suitable for a release branch.
Comment 23 Tomalak Geret'kal 2013-10-21 16:49:30 UTC
Nathan, read comment 15. :)
Comment 24 Matan 2013-11-01 08:41:59 UTC
just downloaded mingw32 version 4.8.1, and it still doesn't seem to be fixed. Still getting error: 'to_string' is not a member of 'std'.

Status should be changed? ..
Comment 25 Jonathan Wakely 2013-11-01 10:39:39 UTC
See comment 15 - it's only fixed if you use mingw-w64, and is not possible to fix for mingw
Comment 26 Keith Marshall 2013-11-03 13:18:32 UTC
(In reply to Jonathan Wakely from comment #25)
> See comment 15 - it's only fixed if you use mingw-w64, and is not possible
> to fix for mingw

Not possible?  I doubt that.  If you need the participation of (one of) the developers at MinGW.org -- to implement support in our runtime library, for example -- you have only to ask.

Of course, if you restrict your communications to within your own little clique, a solution is less likely to be forthcoming.
Comment 27 Paolo Carlini 2013-11-03 13:47:57 UTC
I'm pretty sure that nobody here is artificially restricting communications. Most of us simply don't know enough about mingw and trust our target maintainers (Kai, Christopher, and Dave). I think that in general this is a sensible way to manage a large project like GCC. I'm adding Christopher and Dave too in CC, anyway.
Comment 28 Kai Tietz 2013-11-03 13:58:17 UTC
Nobody restricts here any communications.  The description in comment #15 is right now describing just the facts.  That nobody of the mingw.org team is active on gcc-upstream, is for sure not gcc's community problem.
You misjudge your importance pretty much.  It is not up to gcc-community to involve you.  Nobody waits for you, nor miss you ...
Actual your clique might want to be more active on suggestions, providing improvements, patches, new features, etc for mingw 32-bit target ... but this we hadn't seen for long time now.

So the conclusion of all here is my advice for you:  "si tacuisses philosophus mansisses".  Try to bring things forward, not blaming others for your ignorance.
Comment 29 Keith Marshall 2013-11-03 14:14:23 UTC
(In reply to Kai Tietz from comment #28)
> Nobody restricts here any communications.  The description in comment #15 is
> right now describing just the facts.  That nobody of the mingw.org team is
> active on gcc-upstream, is for sure not gcc's community problem.
> You misjudge your importance pretty much.  It is not up to gcc-community to
> involve you.  Nobody waits for you, nor miss you ...
> Actual your clique might want to be more active on suggestions, providing
> improvements, patches, new features, etc for mingw 32-bit target ... but
> this we hadn't seen for long time now.
> 
> So the conclusion of all here is my advice for you:  "si tacuisses
> philosophus mansisses".  Try to bring things forward, not blaming others for
> your ignorance.

Precisely the sort of cliquey arrogance which I find so offensive, in GCC.

Not one of the three, named by Paolo, is in any way associated with MinGW.org, (the originator of the name MinGW, which you so gratuitously abuse).  Granted, MinGW.org could be more forthcoming in appointing a project liaison, but given this level of arrogant abuse, is it any wonder that none is stepping up to the plate?
Comment 30 Jonathan Wakely 2013-11-03 19:53:52 UTC
(In reply to Keith Marshall from comment #29)
> Granted, MinGW.org could be more forthcoming in appointing a
> project liaison, but given this level of arrogant abuse, is it any wonder
> that none is stepping up to the plate?

So do you expect GCC devs who don't even own a Windows machine to liase instead?
Not gonna happen, sorry.
Comment 31 Jonathan Wakely 2013-11-03 20:09:43 UTC
Or to put it another way, this bug only affects MinGW users, is blocked by a limitation in MinGW, and noone from MinGW has offered to do anything about it, but you're pointing fingers at GCC devs and saying there's a GCC clique?  Who is preventing MinGW devs joining this clique?

If you want to improve the situation I suggest not throwing around words like abuse, and instead gently correcting misunderstandings by demonstrating that this can indeed be fixed in MinGW.  But that fix probably has to come from MinGW.
Comment 32 Nathan Ridge 2013-11-03 23:21:35 UTC
(In reply to Jonathan Wakely from comment #31)
> Or to put it another way, this bug only affects MinGW users, is blocked by a
> limitation in MinGW, and noone from MinGW has offered to do anything about
> it, but you're pointing fingers at GCC devs and saying there's a GCC clique?
> Who is preventing MinGW devs joining this clique?

No one, but they need to know about issues like this in order to do something about them. Above you said that this was "not possible" to fix for mingw. If you really meant "this would require changes in the mingw runtime", perhaps you should have said that. Then, even if you are not motivated to approach the MinGW developers to effect such changes, someone else (e.g. me) could have.
Comment 33 Jonathan Wakely 2013-11-04 09:14:52 UTC
(In reply to Nathan Ridge from comment #32)
> No one, but they need to know about issues like this in order to do
> something about them.

It's been in the MinGW bug tracker for years, although now closed as "out of date"

> Above you said that this was "not possible" to fix for
> mingw.

It's not possible to fix in GCC without extraordinary effort for a single target, which is not going to happen. If a given target wants to support C++11 features then it needs to provide the necessary C99 features. This is not a GCC issue.

> If you really meant "this would require changes in the mingw
> runtime", perhaps you should have said that. Then, even if you are not
> motivated to approach the MinGW developers to effect such changes, someone
> else (e.g. me) could have.

Fine. How about some ACTUALLY DOES SOMETHING USEFUL instead of quibbling over the particular wording I used in a bugzilla comment?
Comment 34 Jonathan Wakely 2013-11-11 11:36:13 UTC
*** Bug 59076 has been marked as a duplicate of this bug. ***
Comment 35 Roman 2014-02-26 05:49:58 UTC
Tried to apply proposed patch for MinGW 4.8.1 and received no positive effect. Compiler tells about error : 'stoi' was not declared in this scope. Have any Idea how to fix it?
Comment 36 Jonathan Wakely 2014-02-26 09:59:54 UTC
(In reply to Roman from comment #35)
> Tried to apply proposed patch for MinGW 4.8.1 and received no positive
> effect. Compiler tells about error : 'stoi' was not declared in this scope.
> Have any Idea how to fix it?

Not enough information to be useful.

Did you even use -std=c++11 ? 

Noone here can debug your modified sources, you'll have to look into what is or isn't defined on your system after the patch. Try looking at the preprocessed source, for example.
Comment 37 Roman 2014-02-27 07:16:43 UTC
Created attachment 32220 [details]
initilal file
Comment 38 Roman 2014-02-27 07:19:19 UTC
Created attachment 32221 [details]
yeld without -std=c++11
Comment 39 Roman 2014-02-27 07:20:27 UTC
Created attachment 32222 [details]
yeld with -std=c++11
Comment 40 Roman 2014-02-27 07:21:09 UTC
(In reply to Jonathan Wakely from comment #36)
> (In reply to Roman from comment #35)
> > Tried to apply proposed patch for MinGW 4.8.1 and received no positive
> > effect. Compiler tells about error : 'stoi' was not declared in this scope.
> > Have any Idea how to fix it?
> 
> Not enough information to be useful.
> 
> Did you even use -std=c++11 ? 
Yes, shure.
> 
> Noone here can debug your modified sources, you'll have to look into what is
> or isn't defined on your system after the patch. Try looking at the
> preprocessed source, for example.
I'm not familiar with such a matter. Attached files are:
stoi.cpp is initial code
stoi_prep.cpp is result of g++ stoi.cpp -E > stoi_prep.cpp
stoi_prep11.cpp is result of g++ stoi.cpp -E -std=c++11 > stoi_prep11.cpp