Bug 40278 - -std=c++0x is error, but -std=gnu++0x is OK!
Summary: -std=c++0x is error, but -std=gnu++0x is OK!
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.4.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-28 00:23 UTC by Yuchen Deng
Modified: 2012-05-13 22:37 UTC (History)
4 users (show)

See Also:
Host: mingw32
Target: mingw32
Build: mingw32
Known to work:
Known to fail:
Last reconfirmed: 2012-01-16 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuchen Deng 2009-05-28 00:23:24 UTC
 
Comment 1 Yuchen Deng 2009-05-28 00:28:44 UTC
if use -std=c++0x, will error:

d:\ycdeng\qpdev\bin\..\lib\gcc\mingw32\4.4.1\include\c++\cwchar|159|error: '::swprintf' has not been declared|
d:\ycdeng\qpdev\bin\..\lib\gcc\mingw32\4.4.1\include\c++\cwchar|166|error: '::vswprintf' has not been declared|
||=== Build finished: 2 errors, 0 warnings ===|

if want fix, need #undef __STRICT_ANSI__, see: stdio.h
or option is: -U__STRICT_ANSI__

but when change to: -std=gnu++0x, it's OK!

Comment 2 Andrew Pinski 2009-05-28 00:31:21 UTC
This sounds like a bug in mingw's stdio.h and not GCC.
Comment 3 Yuchen Deng 2009-05-28 00:48:19 UTC
(In reply to comment #2)
> This sounds like a bug in mingw's stdio.h and not GCC.

But why -std=gnu++0x is OK? 
Only -std=c++0x error?

So, I think: this is not MinGW's bug, it's GCC.
Comment 4 Andrew Pinski 2009-05-28 00:59:00 UTC
Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables __STRICT_ANSI__.  But the mingw headers don't know about C++0x standard so it does not know those functions should be enabled.
Comment 5 Yuchen Deng 2009-05-28 04:01:05 UTC
(In reply to comment #4)
> Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables
> __STRICT_ANSI__.  But the mingw headers don't know about C++0x standard so it
> does not know those functions should be enabled.
> 

Oh. I see. Thanks!
I report this bug to MinGW project term now.

Comment 6 Danny Smith 2009-05-28 08:26:42 UTC
(In reply to comment #4)
> Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables
> __STRICT_ANSI__.  But the mingw headers don't know about C++0x standard so it
> does not know those functions should be enabled.
> 

mingw does not yet provide ANSI (c99) compliant swprintf or vswprintf implementations. The functions it does provide, _swprintf and _vswprintf, are pre-c99 MSVCRT implementations.

Danny
Comment 7 Paolo Carlini 2009-05-28 09:10:22 UTC
We had a similar issue elsewhere (see [GLIBCXX_CHECK_C99_TR1]). Essentially, the issue has nothing to do with C++0x, instead with GNU mode vs strict ansi mode, and as such is actually *very* old: appears also for -std=c++98 vs -std=gnu++98, but often it's not noticed because people don't use -std=c++98 very often, as far as I know. The point is simply that the configure check for those functions, in [GLIBCXX_ENABLE_WCHAR_T] is carried out with the default C++ compiler, thus including the GNU extensions, that is the -std=gnu++98 behavior. In linux, both modes enable the same wchar_t functions, but that doesn't happen for mingw, apparently. Is this expected? If you want me to change the configure test to use -std=c++98 just let me know.
Comment 8 Paolo Carlini 2009-05-28 09:14:37 UTC
Just wanted to add, that eventually, the new C++ standard will be known to the libc implementations, thus the fact that in it the C99 functions are part of the strict ansi mode of operation. This isn't really something we can or should discuss here.
Comment 9 Paolo Carlini 2010-02-18 10:00:44 UTC
Dave, what do you recommend about this issue? Does it affect cygwin too?
Comment 10 Paolo Carlini 2010-02-18 10:12:47 UTC
In short, I see two conceptually separate issues: 1- We run the configure tests for those functions in GNU mode, thus if on a target an header doesn't declare some functions in ISO strict mode, the user experiences puzzling errors, like in Comment #1; 2- Specific to MingW (and Cygwin too?!?), those C99 names do not correspond to functions implementing the actual C99 semantics, arguably should indeed not be exposed in strict ISO mode.

Thus, my doubt is: should we actually run those configure tests in strict ISO mode, instead of GNU mode? For Linux would not make a difference, and would avoid puzzling errors like those experienced by MingW users. However, I'm afraid some users, on other systems, could be disappointed in finding fewer functions declared in the C++ headers (in namespace std) in GNU mode (which is the default!)
Comment 11 Dave Korn 2010-02-18 12:54:27 UTC
(In reply to comment #9)
> Dave, what do you recommend about this issue? Does it affect cygwin too?
> 

This particular problem doesn't occur on cygwin, but we've had similar issues in the past with pre-c99 headers on cygwin (arising from newlib), although it was easier there, since we did actually have the functionality available, so just had to change the headers to make sure it was declared in __STRICT_ANSI__ mode.

I don't know how the MinGW guys would best like to go about tackling this, but I'd certainly not suggest changing the configury for /all/ hosts.  Adding a host-specific CFLAGs entry during the configure tests would be one way of handling it at the compiler end.  Adding the required support in the mingw library will be the ultimate way of handling it.  A third option would be for mingw to alias their current _(v)swprintf implementations to the required names as a stop-gap measure, on the grounds that since the resulting compiler/toolchain is going to be not fully conformant anyway until the functions are added, a slightly sub-spec implementation is preferable to an entirely missing one.

Danny, it's your call.
Comment 12 Kai Tietz 2012-01-16 09:49:14 UTC
Hmm, this issue doesn't occure with mingw-w64 for 32-bit or 64-bit.  This is related to the fact that mingw-w64 provides also the wide-character printf/scanf family in unix-way.

So I would suggest to close this bug here, as it is a mingw.org runtime issue.
Comment 13 Manuel López-Ibáñez 2012-05-13 22:37:45 UTC
Closed per comment #12