[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[neroden at gcc dot gnu dot org]

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


neroden at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |11285
              nThis|                            |


------- Additional Comments From neroden at gcc dot gnu dot org  2003-08-03 18:56 -------
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at integrable-solutions dot net]

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 gdr at integrable-solutions dot net  2003-08-03 19:16 -------
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[neroden at gcc dot gnu dot org]

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 neroden at gcc dot gnu dot org  2003-08-03 20:19 -------
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at integrable-solutions dot net]

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 gdr at integrable-solutions dot net  2003-08-03 20:31 -------
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[neroden at gcc dot gnu dot org]

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 neroden at gcc dot gnu dot org  2003-08-03 23:01 -------
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at integrable-solutions dot net]

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 gdr at integrable-solutions dot net  2003-08-03 23:37 -------
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pme at gcc dot gnu dot org]

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 pme at gcc dot gnu dot org  2003-08-04 04:32 -------
> 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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at integrable-solutions dot net]

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 gdr at integrable-solutions dot net  2003-08-04 08:01 -------
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[phil at jaj dot com]

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.


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at integrable-solutions dot net]

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 gdr at integrable-solutions dot net  2003-08-04 08:26 -------
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[phil at jaj dot com]

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:46 -------
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?

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at integrable-solutions dot net]

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 gdr at integrable-solutions dot net  2003-08-04 09:04 -------
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[bkoz at gcc dot gnu dot org]

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 bkoz at gcc dot gnu dot org  2003-08-04 16:13 -------
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[phil at jaj dot com]

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 17:01 -------
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[neroden at gcc dot gnu dot org]

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


neroden at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor


------- Additional Comments From neroden at gcc dot gnu dot org  2003-08-04 18:00 -------
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-07 10:26 -------
Unsuspending for the time being.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW
   Last reconfirmed|2003-11-05 07:55:45         |2004-01-07 10:26:32
               date|                            |


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-07 10:27 -------
*** Bug 13596 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at gcc dot gnu dot
                   |                            |org


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-01-07 18:59 -------
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.

-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[neroden at gcc dot gnu dot org]

------- Additional Comments From neroden at gcc dot gnu dot org  2004-01-07 21:29 -------
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.  :-)


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-01-08 16:59 -------

> 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

-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[chris at bubblescope dot net]

------- Additional Comments From chris at bubblescope dot net  2005-03-29 19:19 -------
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.

-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-03-29 21:55 -------
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


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[tortoise_74 at yahoo dot co.uk]

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

--- Comment #129 from Bruce Adams <tortoise_74 at yahoo dot co.uk> 2011-11-29 10:49:08 UTC ---
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[redi at gcc dot gnu.org]

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

--- Comment #128 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-26 12:30:25 UTC ---
Your test script runs blah twice, but you probably meant to run blah2

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[tortoise_74 at yahoo dot co.uk]

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

--- Comment #127 from Bruce Adams <tortoise_74 at yahoo dot co.uk> 2011-11-26 12:10:26 UTC ---
(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?

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #126 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-11-25 19:22:06 UTC ---
"201103" of course.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #125 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-11-25 19:21:10 UTC ---
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[tortoise_74 at yahoo dot co.uk]

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

Bruce Adams <tortoise_74 at yahoo dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tortoise_74 at yahoo dot
                   |                            |co.uk

--- Comment #124 from Bruce Adams <tortoise_74 at yahoo dot co.uk> 2011-11-25 18:33:25 UTC ---
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[jason at gcc dot gnu.org]

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

--- Comment #123 from Jason Merrill <jason at gcc dot gnu.org> 2011-10-31 19:34:32 UTC ---
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[redi at gcc dot gnu.org]

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

--- Comment #122 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-09-28 15:34:22 UTC ---
(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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #121 from Marc Glisse <marc.glisse at normalesup dot org> 2011-09-28 14:20:09 UTC ---
(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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[vanboxem.ruben at gmail dot com]

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

--- Comment #120 from Ruben Van Boxem <vanboxem.ruben at gmail dot com> 2011-09-28 13:58:03 UTC ---
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++*?

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #119 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-09-28 12:23:51 UTC ---
If you ask me, no way.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[redi at gcc dot gnu.org]

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

--- Comment #118 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-09-28 12:21:31 UTC ---
(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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[vanboxem.ruben at gmail dot com]

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

Ruben Van Boxem <vanboxem.ruben at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vanboxem.ruben at gmail dot
                   |                            |com

--- Comment #117 from Ruben Van Boxem <vanboxem.ruben at gmail dot com> 2011-09-28 12:14:38 UTC ---
Thanks for the effort!

Any chance of this being backported to older branches? Seems quite useful for
the future.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #116 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-21 22:02:23 UTC ---
Thank you Rainer, and Marc, for the huge analysis and programming and testing
effort.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |ro at gcc dot gnu.org
         Resolution|                            |FIXED
   Target Milestone|---                         |4.7.0

--- Comment #115 from Rainer Orth <ro at gcc dot gnu.org> 2011-08-18 17:38:13 UTC ---
Finally fixed for 4.7.0, many thanks to all contributors for patches, analysis
and support.

  Rainer

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at gcc dot gnu.org]

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

--- Comment #114 from Rainer Orth <ro at gcc dot gnu.org> 2011-08-18 17:29:14 UTC ---
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #113 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-08-09 12:56:20 UTC ---
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #24884|0                           |1
        is obsolete|                            |

--- Comment #112 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-05 15:11:43 UTC ---
Created attachment 24921
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24921
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #111 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-04 15:38:52 UTC ---
(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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #110 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-04 15:29:58 UTC ---
> 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?

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #109 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-04 15:21:36 UTC ---
(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?

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #108 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-04 14:40:21 UTC ---
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?

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #24874|0                           |1
        is obsolete|                            |

--- Comment #107 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-04 14:20:12 UTC ---
Created attachment 24917
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24917
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #106 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-03 21:51:53 UTC ---
(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__...

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[andrew at ishiboo dot com]

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

--- Comment #105 from Andrew Paprocki <andrew at ishiboo dot com> 2011-08-03 20:26:17 UTC ---
$ 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
$

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[andrew at ishiboo dot com]

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

Andrew Paprocki <andrew at ishiboo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrew at ishiboo dot com

--- Comment #104 from Andrew Paprocki <andrew at ishiboo dot com> 2011-08-03 20:17:26 UTC ---
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #103 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-03 15:52:09 UTC ---
(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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #102 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-08-03 15:12:29 UTC ---
> --- 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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

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

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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #100 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-01 16:17:25 UTC ---
Created attachment 24884
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24884
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)

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #24877|0                           |1
        is obsolete|                            |

--- Comment #99 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-01 14:38:24 UTC ---
Created attachment 24883
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24883
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).

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #98 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-01 13:03:18 UTC ---
(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).

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #97 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-08-01 12:52:50 UTC ---
> --- 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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #96 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-08-01 12:31:54 UTC ---
> --- 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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #95 from Marc Glisse <marc.glisse at normalesup dot org> 2011-07-31 14:03:39 UTC ---
Created attachment 24877
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24877
More solaris fixinclude

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #94 from Marc Glisse <marc.glisse at normalesup dot org> 2011-07-30 23:16:55 UTC ---
(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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #93 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-07-30 21:15:30 UTC ---
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!

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #92 from Marc Glisse <marc.glisse at normalesup dot org> 2011-07-30 21:08:20 UTC ---
Created attachment 24874
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24874
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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

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

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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #89 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-07-25 17:14:13 UTC ---
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...

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #88 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-07-25 17:02:45 UTC ---
> --- 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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #86 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-07-21 12:44:59 UTC ---
> --- 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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

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

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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #84 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-07-21 12:14:17 UTC ---
> --- 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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #82 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-07-21 11:32:42 UTC ---
> --- 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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo.carlini at oracle dot
                   |                            |com

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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[d.v.a at ngs dot ru]

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

__vic <d.v.a at ngs dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |d.v.a at ngs dot ru

--- Comment #80 from __vic <d.v.a at ngs dot ru> 2011-07-21 07:01:12 UTC ---
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?

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[redi at gcc dot gnu.org]

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

--- Comment #79 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-03-11 16:09:23 UTC ---
(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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #78 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-03-11 15:44:59 UTC ---
> --- 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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #76 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-03-08 10:27:08 UTC ---
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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #75 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-03-07 19:58:24 UTC ---
For 4.7, if Rainer can help testing, we can certainly seriously attack and
resolve this issue.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc.glisse at normalesup dot org]

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

--- Comment #74 from Marc Glisse <marc.glisse at normalesup dot org> 2011-03-07 19:21:16 UTC ---
(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.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #73 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-03-07 19:05:14 UTC ---
> --- 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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at CeBiTec dot
                   |                            |Uni-Bielefeld.DE

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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[redi at gcc dot gnu.org]

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

--- Comment #71 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-03-07 15:57:59 UTC ---
N.B. The latest C++0x draft, N3042, specifies the value 201103L

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc dot glisse at normalesup dot org]

------- Comment #70 from marc dot glisse at normalesup dot org  2010-04-29 10:27 -------
(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...


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo dot carlini at oracle dot com]

------- Comment #69 from paolo dot carlini at oracle dot com  2010-04-29 09:53 -------
For testing, I would suggest also involving Rainer, now he is quite active on
Solaris.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[redi at gcc dot gnu dot org]

------- Comment #68 from redi at gcc dot gnu dot org  2010-04-29 09:49 -------
(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)


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[chris at bubblescope dot net]

------- Comment #67 from chris at bubblescope dot net  2008-12-19 11:45 -------
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?


-- 

chris at bubblescope dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris at bubblescope dot net


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[bss03 at volumehost dot net]

------- Comment #66 from bss03 at volumehost dot net  2007-08-19 01:51 -------
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.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[bkoz at redhat dot com]

------- Comment #65 from bkoz at redhat dot com  2007-04-02 09:49 -------
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


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc dot glisse at normalesup dot org]

------- Comment #64 from marc dot glisse at normalesup dot org  2007-03-29 12:29 -------
(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?


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[bkoz at gcc dot gnu dot org]

------- Comment #63 from bkoz at gcc dot gnu dot org  2007-03-28 18:18 -------


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.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at cs dot tamu dot edu]

------- Comment #62 from gdr at cs dot tamu dot edu  2007-03-28 17:54 -------
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


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[bkoz at gcc dot gnu dot org]

------- Comment #61 from bkoz at gcc dot gnu dot org  2007-03-28 17:49 -------

mine, try two


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|gdr at gcc dot gnu dot org  |bkoz at gcc dot gnu dot org
             Status|NEW                         |ASSIGNED


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[bkoz at gcc dot gnu dot org]

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


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at cs dot tamu dot edu]

------- Comment #59 from gdr at cs dot tamu dot edu  2007-03-28 17:43 -------
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


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[bkoz at gcc dot gnu dot org]

------- Comment #58 from bkoz at gcc dot gnu dot org  2007-03-28 17:32 -------

Request to re-assign to me.

-benjamin


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[gdr at integrable-solutions dot net]

------- Comment #57 from gdr at integrable-solutions dot net  2006-05-09 15:15 -------
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


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc dot glisse at normalesup dot org]

------- Comment #56 from marc dot glisse at normalesup dot org  2006-05-09 14:24 -------
(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)


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[marc dot glisse at normalesup dot org]

------- Comment #55 from marc dot glisse at normalesup dot org  2006-05-09 13:55 -------
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 :-)


-- 

marc dot glisse at normalesup dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc dot glisse at
                   |                            |normalesup dot org


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #54 from pcarlini at suse dot de  2005-12-04 21:33 -------
(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.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ebotcazou at gcc dot gnu dot org]

------- Comment #53 from ebotcazou at gcc dot gnu dot org  2005-12-04 21:22 -------
> 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


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #52 from pcarlini at suse dot de  2005-12-04 21:04 -------
(In reply to comment #51)

> +#define __cpluplus 1

                 ^
Gosh! Thanks Eric for noticing and further testing.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ebotcazou at gcc dot gnu dot org]

------- Comment #51 from ebotcazou at gcc dot gnu dot org  2005-12-04 21:01 -------
> 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.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #50 from pcarlini at suse dot de  2005-12-04 20:52 -------
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 !?!


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #49 from pcarlini at suse dot de  2005-12-04 20:29 -------
(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. 


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #48 from pcarlini at suse dot de  2005-12-04 20:20 -------
(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?


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pedro dot lamarao at mndfck dot org]

------- Comment #47 from pedro dot lamarao at mndfck dot org  2005-12-04 20:11 -------
Any reason why libsupc++ can't include the stuff in config/ ?
I'm interested in seeing this bug go, I'd work on it.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #46 from pcarlini at suse dot de  2005-12-04 19:46 -------
(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...


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ebotcazou at gcc dot gnu dot org]

------- Comment #45 from ebotcazou at gcc dot gnu dot org  2005-12-04 19:31 -------
> 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


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #44 from pcarlini at suse dot de  2005-12-04 17:11 -------
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.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #43 from pcarlini at suse dot de  2005-12-04 16:43 -------
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...


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ebotcazou at gcc dot gnu dot org]

------- Comment #42 from ebotcazou at gcc dot gnu dot org  2005-12-04 16:34 -------
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


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #41 from pcarlini at suse dot de  2005-11-29 14:00 -------
Ok, agreed. I'm eager to finally close the oldest open libstdc++ PR... ;)


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ebotcazou at gcc dot gnu dot org]

------- Comment #40 from ebotcazou at gcc dot gnu dot org  2005-11-29 11:51 -------
> 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.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #39 from pcarlini at suse dot de  2005-11-29 10:24 -------
Eric, I'm sorry, any news?!? Thanks.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #38 from pcarlini at suse dot de  2005-11-21 15:22 -------
(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. 


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pedro dot lamarao at mndfck dot org]

------- Comment #37 from pedro dot lamarao at mndfck dot org  2005-11-21 15:11 -------
> 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.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[ebotcazou at gcc dot gnu dot org]

------- Comment #36 from ebotcazou at gcc dot gnu dot org  2005-11-21 13:59 -------
> 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.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ebotcazou at libertysurf dot|ebotcazou at gcc dot gnu dot
                   |fr                          |org


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #35 from pcarlini at suse dot de  2005-11-21 13:35 -------
(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


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-09-26 00:51:24         |2005-11-21 13:35:15
               date|                            |


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pedro dot lamarao at mndfck dot org]

------- Comment #34 from pedro dot lamarao at mndfck dot org  2005-11-21 13:29 -------
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.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pedro dot lamarao at mndfck dot org]

------- Comment #33 from pedro dot lamarao at mndfck dot org  2005-11-21 13:26 -------
Created an attachment (id=10307)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10307&action=view)
Defines __cplusplus to 199711L and overrides it for solaris 8 *only*

Please see comment #33 before applying this patch.


-- 

pedro dot lamarao at mndfck dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10303|0                           |1
        is obsolete|                            |


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pedro dot lamarao at mndfck dot org]

------- Comment #32 from pedro dot lamarao at mndfck dot org  2005-11-21 12:26 -------
Yes, I'll take a shot at this.


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pcarlini at suse dot de]

------- Comment #31 from pcarlini at suse dot de  2005-11-21 10:40 -------
(In reply to comment #30)
> Created an attachment (id=10303)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10303&action=view) [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?


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at libertysurf dot
                   |                            |fr


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pedro dot lamarao at mndfck dot org]

------- Comment #30 from pedro dot lamarao at mndfck dot org  2005-11-21 01:42 -------
Created an attachment (id=10303)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10303&action=view)
Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8


-- 


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

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[pedro dot lamarao at mndfck dot org]

------- Comment #29 from pedro dot lamarao at mndfck dot org  2005-11-21 01:41 -------
The following patch implements the suggested solution.
Is it correct?
I don't have access to any version of Solaris to check.


-- 


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