The following program prints "1", but it should print "199711", because __cplusplus should be so defined according to ISO C++ section 16.8 [cpp.predefined]. Release: gcc version 2.97 20010125 (experimental) Environment: i686-pc-linux-gnu with glibc 2.2 How-To-Repeat: #include <stdio.h> int main() { printf("%ld\n", __cplusplus); }
Responsible-Changed-From-To: unassigned->gdr Responsible-Changed-Why: Analyzed
State-Changed-From-To: analyzed->suspended State-Changed-Why: This is a known issue. Defining a standard conforming value for __cplusplus happens to break V3 owns implementation. This issue will addressed later. Thanks for your report. -- Gaby
From: pme@sources.redhat.com To: nobody@gcc.gnu.org, Jens.Maurer@gmx.net, gcc-gnats@gcc.gnu.org Cc: Subject: Re: c++/1773: Changed information Date: 25 Jan 2001 22:13:47 -0000 Synopsis: __cplusplus defined to 1, should be 199711L Priority: low Severity: non-critical Changed-When: Thu Jan 25 17:11:59 EST 2001 Changed-By: pme "Phil Edwards" <pme@sources.redhat.com> Changed-State-From-To: open->analyzed Changed-Why: Known problem. I experimented with having g++ set this to the correct value, but libstdc++-v3 (the new c++ lib) has lots of problems compiling on some platforms.
From: gdr@gcc.gnu.org To: bkoz@redhat.com, pme@sourceware.cygnus.com, Jens.Maurer@gmx.net, gcc-gnats@gcc.gnu.org, gdr@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: c++/1773 Date: 25 Jan 2001 22:58:57 -0000 Synopsis: __cplusplus defined to 1, should be 199711L Responsible-Changed-From-To: unassigned->gdr Responsible-Changed-By: gdr Responsible-Changed-When: Thu Jan 25 14:58:57 2001 Responsible-Changed-Why: Analyzed State-Changed-From-To: analyzed->suspended State-Changed-By: gdr State-Changed-When: Thu Jan 25 14:58:57 2001 State-Changed-Why: This is a known issue. Defining a standard conforming value for __cplusplus happens to break V3 owns implementation. This issue will addressed later. Thanks for your report. -- Gaby http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1773&database=gcc
From: Nathanael Nerode <neroden@twcny.rr.com> To: bkoz@redhat.com, gcc-gnats@gcc.gnu.org, Jens.Maurer@gmx.net, gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gdr@gcc.gnu.org, pme@sourceware.cygnus.com, gcc-prs@gcc.gnu.org Cc: Subject: Re: libstdc++/1773: __cplusplus defined to 1, should be 199711L Date: Wed, 12 Mar 2003 16:32:03 -0500 This is a very old report. What's the status now? It was suspended because the standard conforming value for __cplusplus broke libstdc++-v3 on many platforms. libstdc++-v3 and the C++ front end have both undergone dramatic changes and improvements. Can this be fixed now? --Nathanael
From: Benjamin Kosnik <bkoz@redhat.com> To: neroden@twcny.rr.com Cc: gcc-gnats@gcc.gnu.org, Jens.Maurer@gmx.net, gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gdr@gcc.gnu.org, pme@sourceware.cygnus.com, gcc-prs@gcc.gnu.org Subject: Re: libstdc++/1773: __cplusplus defined to 1, should be 199711L Date: Wed, 12 Mar 2003 18:23:59 -0600 On Wed, 12 Mar 2003 16:32:03 -0500 Nathanael Nerode <neroden@twcny.rr.com> wrote: >This is a very old report. What's the status now? It was suspended because >the standard conforming value for __cplusplus broke libstdc++-v3 on many >platforms. libstdc++-v3 and the C++ front end have both undergone dramatic >changes and improvements. Can this be fixed now? Sadly, this can't be fixed at the moment, at least on most platforms. For cross compilers using newlib, this was fixed some time back with the --enable-headers=c work done at the time of the QNX port. That is not the default configuration, however. One of the things blocking this is hardware, ie real access to up-to-date sun hardware with sunpro tools so I can see what is going on. The other issue is time: I don't have enough of it, and this is something I consider a lower priority than other issues. There were some patches in glibc-2.3.x that went in that may allow a more elegant solution for linux, but that work is not finished. best, benjamin
Do we know what platforms are causing problems and why? Also, are there more details on *why* this breaks things? Does it trigger incorrect behavior in system headers? If so, can we make a system-specific change, or perhaps better, a fixincludes fix? --Nathanael
Subject: Re: __cplusplus defined to 1, should be 199711L "neroden at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Do we know what platforms are causing problems and why? | | Also, are there more details on *why* this breaks things? I think most of the answers to your questions are contained in the archive. It was reported recently that a fix could be applied for solaris-2.9 only. | Does it trigger incorrect behavior in system headers? If so, can we make a | system-specific change, or perhaps better, a fixincludes fix? I don't think this is a case where we would like to use fixincludes hacks. Basically, some host (== target for the compiler) C libraries are made ISO C++ aware (solaris-2.[89] C headers are such an example) so that they are clean with respect to C++ rules. We, in V3 land, assume that most host C headers are not C++ aware and build our headers on that assumption. Many attempts were made in the past to correct those assumtpions. I believe Stephen Webb had worked in this area on the topic of "stagged headers". -- Gaby
Oh-kay. After doing my research, there seem to be the following cases: 1. C Headers which don't know anything about C++. For these, we can safely define __cplusplus correctly, since the system headers don't care about it. (Fixincludes does various things to make these C++-ready, as well.) 2. C Headers which know about C++ and do the right thing (Solaris 9, perhaps). For these, should be able to safely define __cplusplus correctly. 3. C Headers which know about C++ and do the *wrong* thing (Solaris 8 is the *only* reported version of this sort). Are we holding up the change for these? It sounds like it! The headers in category 3 are precisely the sort of thing which fixincludes is *supposed* to fix. For starters, it wouldn't be very hard to kill off everything inside their #if __cplusplus >= 199711L clauses using fixincludes (perhaps by replacing it with #if __DUMMY_BLAH_BLAH_BLAH >= 199711L). If that converted them to headers which could be used as "regular" C headers, that would do the trick. If that didn't do the trick, even more aggressive techniques could be used to eliminate C++-awareness from the headers.
Subject: Re: __cplusplus defined to 1, should be 199711L "neroden at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | The headers in category 3 are precisely the sort of thing which | fixincludes is *supposed* to fix. For starters, it wouldn't be very | hard to kill off everything inside their #if __cplusplus >= 199711L | clauses using fixincludes (perhaps by replacing it with #if | __DUMMY_BLAH_BLAH_BLAH >= 199711L). In fact, we would not like to kill those fine things. We just need to revise our logic for those headers. -- Gaby
Um. So the conclusion is that changing __cplusplus to 199711L, which should benefit everyone, is being postponed indefinitly *solely* because you want better treatment of Solaris 8 headers? Remember that Solaris 8 is the *only* platform causing trouble.
Subject: Re: __cplusplus defined to 1, should be 199711L "neroden at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Um. So the conclusion is that changing __cplusplus to 199711L, which should | benefit everyone, is being postponed indefinitly *solely* because you want | better treatment of Solaris 8 headers? You missed the point. I'm not sure we're going to reach anywhere with that start. | Remember that Solaris 8 is the *only* platform causing trouble. Don't be afraid that I'm forgetting bits.
> You missed the point. I'm not sure we're going to reach anywhere with > that start. No, he hasn't missed the point. The question in comment #11 is a legitimate one, based on this sequence of reasoning: Solaris 8 is the only (reported!) platform with the problem, other bugs are appearing because of g++'s wrong __cplusplus value, we /could/ fix the problem on Solaris 8 but have chosen not to. The question is exactly the point: "why are we holding back other platforms and other fixes for the sake of Solaris 8?" The answer up to now has been that, since Sol8's headers are correct C++, we should be able to use them directly without having to do any fixincl work on them at all. The problem is that their headers do something like this (via multiple headers not shown here): namespace std { proper_type size_t; // assume "proper_type" Does The Right Thing } #if __cplusplus >= 199711L using std::size_t; #endif Then, somewhere else in the path of things, g++ sees our own version of std::size_t, and pukes on the 'using' line with a "conflicting declaration" error. It's been a while since I tried it, but the exact analysis is in the archives somewhere. The /ideal/ solution -- and the solution which Gaby and I and others have been hoping for -- is either to notice the Sol8 correct declarations and not do anything ourselves, or to look at the conflict, deduce that proper_type is in fact the proper type, and conclude that there isn't a conflict. Using fixincludes to hack up correct headers because g++ isn't quite smart enough is a mistake in this case. However, the bug has been there for over two years. Sun has moved on and made things different in Sol9 apparently (haven't seen the 9 headers myself). Nobody has volunteered a fix for g++. We may simply have to throw in the towel on this issue and run Sol8 through fixincludes. > | Remember that Solaris 8 is the *only* platform causing trouble. > > Don't be afraid that I'm forgetting bits. "(Remember|Recall) that <point of observation>" is just an English-language rhetorical technique used to bring a statement full circle. No one is questioning anyone's memory, especially when the entire audit trail is present on the screen.
Subject: Re: __cplusplus defined to 1, should be 199711L "pme at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | > You missed the point. I'm not sure we're going to reach anywhere with | > that start. | | No, he hasn't missed the point. Sure he missed the point. To see why you need to consider the whole previous comments. He proposed to use fixinclude hacks to remove stuff from "headers that are C++ correct" (borrowing words from you). I told him that in reality, we don't want to remove those fine things. We just want to change our logic about those headers. He jumped to the conclusion: So the conclusion is that changing __cplusplus to 199711L, which should benefit everyone, is being postponed indefinitly *solely* because you want better treatment of Solaris 8 headers? which just missed the point I was making. I was not telling him that we should indefinitely postpone better treatements: I was point out the the approach he proposed to the solaris 8 is not correct. I would help if people could refrain from jumping to quick conclusions, especially confused ones phrased as above. [...] | Then, somewhere else in the path of things, g++ sees our own version of | std::size_t, and pukes on the 'using' line with a "conflicting declaration" | error. It's been a while since I tried it, but the exact analysis is in | the archives somewhere. That is why I said we should change our logic about those headers. | The /ideal/ solution -- and the solution which Gaby and I and others have | been hoping for -- is either to notice the Sol8 correct declarations and not | do anything ourselves, or to look at the conflict, deduce that proper_type | is in fact the proper type, and conclude that there isn't a conflict. Using | fixincludes to hack up correct headers because g++ isn't quite smart enough | is a mistake in this case. Up to this point we're on the same page. The above is what I conveyed in "I don't think this is a case where would like to use fixincludes hacks". | However, the bug has been there for over two years. Sun has moved on and | made things different in Sol9 apparently (haven't seen the 9 headers myself). | Nobody has volunteered a fix for g++. We may simply have to throw in the | towel on this issue and run Sol8 through fixincludes. There is an alternate option: Define __cplucplus on target (os or cpu) basis. For example have V3/config/os/generic/os_defines.h define __cplusplus to the correct value (which should be something higher than 199711l, I don't recall the exact value) and have solaris8 override it. | > | Remember that Solaris 8 is the *only* platform causing trouble. | > | > Don't be afraid that I'm forgetting bits. | | "(Remember|Recall) that <point of observation>" is just an English-language | rhetorical technique used to bring a statement full circle. No one is | questioning anyone's memory, especially when the entire audit trail is | present on the screen. "not to forget" is an English-language rhetorical technique use to say that one has statements/facts in full circle. I'm not saying he is questioning my memory. -- Gaby
Subject: Re: __cplusplus defined to 1, should be 199711L > Sure he missed the point. To see why you need to consider the whole > previous comments. I disagree, but we'll leave it at that. > There is an alternate option: Define __cplucplus on target (os or > cpu) basis. For example have V3/config/os/generic/os_defines.h define > __cplusplus to the correct value (which should be something higher > than 199711l, I don't recall the exact value) and have solaris8 > override it. 199711L is the value called for by 14882. Are we permitted to use higher values? How would a V3 header file help us here? None of our headers are used.
Subject: Re: __cplusplus defined to 1, should be 199711L "phil at jaj dot com" <gcc-bugzilla@gcc.gnu.org> writes: | PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. | | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 | | | | ------- Additional Comments From phil at jaj dot com 2003-08-04 08:17 ------- | Subject: Re: __cplusplus defined to 1, should be 199711L | | > Sure he missed the point. To see why you need to consider the whole | > previous comments. | | I disagree, but we'll leave it at that. Sure, as I said in the previous comment you were replying to, I do not think we're going to reach anywhere with that start. | > There is an alternate option: Define __cplucplus on target (os or | > cpu) basis. For example have V3/config/os/generic/os_defines.h define | > __cplusplus to the correct value (which should be something higher | > than 199711l, I don't recall the exact value) and have solaris8 | > override it. | | 199711L is the value called for by 14882. Are we permitted to use higher | values? TC1 has been made part of C++, now know as C++2003. I do not have the new definition oin my laptop right now. | How would a V3 header file help us here? None of our headers are used. Used for what? -- Gaby
Subject: Re: __cplusplus defined to 1, should be 199711L > | 199711L is the value called for by 14882. Are we permitted to use higher > | values? > > TC1 has been made part of C++, now know as C++2003. I do not have the > new definition oin my laptop right now. Has TC1 actually been published yet?
Subject: Re: __cplusplus defined to 1, should be 199711L "phil at jaj dot com" <gcc-bugzilla@gcc.gnu.org> writes: | > | 199711L is the value called for by 14882. Are we permitted to use higher | > | values? | > | > TC1 has been made part of C++, now know as C++2003. I do not have the | > new definition oin my laptop right now. | | Has TC1 actually been published yet? Here is the info I do know for sure http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1458.html (specifically 2.2.1). And I do know that many other implementors have already integrated TC1 changes in their products (we too mostly do that on the library side). -- Gaby
Dudes. Fixing this is more involved than its been pointed out, which is why this bug is still around after two+ years. This is also a bug that can be fixed without impacting the ABI, which means it's decidedly lower priority at the moment. Back to this specific bug report. First of all, Solaris headers keep changing, and none of the v3 maintainers has access to all of 2.5/2.6/2.7/2.8/2.9 etc. In addition, I think only Phil has reliable acces to 2.9. Second of all, the Solaris 2.9 headers are correct, and are what the linux includes should be attempting. As Gaby pointed out, this is a problem with the C->C++ interface, and thus on linux involves a reasonable stab at "C" compatibility headers and C++ aware "C" includes. For some platforms (say newlib crosses and QNX) the "c" header strategy (as opposed to the current "c_std") solves this problem for platforms that don't use wchar_t or C99 features. There are at least three problems that need to be solved before this approach will work on linux, and this bug report can be closed. 1) _USE_GNU needs to be turned off in the g++ front end, and a more fine-grained approach needs to be used to bring in wchar_t functions. 2) the "C" includes have to be fitted into the eventual C++ compatibility headers (some work went in for glibc-2.3.x). 3) using the "c" model has to be made to work in the presence of C99 and wchar_t. -benjamin
Subject: Re: __cplusplus defined to 1, should be 199711L > In addition, I think only Phil has > reliable acces to 2.9. 2.8, and only for another two weeks.
OK, Ben, what exactly are you talking about? After a trawl through the mailing list archives, it appeared that there was no problem changing the value of __cplusplus on Linux. So either whatever problem you're referring to has not been reported or discussed in public... or you're trying to tackle a problem which is not directly connected to this bug.
Unsuspending for the time being.
*** Bug 13596 has been marked as a duplicate of this bug. ***
I think that there's a relatively simple solution to this problem: have the C++ front end define __cplusplus to 1, by default, but allow a target configuration to override that value. That would allow the systems where it works to definine it to 199711L to work. On other systems, leave it set to 1. Heck, I'll preapprove a patch to do that. Yes, it would be nice to take a more elegant approach with Solaris 8. If that is really the only system where that is a problem, and someone has a pointer to a description showing what goes wrong there, complete with a test case for me to play with, we can look at doing something smarter. But, I'm not sure I see the point in investing a lot of effort to fix something for an already somewhat old version of the OS. Benjamin raises other issues, such as definining _USE_GNU, and those are valid, but orthogonal.
Mark Mitchell wrote: >Yes, it would be nice to take a more elegant approach with Solaris 8. If that >is really the only system where that is a problem, That appears to be the case! As Phil Edwards wrote earlier: >The question is exactly the point: "why are we holding back other platforms >and other fixes for the sake of Solaris 8?" So I would like to suggest a different version of Mark's approach: define __cplusplus correctly (to 199711L) by default, and allow targets to override it. Then Solaris 8 can set it to 1. :-)
> So I would like to suggest a different version of Mark's approach: define > __cplusplus correctly (to 199711L) by default, and allow targets to override it. > Then Solaris 8 can set it to 1. :-) I'm up for this solution. -benjamin
A friend of mine was recently caught by this bug.. is there any chance it could be fixed now? or is there still some problem holding it up (or just no-one cares?). Although I am by no means certain, I imagine it's possible that this might be increased by the upcoming TR1 library, so it might be nice to get the value correct.
Subject: Re: __cplusplus defined to 1, should be 199711L "chris at bubblescope dot net" <gcc-bugzilla@gcc.gnu.org> writes: | A friend of mine was recently caught by this bug.. is there any | chance it could be fixed now? or is there still some problem holding | it up (or just no-one cares?). Although I am by no means certain, I | imagine it's possible that this might be increased by the upcoming | TR1 library, so it might be nice to get the value correct. question: is there any news from the solaris front or noboody really cares? -- Gaby
The following patch implements the suggested solution. Is it correct? I don't have access to any version of Solaris to check.
Created attachment 10303 [details] Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8
(In reply to comment #30) > Created an attachment (id=10303) [edit] > Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8 As-is, this cannot be right, because that file is shared between *all* the Solaris version besides 5 and 6. See configure.host around line 247. If I understand correctly Comment #8, the corrected default should be overriden *only* for Solaris 8. In general, I'm also in favor of this approach, we all agree about that (see Comment #24, 25, 26...). Therefore, my plan would be involving Eric for some tests on *all* the Solaris versions of an amended patch which really would deal specially with Solaris 8 only. It would involve adding a solaris2.8 dir in config/os/solaris, and tweaking configure.host to use the existing solaris2.7 dir for 2.7, 2.9, 2.10... , i.e., skipping 2.8, and the new 2.8 dir (getting the override) for 2.8 only. Are you willing to work on that?
Yes, I'll take a shot at this.
Created attachment 10307 [details] Defines __cplusplus to 199711L and overrides it for solaris 8 *only* Please see comment #33 before applying this patch.
I attached a patch containing Paolo's suggestions. It was produced with svn diff -x -up after an svn copy like this: pedro@localhost gcc] svn copy libstdc++-v3/config/os/solaris/solaris2.{7,8} "svn diff" doesn't contain this copy directly.
(In reply to comment #34) > I attached a patch containing Paolo's suggestions. Thanks. Looks fine to me. If Eric could test it on his Solaris machines it would be great (remember the svn copy! ;) ... Before finally committing it, probably we want to add a short comment before the undef in solaris/solaris2.8/os_defines.h
> Thanks. Looks fine to me. If Eric could test it on his Solaris machines it > would be great (remember the svn copy! ;) ... Sure. > Before finally committing it, probably we want to add a short comment before > the undef in solaris/solaris2.8/os_defines.h Yes, please *heavily* comment.
> Yes, please *heavily* comment. If this is approved, someone could do the copy on the relevant branches, then I'd send a patch with better comments and changelog to the gcc-patches list.
(In reply to comment #37) > > Yes, please *heavily* comment. > > If this is approved, someone could do the copy on the relevant branches, then > I'd send a patch with better comments and changelog to the gcc-patches list. Don't worry about that, as soon as Eric reports, I'll take care of the rest.
Eric, I'm sorry, any news?!? Thanks.
> Eric, I'm sorry, any news?!? Thanks. Bootstrap was broken last week and I was away for the week-end... I'll need to re-compute baseline results first, so maybe at the end of this week.
Ok, agreed. I'm eager to finally close the oldest open libstdc++ PR... ;)
Solaris 8 (32-bit compiler): gmake[3]: Entering directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' Making all in include gmake[4]: Entering directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include' gmake[4]: *** No rule to make target `/home/eric/svn/gcc/libstdc++-v3/config/os/solaris/solaris2.8/ctype_base.h', needed by `stamp-host'. Stop. gmake[4]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2 Solaris 9 (64-bit compiler): /opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/include/cstdlib: In function 'long int std::abs(long int)': /opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/include/cstdlib:131: error: redefinition of 'long int std::abs(long int)' /usr/include/iso/stdlib_iso.h:123: error: 'long int std::abs(long int)' previously defined here /opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/include/cstdlib: In function 'std::ldiv_t std::div(long int, long int)': /opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/include/cstdlib:134: error: redefinition of 'std::ldiv_t std::div(long int, long int)' /usr/include/iso/stdlib_iso.h:124: error: 'std::ldiv_t std::div(long int, long int)' previously defined here gmake[4]: *** [del_op.lo] Error 1 gmake[4]: Leaving directory `/opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3/libsupc++' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc64-sun-solaris2.9/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2 Solaris 10 (biarch compiler): /usr/include/iso/stdlib_iso.h:114: error: previous declaration of 'void* std::bsearch(const void*, const void*, std::size_t, std::size_t, int (*)(const void*, const void*))' with 'C' linkage /usr/include/iso/stdlib_iso.h:118: error: conflicts with new declaration with 'C++' linkage /usr/include/iso/stdlib_iso.h:134: error: previous declaration of 'void std::qsort(void*, std::size_t, std::size_t, int (*)(const void*, const void*))' with 'C' linkage /usr/include/iso/stdlib_iso.h:137: error: conflicts with new declaration with 'C++' linkage /opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/include/cstdlib: In function 'long int std::abs(long int)': /opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/include/cstdlib:131: error: redefinition of 'long int std::abs(long int)' /usr/include/iso/stdlib_iso.h:154: error: 'long int std::abs(long int)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/include/cstdlib: In function 'std::ldiv_t std::div(long int, long int)': /opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/include/cstdlib:134: error: redefinition of 'std::ldiv_t std::div(long int, long int)' /usr/include/iso/stdlib_iso.h:155: error: 'std::ldiv_t std::div(long int, long int)' previously defined here gmake[4]: *** [del_op.lo] Error 1 gmake[4]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3/libsupc++' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.10/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2
Hummm, probably there is something fundamentally wrong in the approach, because Solaris 8, at least, is supposed to not change at all, i.e., __cplusplus == 1...
Eric, as regards Solaris, 8, I think you forgot to do the svn copy, as per Comment #34 (and # 35 ;) Still, Solaris 9 and 10 are not fine, sigh, I'll try to look a bit more into that. Thanks, anyway.
> Eric, as regards Solaris, 8, I think you forgot to do the svn copy, as per > Comment #34 (and # 35 ;) Ah, sure, thanks. Now I get: /opt/build/eric/gcc/./gcc/xgcc -shared-libgcc -B/opt/build/eric/gcc/./gcc -nostdinc++ -L/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src -L/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/opt/build/eric/local/gcc/sparc-sun-solaris2.8/bin/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.8/lib/-isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.8/include -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.8/sys-include -I/home/eric/svn/gcc/libstdc++-v3/../gcc -I/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8 -I/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include -I/home/eric/svn/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c /home/eric/svn/gcc/libstdc++-v3/libsupc++/eh_globals.cc -fPIC -DPIC -o eh_globals.o /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:66: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:67: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:71: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:72: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:77: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:78: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:84: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:85: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:91: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:96: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:100: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:105: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:109: error: '__cxa_cdtor_type' has not been declared /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:114: error: '__cxa_cdtor_type' has not been declared gmake[3]: *** [eh_globals.lo] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/libsupc++' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake: *** [all-target-libstdc++-v3] Error 2
(In reply to comment #45) > > Eric, as regards Solaris, 8, I think you forgot to do the svn copy, as per > > Comment #34 (and # 35 ;) > > Ah, sure, thanks. Now I get: [snip] > /home/eric/svn/gcc/libstdc++-v3/libsupc++/eh_globals.cc -fPIC -DPIC -o > eh_globals.o > /home/eric/svn/gcc/libstdc++-v3/libsupc++/cxxabi.h:66: error: > '__cxa_cdtor_type' has not been declared Thanks. Sigh, double sigh. This makes sense and means that (irrespective of the issues with Sol 9 and 10) the suggested approach doesn't work, because the problems start already inside libsupc++, *not* only in libstdc++ proper, where we can easily put back __cplusplus to 1 in os_defines.h...
Any reason why libsupc++ can't include the stuff in config/ ? I'm interested in seeing this bug go, I'd work on it.
(In reply to comment #47) > Any reason why libsupc++ can't include the stuff in config/ ? > I'm interested in seeing this bug go, I'd work on it. I'm also interested, of course. In principle, libspuc++ can certainly do that, but you have to investigate a bit the best way to do that, consistently with the rest of the library. About Sol 9 and Sol 10, I'm rather surprised to see that the problems are still present. Personally, I would be in favor to just have __cplusplus == 1 on Sol >= 8, would be a progress for all the other targets, but it's a pity, isn't it?
(In reply to comment #48) > (In reply to comment #47) > > Any reason why libsupc++ can't include the stuff in config/ ? > > I'm interested in seeing this bug go, I'd work on it. > > I'm also interested, of course. In principle, libspuc++ can certainly do that, > but you have to investigate a bit the best way to do that, consistently with > the rest of the library. In fact, the libsupc++ files are *already* including <bits/c++config.h>, which is all we need. The problem in eh_globals.cc (also elsewhere? An audit is in order) seems only that it's included too late.
But there is something I don't understand at all: after a recent patch from Benjamin, eh_globals.cc now does include <bits/c++config.h> *first*! Therefore the problem seems different. At the beginning of eh_globals.cc __cplusplus is used but should not be seen different before/after the patch on Sol 8, always == 1 !?!
> But there is something I don't understand at all: after a recent patch from > Benjamin, eh_globals.cc now does include <bits/c++config.h> *first*! Therefore > the problem seems different. At the beginning of eh_globals.cc __cplusplus is > used but should not be seen different before/after the patch on Sol 8, always > == 1 !?! Humpf... +#ifdef __cplusplus +# undef __cplusplus +#endif +#define __cpluplus 1 I'm going to fix the typo and retest.
(In reply to comment #51) > +#define __cpluplus 1 ^ Gosh! Thanks Eric for noticing and further testing.
> Gosh! Thanks Eric for noticing and further testing. Hum... no changes on Solaris 9 and 10. On Solaris 8 I now get: /opt/build/eric/gcc/./gcc/xgcc -shared-libgcc -B/opt/build/eric/gcc/./gcc -nostdinc++ -L/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src -L/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -B/opt/build/eric/local/gcc/sparc-sun-solaris2.8/bin/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.8/lib/-isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.8/include -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.8/sys-include -I/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8 -I/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include -I/home/eric/svn/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c /home/eric/svn/gcc/libstdc++-v3/src/locale.cc -fPIC -DPIC -o .libs/locale.o /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'void* std::memchr(void*, int, std::size_t)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:101: error: redefinition of 'void* std::memchr(void*, int, std::size_t)' /usr/include/iso/string_iso.h:106: error: 'void* std::memchr(void*, int, std::size_t)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:102: error: invalid conversion from 'const void*' to 'void*' /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'char* std::strchr(char*, int)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:107: error: redefinition of 'char* std::strchr(char*, int)' /usr/include/iso/string_iso.h:80: error: 'char* std::strchr(char*, int)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'char* std::strpbrk(char*, const char*)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:113: error: redefinition of 'char* std::strpbrk(char*, const char*)' /usr/include/iso/string_iso.h:86: error: 'char* std::strpbrk(char*, const char*)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'char* std::strrchr(char*, int)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:119: error: redefinition of 'char* std::strrchr(char*, int)' /usr/include/iso/string_iso.h:92: error: 'char* std::strrchr(char*, int)' previously defined here /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring: In function 'char* std::strstr(char*, const char*)': /opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/include/cstring:125: error: redefinition of 'char* std::strstr(char*, const char*)' /usr/include/iso/string_iso.h:98: error: 'char* std::strstr(char*, const char*)' previously defined here /home/eric/svn/gcc/libstdc++-v3/src/locale.cc: At global scope: /home/eric/svn/gcc/libstdc++-v3/src/locale.cc:62: warning: missing braces around initializer for 'upad64_t [4]' /home/eric/svn/gcc/libstdc++-v3/src/locale.cc:181: warning: missing braces around initializer for 'upad64_t [4]' gmake[4]: *** [locale.lo] Error 1 gmake[4]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3/src' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.8/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [all] Error 2
(In reply to comment #53) > > Gosh! Thanks Eric for noticing and further testing. > > Hum... no changes on Solaris 9 and 10. Indeed, should still give problems. > On Solaris 8 I now get: I see what's going wrong: <bits/c++config.h> is not included before <cstring>, which needs it, needs __cplusplus == 1. Ok, Eric, I will ASAP do an audit, check that <bits/c++config.h> is everywhere included correctly, sufficiently early, fix all those issues, and only then bother you again for Sol. For now would be the same approach also for Sol 9 and newer. We can figure out something better for recent Sol later, by way of fixincludes or whatelse... Thanks again.
A few remarks on (really) defining __cplusplus to 199711L on solaris. One issue I already mentionned in libstdc++/27340 is some conflicts on names like std::__cos. An other issue is the fact that solaris (>=9) headers have (when __cplusplus is at least 199711L) already the correct c++ declarations for functions like wcschr or wcspbrk, so we would need a macro to disable all the extra definitions like: inline wchar_t* wcschr(wchar_t* __p, wchar_t __c) { return wcschr(const_cast<const wchar_t*>(__p), __c); } that are provided in the c* headers. This means all the overloaded math functions as well (except the non-standard integer versions, for which I always wished g++ would at least emit a warning). The headers (like stddef.h) provided by gcc and that take precedence over the solaris headers need to be patched to look more like the headers they are replacing. An other problem is that it breaks the ABI (a c++ function that takes a struct tm won't be mangled the same as one that takes a std::tm). It will break bad code that declares struct tm in the global namespace instead of including the standard headers (gtk+-1.2). If this were done, it would become quite easy to chose, each time we call g++, whether we want to use the gcc headers or headers that keep the global namespace clean, which is good :-)
(In reply to comment #30) > Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8 Out of curiosity, why not deal with __cplusplus the same way as __STDC__ (0 for standard headers and 1 elsewhere IIRC) instead, or even defining it to 1 directly for this platform? If I include stdlib.h (not cstdlib), I won't include c++config.h first, and it should cause trouble with this approach. (although I don't like the approach, which considers as broken the only platform that has correct headers, but that is a different issue)
Subject: Re: __cplusplus defined to 1, should be 199711L "marc dot glisse at normalesup dot org" <gcc-bugzilla@gcc.gnu.org> writes: | (In reply to comment #30) | > Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8 | | Out of curiosity, why not deal with __cplusplus the same way as __STDC__ (0 for | standard headers and 1 elsewhere IIRC) instead, or even defining it to 1 | directly for this platform? If I include stdlib.h (not cstdlib), I won't | include c++config.h first, and it should cause trouble with this approach. other standard headers might directly or indrectly include <cstdlib>, so any macro game should work properly. I see c++config.h as a "built-in" header that should be always there anyway we are processing a C++ program. -- Gaby
Request to re-assign to me. -benjamin
Subject: Re: __cplusplus defined to 1, should be 199711L "bkoz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Request to re-assign to me. Please, go ahead :-) -- Gaby
Mine. Current libcpp patch only is: Index: init.c =================================================================== --- init.c (revision 123196) +++ init.c (working copy) @@ -376,7 +376,7 @@ } if (CPP_OPTION (pfile, cplusplus)) - _cpp_define_builtin (pfile, "__cplusplus 1"); + _cpp_define_builtin (pfile, "__cplusplus 199711L"); else if (CPP_OPTION (pfile, lang) == CLK_ASM) _cpp_define_builtin (pfile, "__ASSEMBLER__ 1"); else if (CPP_OPTION (pfile, lang) == CLK_STDC94)
mine, try two
Subject: Re: __cplusplus defined to 1, should be 199711L "bkoz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | ------- Comment #60 from bkoz at gcc dot gnu dot org 2007-03-28 17:48 ------- | | Mine. | | Current libcpp patch only is: | | Index: init.c | =================================================================== | --- init.c (revision 123196) | +++ init.c (working copy) | @@ -376,7 +376,7 @@ | } | | if (CPP_OPTION (pfile, cplusplus)) | - _cpp_define_builtin (pfile, "__cplusplus 1"); | + _cpp_define_builtin (pfile, "__cplusplus 199711L"); | else if (CPP_OPTION (pfile, lang) == CLK_ASM) | _cpp_define_builtin (pfile, "__ASSEMBLER__ 1"); | else if (CPP_OPTION (pfile, lang) == CLK_STDC94) Yes, that is correct. I thought there was an issue with solaris boxes. Was that fixed? -- Gaby
There is no fix a the moment. However, I'm working on speculative fixes for newlib and linux, which are predicated on the correct __cplusplus values. I may get to solaris too, if my sanity stretches that far, or I may fail entirely, everywhere. However, I now think the current solaris headers are actually wrong , but differently than before. :( Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the namespace std versions of functions, and not also the global scoped ones. This is a problem. The way I read ISO C++, cstdlib should only have std:: scoped bits. The C++ compatibility include stdlib.h should then re-scope to :: (global). Solaris tries to smash these two concepts together. Boo. In theory it should be possible for ISO-C++ programs to have a clean global namespace. Or, mostly clean considering some stuff is in the global namespace by default (some new signatures, etc.: complete list in doxygen markup.) Anyway. Who knows if this is indeed possible, anyway? I'll try to find out what our options are and give current status at least. My RFC message about C++0x headers had the details on my implementation plan, I think.
(In reply to comment #63) > However, I'm working on speculative fixes for newlib and linux, which are > predicated on the correct __cplusplus values. I may get to solaris too, if my > sanity stretches that far, or I may fail entirely, everywhere. Weird, when solaris is the easiest one. > Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the > namespace std versions of functions, and not also the global scoped ones. #include <iso/stdlib_iso.h> (this is how sun studio compiler does it) If you also want the C99 functions, then you have to wait for the next c++ standard to actually exist before solaris changes its headers accordingly. > My RFC message about C++0x headers had the details on my implementation plan, > I think. Sorry for the dumb question, but where is it?
Subject: Re: __cplusplus defined to 1, should be 199711L > Weird, when solaris is the easiest one. That's certainly a matter of perspective. >> Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the >> namespace std versions of functions, and not also the global scoped ones. > > #include <iso/stdlib_iso.h> > > (this is how sun studio compiler does it) > If you also want the C99 functions, then you have to wait for the next c++ > standard to actually exist before solaris changes its headers accordingly. Ah. Thanks for pointing this out to me. Figuring out how to map these files correctly just for solaris will be interesting. >> My RFC message about C++0x headers had the details on my implementation plan, >> I think. > > Sorry for the dumb question, but where is it? Sorry, I cannot find this at the moment. The plan is to correct the includes/c implementation. -benjamin
Subject: Any progress on this? I just hit this (6 year old) bug today. Surely, there's got to be some possible fix for linux-2.6 (my current OS) that doesn't cause severe regressions in Solaris? Anyway, it looked like activity on this bug had stalled for a number of months, so I thought I'd bump it.
Sorry to come back to this again. With C++0x just around the corner, is there any chance of getting this fixed, seeing as I expect this should be the standard way of checking if we are in conforming C++0x mode, when it gets released?
(In reply to comment #63) > > Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the > namespace std versions of functions, and not also the global scoped ones. This > is a problem. The way I read ISO C++, cstdlib should only have std:: scoped > bits. The C++ compatibility include stdlib.h should then re-scope to :: > (global). Solaris tries to smash these two concepts together. Boo. This is no longer a problem: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456 Can we consider defining __cplusplus to the correct value in C++0x mode, even if we leave it at 1 for 98/03 mode? Let me know if I can help test on Solaris (if that's still necessary)
For testing, I would suggest also involving Rainer, now he is quite active on Solaris.
(In reply to comment #68) > (In reply to comment #63) > > > > Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the > > namespace std versions of functions, and not also the global scoped ones. This > > is a problem. The way I read ISO C++, cstdlib should only have std:: scoped > > bits. The C++ compatibility include stdlib.h should then re-scope to :: > > (global). Solaris tries to smash these two concepts together. Boo. > > This is no longer a problem: > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456 It was not so hard to work around in any case (see rest of the discussion). > Can we consider defining __cplusplus to the correct value in C++0x mode, even > if we leave it at 1 for 98/03 mode? The reason for not defining it to the correct value is not that it would yield an unclean situation (which is already the case). There are several issues: - breaks the ABI because tm and a couple other structs move from the global namespace to namespace std. This can be worked around by forcing the mangling of std::tm to be that of ::tm, but it is ugly. - needs to remove the overloads on linkage (like bsearch, qsort) in the solaris headers because g++ is broken there. - needs to adapt redefine_extname to remove its limitation to the global namespace. - needs to conditionally remove the overloads from libstdc++ that are already in the solaris headers (like the math functions) and deal with the fact that afterwards, including math.h instead of cmath will mean that cos(int) fails, at least until Oracle writes C++0X headers (might take a few years). Or fixinclude out almost anything that __cplusplus enables... I had a proof of concept in some PR some time ago, but the fixinclude part was a bit heavy...
N.B. The latest C++0x draft, N3042, specifies the value 201103L
If I remember correctly, mostly Solaris issues prevented us from defining __cplusplus to a meaningful value. Since now we have a pretty active maintainer, Rainer, I'm adding him in CC and asking him to play a bit with the straightforward cpp_init_builtins patch defining __cplusplus to 199711 for c++98 (and 201103 in c++0x mode?)
> --- Comment #72 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-03-07 16:38:06 UTC --- > If I remember correctly, mostly Solaris issues prevented us from defining > __cplusplus to a meaningful value. Since now we have a pretty active > maintainer, Rainer, I'm adding him in CC and asking him to play a bit with the > straightforward cpp_init_builtins patch defining __cplusplus to 199711 for > c++98 (and 201103 in c++0x mode?) I've used the following patch and gave it a try on Solaris 8 to 11, both SPARC and x86: diff -r 599e2b06493d libcpp/init.c --- a/libcpp/init.c Fri Mar 04 18:31:41 2011 +0100 +++ b/libcpp/init.c Mon Mar 07 20:02:13 2011 +0100 @@ -452,8 +452,12 @@ || CPP_OPTION (pfile, std))) _cpp_define_builtin (pfile, "__STDC__ 1"); - if (CPP_OPTION (pfile, cplusplus)) - _cpp_define_builtin (pfile, "__cplusplus 1"); + if (CPP_OPTION (pfile, lang) == CLK_CXX98 + || CPP_OPTION (pfile, lang) == CLK_GNUCXX) + _cpp_define_builtin (pfile, "__cplusplus 19971L"); + else if (CPP_OPTION (pfile, lang) == CLK_CXX0X + || CPP_OPTION (pfile, lang) == CLK_GNUCXX0X) + _cpp_define_builtin (pfile, "__cplusplus 201103L"); else if (CPP_OPTION (pfile, lang) == CLK_ASM) _cpp_define_builtin (pfile, "__ASSEMBLER__ 1"); else if (CPP_OPTION (pfile, lang) == CLK_STDC94) Unfortunately, even on Solaris 11/x86 bootstrap breaks quickly building i386-pc-solaris2.11/bits/stdc++.h.gch/O2ggnu++0x.gch: In file included from /vol/gcc/src/hg/trunk/local/libstdc++-v3/include/precompiled/stdc++.h:42:0: /var/gcc/regression/trunk/11-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/cmath: In function 'double std::abs(double)': /var/gcc/regression/trunk/11-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/cmath:82:3: error: redefinition of 'double std::abs(double)' /usr/include/iso/math_iso.h:159:16: error: 'double std::abs(double)' previously defined here and many many more errors. cmath has inline double abs(double __x) { return __builtin_fabs(__x); } while <iso/math_iso.h> has inline double abs(double __X) { return fabs(__X); } I haven't looked at the failures on older Solaris versions yet, which will likely be different. Rainer
(In reply to comment #73) > > asking him to play a bit with the > > straightforward cpp_init_builtins patch defining __cplusplus to 199711 for > > c++98 (and 201103 in c++0x mode?) > > I've used the following patch and gave it a try on Solaris 8 to 11, both > SPARC and x86: This can't work. As explained in comment #70, there would be several issues to fix first (none very hard, but it would take time). An alternate solution that would not require as much work is suggested in comment #56. I have no idea how well/bad that would work out. Yet another one is to heavily fixinclude the solaris headers.
For 4.7, if Rainer can help testing, we can certainly seriously attack and resolve this issue.
I admittedly haven't read the (excessively long) PR. If the Solaris headers can only work with the Studio compilers, I'm certainly open for a fixincludes solution. I may even be able to get this stuff integrated into Solaris 11, given sufficient justification. Rainer
Great Rainer. As soon as 4.6.0 branches I guess we should ask Marc to present on the libstdc++ mailing list a concise summary of the various options, I encourage you to follow this discussion, in the light of which we'll be able to make a decision. In general, I think we should try to be minimally invasive for non-Solaris, where everything works pretty well already, thus the fixincludes solution looks indeed very attractive. But at the outset I'm also open to more invasive changes, in particular if they can be shown to offer further advantages in terms of clarity or ability to solve other problems, for 4.7.0 we can afford that.
> --- Comment #77 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-03-08 11:19:03 UTC --- > Great Rainer. > > As soon as 4.6.0 branches I guess we should ask Marc to present on the > libstdc++ mailing list a concise summary of the various options, I encourage > you to follow this discussion, in the light of which we'll be able to make a > decision. In general, I think we should try to be minimally invasive for Please put me on the Cc: when it starts: I'm not subscribed to libstdc++. > non-Solaris, where everything works pretty well already, thus the fixincludes > solution looks indeed very attractive. But at the outset I'm also open to more > invasive changes, in particular if they can be shown to offer further > advantages in terms of clarity or ability to solve other problems, for 4.7.0 we > can afford that. I've started to analyse the failures caused by having a proper __cplusplus value, but there seem to be several headers and solutions involved. This isn't a problem per se, especially if they also apply to Solaris 8 and up, which might be the case with only small variations to the fixes. Once I have an idea what it takes to make the Solaris headers work with __cplusplus 199711L, I'll also engage the Solaris engineers to try and get this stuff (and other fixincludes changes, while we're at it) integrated. Rainer
(In reply to comment #70) > - needs to remove the overloads on linkage (like bsearch, qsort) in the solaris > headers because g++ is broken there. So it's linked to from here, this is PR 2316
Gentlemans! It has been 10 years but there is no progress. Why the standard-compliant value is still not defined in platforms other that @#$%#^% Solaris? How do we write universal code for C++98 and C++11 without the proper defined macro?
Marc and Rainer, if you have proposals for Solaris, I think this is the right time for 4.7...
> --- Comment #81 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-07-21 09:52:11 UTC --- > Marc and Rainer, if you have proposals for Solaris, I think this is the right > time for 4.7... I thought the conclusion were that this would be fixable inside libstdc++ without (much) touching the Solaris headers. Given that I'm not a C++ person at all, I'm relying on the libstdc++ maintainers to handle that. I can help of course if there's still some need for fixincludes. As a prerequisite, PR c++/30112 needs to be fixed which also recently bit me when trying gold on Solaris 11. Rainer
Ok, thus I marked 30112 as blocking this, I'll try to raise its priority. Otherwise Rainer, ok, in terms of producing an actual patch I was addressing mostly Marc, but, unless I'm badly misremembering, something *should* be special about Solaris, eg I'm pretty sure I can fix the macro for systems using glibc without major problems. Thus it would be great if you could coordinate with Marc in terms of extensive testing on Solaris...
> --- Comment #83 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-07-21 12:08:32 UTC --- > Ok, thus I marked 30112 as blocking this, I'll try to raise its priority. Fine, thanks. > Otherwise Rainer, ok, in terms of producing an actual patch I was addressing > mostly Marc, but, unless I'm badly misremembering, something *should* be > special about Solaris, eg I'm pretty sure I can fix the macro for systems using > glibc without major problems. Thus it would be great if you could coordinate IIUC the major problem is that the Solaris headers (at least since Solaris 10) are (fully?) C++ aware, while glibc is not, so we were running into conflicts. I brought the issue and my findings with fixing Solaris headers to avoid the conflicts up with the Solaris C++ and libc engineers, and there was major opposition to `fixing' them for the benefit of libstdc++ if the problem is mostly on the libstdc++ side. > with Marc in terms of extensive testing on Solaris... Sure, no problem: I've got an extensive test farm over here, from Solaris 8 to 11, both x86 and SPARC. As soon as something is ready for testing, I'm prepared :-) Rainer
Fair enough, and I should really find the time to go again through the entire trail. Just wanted to add that for a C header to be 'C++ ready' is a rather vaguely defined notion, thus, whereas I can definitely trust my new colleagues that something consistent and sane is in place in the Solaris headers, I still fear too much special casing in v3. Well, we could also imagine properly defining the macros *only* on linux and Solaris at some point, and gradually ask the port maintainers to work out the missing bits on their ports. At this point I'd really ask Marc if, maybe post 30112, he is willing to outline again a possible patch which you could test. As I said already, ideally, if the patch would be large, I would really recommend sending for review a mini version first, fixing only a couple of headers.
> --- Comment #85 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-07-21 12:34:21 UTC --- > Fair enough, and I should really find the time to go again through the entire > trail. Just wanted to add that for a C header to be 'C++ ready' is a rather > vaguely defined notion, thus, whereas I can definitely trust my new colleagues > that something consistent and sane is in place in the Solaris headers, I still > fear too much special casing in v3. Well, we could also imagine properly > defining the macros *only* on linux and Solaris at some point, and gradually > ask the port maintainers to work out the missing bits on their ports. You should find a description of the problems I found in this thread: Allow __cplusplus=199711L to work with Solaris 2 headers http://gcc.gnu.org/ml/libstdc++/2011-03/msg00032.html Thanks. Rainer
Now the pragma issue is solved. Good. I don't know Rainer if that means we can do something, I'm afraid it surfaced only as one of the last stumbling blocks in your analysis...
> --- Comment #87 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-07-22 21:49:49 UTC --- > Now the pragma issue is solved. Good. I don't know Rainer if that means we can > do something, I'm afraid it surfaced only as one of the last stumbling blocks > in your analysis... Right, that issue broke wcsftime, IIRC. I think someone with an understanding of libstdc++ and C++ needs to step forward to determine how to avoid the problems I've discovered. I think Jonathan already had a design. Rainer
Ok, thanks. I'm afraid Jon will not be able to contribute much over the next few weeks, in the meanwhile I'll try to find the time to go through that old message of yours to the mailing list. Ideally, it would be nice if we could at least split the work to independent tasks...
How does one go about reporting a bug in solaris? In Solaris 11, with -std=c++** (as opposed to gnu++**), __cplusplus=199711L and without -m64 or -pthreads, iso/stdio_iso.h doesn't declare getc but uses it in the definition of getchar.
solaris also provides the pow(*,int) overloads (see DR550). Should these be fixincluded out? On the other hand, solaris doesn't provide the cos(int) overload, so cos(0) fails as ambiguous (like with sunpro) if one includes math.h and not cmath. Should this be ignored? or the integral overload fixincluded into math.h? or an extra math.h shipped that is equivalent to cmath (careful to use #include_next)? In any case, as already mentioned, we'll have trouble with different versions of solaris providing different things in their headers. The solution of having __cplusplus as 199711L except for system headers where it is 1 seems easier.
Created attachment 24874 [details] for Solaris 11 Still some bugs. And I didn't include the patch to mangle std::tm/ldiv_t/... as if they were in the global namespace so the ABI is broken. And the c++config bit would need proper guarding. And the patch includes unrelated stuff I had to patch along the way.
If we can converge, with Rainer' help too, to something working at least on current Solaris (besides Linux), I'm pretty sure we'll be able to deliver it in 4.7.0!
(In reply to comment #92) > Created attachment 24874 [details] > for Solaris 11 If I manually fixinclude the getc problem and the pow declarations, the only unexpected testsuite failures I get are ext/profile/mutex_extensions_neg.cc (expected error moved by 5 lines) and the ABI breakage. Fixing the ABI is not too hard (add substitutions to cp/mangle.c for std::tm and a couple others) but I don't know if that's acceptable (it may yield weird duplicate symbol errors) and if it should be done only on solaris.
Created attachment 24877 [details] More solaris fixinclude
> --- Comment #90 from Marc Glisse <marc.glisse at normalesup dot org> 2011-07-30 20:19:42 UTC --- > How does one go about reporting a bug in solaris? In Solaris 11, with Not anymore since Oracle in their infinite wisdom made bugs.opensolaris.org `temporarily unavailable', which so far has lasted for several months. In general, you need to have a support contract. I do have good connections to Solaris engineering, though. > -std=c++** (as opposed to gnu++**), __cplusplus=199711L and without -m64 or > -pthreads, iso/stdio_iso.h doesn't declare getc but uses it in the definition > of getchar. I could trace this to g++ defining __STRICT_ANSI__ for -std=c++98/c++0x. <sys/feature_tests.h> defines _STRICT_STDC in this case, which hides the !_REENTRANT && !_LP64 && !_STRICT_STDC getc definition in <iso/stdio_iso.h>. Rainer
> --- Comment #91 from Marc Glisse <marc.glisse at normalesup dot org> 2011-07-30 21:02:20 UTC --- > solaris also provides the pow(*,int) overloads (see DR550). Should these be > fixincluded out? On the other hand, solaris doesn't provide the cos(int) > overload, so cos(0) fails as ambiguous (like with sunpro) if one includes > math.h and not cmath. Should this be ignored? or the integral overload > fixincluded into math.h? or an extra math.h shipped that is equivalent to cmath > (careful to use #include_next)? If there's wording in the C++ standard that suggests the cos(int) overload should exist, I could file a bug with Oracle. > In any case, as already mentioned, we'll have trouble with different versions > of solaris providing different things in their headers. The solution of having > __cplusplus as 199711L except for system headers where it is 1 seems easier. Given the mess with STDC_0_IN_SYSTEM_HEADERS, I'd avoid something like this if at all possible. Rainer
(In reply to comment #97) > If there's wording in the C++ standard that suggests the cos(int) > overload should exist, I could file a bug with Oracle. Only in C++2011. So they will likely add it in a few years, protected with a different __cplusplus value. But in the meantime it will cause what some will see as a regression in gcc on solaris. (by the way, I will update my fixinclude patch to not always remove the pow overloads but only in C++0X mode, as done in cmath) > > In any case, as already mentioned, we'll have trouble with different versions > > of solaris providing different things in their headers. The solution of having > > __cplusplus as 199711L except for system headers where it is 1 seems easier. > > Given the mess with STDC_0_IN_SYSTEM_HEADERS, I'd avoid something like > this if at all possible. I guess the alternative is to live with inconsistencies between the various solaris releases (which Oracle itself seems happy to do with its compiler).
Created attachment 24883 [details] Solaris fixinclude This should wrap the pow overloads to remove them in C++0X instead of always (as in cmath). Untested (my virtualbox solaris doesn't answer ssh today).
Created attachment 24884 [details] Alter mangling of std::tm and std::ldiv_t And I attach a patch that mangles std::tm as ::tm, and the same for ldiv_t. Of course it would also require div_t, lconv, and whatever else a grep will turn up. Note that I don't understand half of the macros in the patch (everything to do with TYPE is likely useless) but it seems to work. Note also that I don't answer the question of whether we want to do such a thing (which should allow compatibility with older gcc and can be reverted at the next ABI break), or even do it just for solaris. (if anyone wants to try, you'll likely hit PR 49914, which can be worked around by s/abs/llabs/ wherever it complains)
Thanks Marc. Thus, it seems to me that Rainer should have a look to the fixincludes, double check make sense to him, aren't library bits and should be sorted out between you two. Also, the mangling bits should be sent to the attention of the C++ front-end maintainers, like Jason, can you do that, Marc? Or let me know if I can help...
> --- Comment #101 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-03 10:02:44 UTC --- > Thanks Marc. Thus, it seems to me that Rainer should have a look to the > fixincludes, double check make sense to him, aren't library bits and should be > sorted out between you two. What would help enormously for this would be a complete justification for the individual fixes: * Does a standard call for some specific declaration? If so, which one, chapter and verse? In such a case, it will be easier get Oracle's attention so the issue is also fixed upstream. (If only C++ 2011, it might be a bit of a tougher ride.) * If this is a libstdc++ requirement not currently demanded by a standard, would there be an alternative way to fix this inside libstdc++? The reason I'm asking is that the OS headers tend to be a moving target, and you may have to keep updating the fix to keep it working. Please keep in mind that my understanding of C++ is minimal, so what may be obvious to you might not be to me. I'm not at all opposed to perform fixincludes fixes, but if there are alternatives, they should at least be considered. Thanks. Rainer
(In reply to comment #102) > What would help enormously for this would be a complete justification > for the individual fixes: Of course. I tried to keep the fixincludes to the minimum. One fixes the issue with getc/getchar explained above. One removes the extern "C++" overloads of bsearch/qsort because of PR 2316 : Solaris is right to have those, but most compilers (wrongly) don't consider linkage (C vs C++) as part of the type and thus to them Solaris is defining the same function twice. One wraps the declarations of pow(*,int) with #ifdef so that they remain available in C++03 (Solaris is right to have them, section 26.5.6 of the standard) but they disappear in C++0X (to match section 26.8.9 of N3291). The first 2 are necessary. I believe the last one is not required (it should just cause one minor bug in C++0X) and can be reconsidered later if you prefer. I haven't tested the version of the fixinclude patch attached to the bug, I was going to do that once I get access to a Solaris 10 (we have one, but it takes a while to register so I can use it). I wrote the patch on S11, so I also wanted to get a look at the S10 headers to check for differences. > In such a case, it will be easier get Oracle's attention so the issue > is also fixed upstream. (If only C++ 2011, it might be a bit of a > tougher ride.) I guess Oracle will implement C++2011 at some point, no need to push them. The libstdc++ headers will need adjusting when that happens. The getc issue is worth reporting upstream though. > * If this is a libstdc++ requirement not currently demanded by a > standard, would there be an alternative way to fix this inside > libstdc++? The reason I'm asking is that the OS headers tend to be a > moving target, and you may have to keep updating the fix to keep it > working. I completely agree with this, but it looks hard without fixinclude. Note that I am not a fixinclude expert and it is possible the fixes could be written in a less fragile way. And I think one "c_fix_arg" is supposed to be "select" instead.
Wow, just got bit by this 10 year old bug on Solaris 10. The following code correctly errors with Sun's compiler: #include <string.h> int main() { char* foo = strchr("z", 'z'); return 0; } "foo.c", line 2: Error: Cannot assign const char* to char*. But under no invocation of g++ does this even print a warning (-Wall -Wextra -Wcast-qual) because Solaris iso/string_iso.h only declares the return value 'const' when __cplusplus >= 199711L.
$ uname -a SunOS sun 5.10 Generic_137111-08 sun4v sparc SUNW,T5240 Solaris $ CC -V CC: Sun C++ 5.10 SunOS_sparc 128228-10 2010/08/18 $ g++ -dumpversion 4.5.2 $ cat > foo.cpp #include <string.h> int main() { char* foo = strchr("z", 'z'); return 0; } $ CC -c foo.cpp "foo.cpp", line 2: Error: Cannot use const char* to initialize char*. 1 Error(s) detected. $ g++ -std=c++0x -pedantic -Wall -Wextra -Wno-unused -c foo.cpp $
(In reply to comment #96) > I could trace this to g++ defining __STRICT_ANSI__ for > -std=c++98/c++0x. <sys/feature_tests.h> defines _STRICT_STDC in this > case, which hides the !_REENTRANT && !_LP64 && !_STRICT_STDC getc > definition in <iso/stdio_iso.h>. If you don't like fixincludes, we could also make g++ never define __STRICT_ANSI__ on Solaris. After all, it already unconditionally defines __STDC_VERSION__=199901L, _XOPEN_SOURCE=600 and __EXTENSIONS__...
Created attachment 24917 [details] tested patch I tested this patch on S10 (the headers are really the same as in S11) and it doesn't seem to cause unexpected failures in libstdc++. The mangling patch, on the other hand, is broken: it forgets "const", for example in "const std::tm*". I am not sure what I am doing wrong (I basically copied the code used to give a special mangling to std::string). The list of all structs in namespace std is: div_t, lconv, ldiv_t, tm.
Excellent. Can we sort out separately with C++ front-end people like Jason this mangling (and demangling too, I suppose) issue? If I understand correctly it's something which we are going to need for C++11 anyway, right?
(In reply to comment #108) > Excellent. Can we sort out separately with C++ front-end people like Jason this > mangling (and demangling too, I suppose) issue? Yes. There are independent pieces: *fixincludes *libstdc++ *mangling and libcpp is the big red button that can only be pressed at the end. None of the changes should have any noticable effect as long as we haven't pressed the red button. > If I understand correctly it's > something which we are going to need for C++11 anyway, right? Ah, no. It is something we only need if we want to keep binary compatibility between __cplusplus=1 and __cplusplus=199711L binaries on Solaris. As soon as we break the ABI (libstdc++-v7?), it should be reverted as useless. About demangling, I don't know if we wan't to change it (and it would have to be Solaris-only). std::tm will be printed as tm, but that doesn't seem so bad... PS: wasn't there a discussion some time ago about adding macros like __SunOS_5_10 (name taken from sunpro) so we can detect the Solaris version?
> Yes. There are independent pieces: > *fixincludes > *libstdc++ > *mangling > > and libcpp is the big red button that can only be pressed at the end. None of > the changes should have any noticable effect as long as we haven't pressed the > red button. This is very, very good, thanks. > > If I understand correctly it's > > something which we are going to need for C++11 anyway, right? > > Ah, no. It is something we only need if we want to keep binary compatibility > between __cplusplus=1 and __cplusplus=199711L binaries on Solaris. As soon as > we break the ABI (libstdc++-v7?), it should be reverted as useless. I think we really need some feedback from Rainer, then. Sorry, but it's the first time I see the mangling machinery at issue only for a specific target. At some point we'll have to involve the front-end people anyway, because the code lives in cp/. > About demangling, I don't know if we wan't to change it (and it would have to > be Solaris-only). std::tm will be printed as tm, but that doesn't seem so > bad... Ok. > PS: wasn't there a discussion some time ago about adding macros like > __SunOS_5_10 (name taken from sunpro) so we can detect the Solaris version? Rainer?
(In reply to comment #110) > > Ah, no. It is something we only need if we want to keep binary compatibility > > between __cplusplus=1 and __cplusplus=199711L binaries on Solaris. As soon as > > we break the ABI (libstdc++-v7?), it should be reverted as useless. > > I think we really need some feedback from Rainer, then. Sorry, but it's the > first time I see the mangling machinery at issue only for a specific target. At > some point we'll have to involve the front-end people anyway, because the code > lives in cp/. Well, it's not everyday you move struct tm from the global namespace to namespace std... I can't think of many ways to keep binary compatibility with such a change, except through mangling. And I don't think people would be happy if we broke binary compatibility on Solaris just so we can set __cplusplus. More fixinclude doesn't sound very good either.
Created attachment 24921 [details] Mangling compatibility Checking cp_type_quals (the documentation advertises the long-dead CP_TYPE_QUALS macro) helped, but the substitution stack ended up shifted by one. Patching write_unscoped_name is easier and abi_check now passes. Anyway, this is more a proof of concept so we can decide if we want to tinker with mangling, as I am sure a C++ FE guy could rewrite something much cleaner.
As you've probably seen, I've cleaned up and tested Marc's patches over the weekend, threw some more testing (Solaris 8/9/10) in yesterday, and posted the results to gcc-patches etc.: [java, libjava] Allow C++ compilation with Solaris headers http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00832.html [c++] Keep tm, div_t, ldiv_t, lconv mangling on Solaris (PR libstdc++-v3/1773) http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00834.html [fixincludes] Allow properly defining __cplusplus with Solaris headers (PR libstdc++-v3/1773) http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00833.html [v3] Use Solaris prototypes if possible (PR libstdc++-v3/1773) http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00835.html [libcpp] Correctly define __cplusplus (PR libstdc++-v3/1773) http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00837.html Many thanks to Marc for his hard work to make this a reality. I just think it's easier to discuss the separate issues in their own threads on the proper mailing lists, rather than on bugzilla. Rainer
Author: ro Date: Thu Aug 18 17:29:10 2011 New Revision: 177877 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177877 Log: Properly define __cplusplus (PR libstdc++-v3/1773) PR libstdc++/1773 * init.c (cpp_init_builtins): Define __cplusplus 19971L. Modified: trunk/libcpp/ChangeLog trunk/libcpp/init.c
Finally fixed for 4.7.0, many thanks to all contributors for patches, analysis and support. Rainer
Thank you Rainer, and Marc, for the huge analysis and programming and testing effort.
Thanks for the effort! Any chance of this being backported to older branches? Seems quite useful for the future.
(In reply to comment #117) > Any chance of this being backported to older branches? Seems quite useful for > the future. I don't think this (very good, but quite major) change qualifies for stable release branches. If someone is (perhaps foolishly) relying on __cplusplus==1 in 4.5.3 we should not break their code if they upgrade to 4.5.4, they should reasonably expect only bug fixes in that upgrade
If you ask me, no way.
OK, somewhat understandable to keep evil legacy code compiling. Last plea for Standards conformance: What about only setting the correct define if -std=c++89/03/0x/11 is passed and keeping the old behavior for -std=gnu++*?
(In reply to comment #120) > Last plea for Standards conformance: What about only setting the correct define > if -std=c++89/03/0x/11 is passed and keeping the old behavior for -std=gnu++*? I don't think so. First, that would be weird. And this isn't just about switching a #define, it comes with a lot of other changes. Besides, it wouldn't help you at all. The only thing that the value of __cplusplus can be good for now is distinguishing between C++03 and C++11, but even trunk doesn't set the C++11 value, and my hope is that it won't set it until C++11 support is essentially complete.
(In reply to comment #120) > Last plea for Standards conformance: What about only setting the correct define > if -std=c++89/03/0x/11 is passed and keeping the old behavior for -std=gnu++*? No. If you want the new behaviour then you have to wait for the new release.
Author: jason Date: Mon Oct 31 19:34:26 2011 New Revision: 180708 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180708 Log: PR libstdc++/1773 * init.c (cpp_init_builtins): Set __cplusplus for C++11. Modified: trunk/libcpp/ChangeLog trunk/libcpp/init.c
My understanding of the last comment is that for -std=c++11 _cplusplus should be set so that "#if __cplusplus > 201100L" can be used to conditionally compile as C++03 vs C++11. I would expect this to be in the snapshot I'm using but it doesn't seem to be. Has it regressed or do we need to wait for the next snapshot release? What other way is there to distinguish C++03 and C++11 in source as a workaround? #include <iostream> int main(int argc, char* argv[]) { std::cout << __cplusplus << std::endl; return 0; } #!/bin/sh gcc --version gcc -Wconversion blah.cpp -oblah -lstdc++ ./blah export LD_LIBRARY_PATH=/opt/gcc4.7/lib:$LD_LIBRARY_PATH export PATH=/opt/gcc4.7/bin:$PATH /opt/gcc4.7/bin/gcc --version /opt/gcc4.7/bin/gcc -std=c++03 blah.cpp -oblah2 -lstdc++ ./blah gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51) [snip] 1 gcc (GCC) 4.7.0 20111119 (experimental) [snip] 1
Something is wrong on your system. The normal output, which I can of course reproduce in mainline, is "199711" or "201193" depending on the -std.
"201103" of course.
(In reply to comment #126) > "201103" of course. Perhaps it is my misunderstanding. I assume __cpluscplus is defined by the compiler. Could it come from a system header or system library instead? g++ must include the std C++ library because otherwise I wouldn't be able to use unique_ptr with g++ 4.7 when I can't use it with g++ 4.1. Could someone confirm whether this change is in the 20111119 snapshot or only in main please?
Your test script runs blah twice, but you probably meant to run blah2
doh! You are entirely right. It works just fine on the 20111119 snapshot. Sorry for wasting time there. I was too fast on the email trigger. Mea culpa.