User account creation filtered due to spam.

Bug 1773 - __cplusplus defined to 1, should be 199711L
Summary: __cplusplus defined to 1, should be 199711L
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 2.97
: P3 minor
Target Milestone: 4.7.0
Assignee: Benjamin Kosnik
URL:
Keywords:
: 13596 (view as bug list)
Depends on: 377 30112
Blocks: 11285
  Show dependency treegraph
 
Reported: 2001-01-25 13:26 UTC by Jens Maurer
Modified: 2011-11-29 10:49 UTC (History)
20 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-11-21 13:35:15


Attachments
Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8 (413 bytes, patch)
2005-11-21 01:42 UTC, Pedro Lamarão
Details | Diff
Defines __cplusplus to 199711L and overrides it for solaris 8 *only* (658 bytes, patch)
2005-11-21 13:26 UTC, Pedro Lamarão
Details | Diff
for Solaris 11 (4.22 KB, patch)
2011-07-30 21:08 UTC, Marc Glisse
Details | Diff
More solaris fixinclude (615 bytes, patch)
2011-07-31 14:03 UTC, Marc Glisse
Details | Diff
Solaris fixinclude (665 bytes, patch)
2011-08-01 14:38 UTC, Marc Glisse
Details | Diff
Alter mangling of std::tm and std::ldiv_t (799 bytes, patch)
2011-08-01 16:17 UTC, Marc Glisse
Details | Diff
tested patch (3.54 KB, patch)
2011-08-04 14:20 UTC, Marc Glisse
Details | Diff
Mangling compatibility (801 bytes, patch)
2011-08-05 15:11 UTC, Marc Glisse
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Maurer 2001-01-25 13:26:00 UTC
The following program prints "1", but it should print
"199711", because __cplusplus should be so defined
according to ISO C++ section 16.8 [cpp.predefined].

Release:
gcc version 2.97 20010125 (experimental)

Environment:
i686-pc-linux-gnu with glibc 2.2

How-To-Repeat:
#include <stdio.h>

int main()
{
  printf("%ld\n", __cplusplus);
}
Comment 1 Gabriel Dos Reis 2001-01-25 14:58:57 UTC
Responsible-Changed-From-To: unassigned->gdr
Responsible-Changed-Why: Analyzed
Comment 2 Gabriel Dos Reis 2001-01-25 14:58:57 UTC
State-Changed-From-To: analyzed->suspended
State-Changed-Why: This is a known issue.  Defining a standard conforming value
    for __cplusplus happens to break V3 owns implementation.
    
    This issue will addressed later.  Thanks for your report.
    
    -- Gaby
Comment 3 Phil Edwards 2001-01-25 22:13:47 UTC
From: pme@sources.redhat.com
To: nobody@gcc.gnu.org, Jens.Maurer@gmx.net, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/1773: Changed information
Date: 25 Jan 2001 22:13:47 -0000

 Synopsis: __cplusplus defined to 1, should be 199711L
 Priority: low
 Severity: non-critical
 
 Changed-When:	Thu Jan 25 17:11:59 EST 2001
 Changed-By:	pme "Phil Edwards" <pme@sources.redhat.com>
 Changed-State-From-To:	open->analyzed
 Changed-Why:	Known problem.  I experimented with having g++ set this
 to the correct value, but libstdc++-v3 (the new c++ lib)
 has lots of problems compiling on some platforms.
 
Comment 4 Gabriel Dos Reis 2001-01-25 22:58:57 UTC
From: gdr@gcc.gnu.org
To: bkoz@redhat.com, pme@sourceware.cygnus.com, Jens.Maurer@gmx.net,
  gcc-gnats@gcc.gnu.org, gdr@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1773
Date: 25 Jan 2001 22:58:57 -0000

 Synopsis: __cplusplus defined to 1, should be 199711L
 
 Responsible-Changed-From-To: unassigned->gdr
 Responsible-Changed-By: gdr
 Responsible-Changed-When: Thu Jan 25 14:58:57 2001
 Responsible-Changed-Why:
     Analyzed
 State-Changed-From-To: analyzed->suspended
 State-Changed-By: gdr
 State-Changed-When: Thu Jan 25 14:58:57 2001
 State-Changed-Why:
     This is a known issue.  Defining a standard conforming value
     for __cplusplus happens to break V3 owns implementation.
     
     This issue will addressed later.  Thanks for your report.
     
     -- Gaby
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1773&database=gcc

Comment 5 Nathanael C. Nerode 2003-03-12 16:32:03 UTC
From: Nathanael Nerode <neroden@twcny.rr.com>
To: bkoz@redhat.com, gcc-gnats@gcc.gnu.org, Jens.Maurer@gmx.net,
   gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gdr@gcc.gnu.org,
   pme@sourceware.cygnus.com, gcc-prs@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/1773: __cplusplus defined to 1, should be 199711L
Date: Wed, 12 Mar 2003 16:32:03 -0500

 This is a very old report.  What's the status now?  It was suspended because 
 the standard conforming value for __cplusplus broke libstdc++-v3 on many 
 platforms.  libstdc++-v3 and the C++ front end have both undergone dramatic 
 changes and improvements.  Can this be fixed now?
 
 --Nathanael

Comment 6 Benjamin Kosnik 2003-03-12 18:23:59 UTC
From: Benjamin Kosnik <bkoz@redhat.com>
To: neroden@twcny.rr.com
Cc: gcc-gnats@gcc.gnu.org, Jens.Maurer@gmx.net, gcc@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org, gdr@gcc.gnu.org, pme@sourceware.cygnus.com,
   gcc-prs@gcc.gnu.org
Subject: Re: libstdc++/1773: __cplusplus defined to 1, should be 199711L
Date: Wed, 12 Mar 2003 18:23:59 -0600

 On Wed, 12 Mar 2003 16:32:03 -0500
 Nathanael Nerode <neroden@twcny.rr.com> wrote:
 
 >This is a very old report.  What's the status now?  It was suspended because 
 >the standard conforming value for __cplusplus broke libstdc++-v3 on many 
 >platforms.  libstdc++-v3 and the C++ front end have both undergone dramatic 
 >changes and improvements.  Can this be fixed now?
 
 Sadly, this can't be fixed at the moment, at least on most platforms.
 For cross compilers using newlib, this was fixed some time back with the
 --enable-headers=c work done at the time of the QNX port. That is not
 the default configuration, however.
 
 One of the things blocking this is hardware, ie real access to
 up-to-date sun hardware with sunpro tools so I can see what is going on.
 The other issue is time: I don't have enough of it, and this is
 something I consider a lower priority than other issues. There were some
 patches in glibc-2.3.x that went in that may allow a more elegant
 solution for linux, but that work is not finished.
 
 best,
 benjamin
Comment 7 Nathanael C. Nerode 2003-08-03 18:56:13 UTC
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
Comment 8 Gabriel Dos Reis 2003-08-03 19:16:54 UTC
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
Comment 9 Nathanael C. Nerode 2003-08-03 20:19:04 UTC
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.
Comment 10 Gabriel Dos Reis 2003-08-03 20:31:57 UTC
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
Comment 11 Nathanael C. Nerode 2003-08-03 23:01:54 UTC
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.
Comment 12 Gabriel Dos Reis 2003-08-03 23:37:42 UTC
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.  
Comment 13 Phil Edwards 2003-08-04 04:32:48 UTC
> 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.
Comment 14 Gabriel Dos Reis 2003-08-04 08:01:38 UTC
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
Comment 15 phil 2003-08-04 08:17:08 UTC
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.

Comment 16 Gabriel Dos Reis 2003-08-04 08:26:10 UTC
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
Comment 17 phil 2003-08-04 08:46:33 UTC
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?

Comment 18 Gabriel Dos Reis 2003-08-04 09:04:49 UTC
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
Comment 19 Benjamin Kosnik 2003-08-04 16:13:52 UTC
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
Comment 20 phil 2003-08-04 17:01:08 UTC
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.


Comment 21 Nathanael C. Nerode 2003-08-04 18:00:13 UTC
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.
Comment 22 Andrew Pinski 2004-01-07 10:26:32 UTC
Unsuspending for the time being.
Comment 23 Andrew Pinski 2004-01-07 10:27:41 UTC
*** Bug 13596 has been marked as a duplicate of this bug. ***
Comment 24 Mark Mitchell 2004-01-07 18:59:56 UTC
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.
Comment 25 Nathanael C. Nerode 2004-01-07 21:29:16 UTC
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.  :-)
Comment 26 Benjamin Kosnik 2004-01-08 16:59:04 UTC
> 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
Comment 27 Chris Jefferson 2005-03-29 19:19:08 UTC
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.
Comment 28 Gabriel Dos Reis 2005-03-29 21:55:03 UTC
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
Comment 29 Pedro Lamarão 2005-11-21 01:41:40 UTC
The following patch implements the suggested solution.
Is it correct?
I don't have access to any version of Solaris to check.
Comment 30 Pedro Lamarão 2005-11-21 01:42:55 UTC
Created attachment 10303 [details]
Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8
Comment 31 Paolo Carlini 2005-11-21 10:40:15 UTC
(In reply to comment #30)
> Created an attachment (id=10303) [edit]
> Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8

As-is, this cannot be right, because that file is shared between *all* the
Solaris version besides 5 and 6. See configure.host around line 247. If I 
understand correctly Comment #8, the corrected default should be overriden
*only* for Solaris 8.

In general, I'm also in favor of this approach, we all agree about that (see
Comment #24, 25, 26...). Therefore, my plan would be involving Eric for some
tests on *all* the Solaris versions of an amended patch which really would
deal specially with Solaris 8 only. It would involve adding a solaris2.8 dir
in config/os/solaris, and tweaking configure.host to use the existing
solaris2.7 dir for 2.7, 2.9, 2.10... , i.e., skipping 2.8, and the new 2.8
dir (getting the override) for 2.8 only.

Are you willing to work on that?
Comment 32 Pedro Lamarão 2005-11-21 12:26:59 UTC
Yes, I'll take a shot at this.
Comment 33 Pedro Lamarão 2005-11-21 13:26:09 UTC
Created attachment 10307 [details]
Defines __cplusplus to 199711L and overrides it for solaris 8 *only*

Please see comment #33 before applying this patch.
Comment 34 Pedro Lamarão 2005-11-21 13:29:13 UTC
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.
Comment 35 Paolo Carlini 2005-11-21 13:35:15 UTC
(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
Comment 36 Eric Botcazou 2005-11-21 13:59:43 UTC
> 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.
Comment 37 Pedro Lamarão 2005-11-21 15:11:57 UTC
> 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.
Comment 38 Paolo Carlini 2005-11-21 15:22:44 UTC
(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. 

Comment 39 Paolo Carlini 2005-11-29 10:24:27 UTC
Eric, I'm sorry, any news?!? Thanks.
Comment 40 Eric Botcazou 2005-11-29 11:51:16 UTC
> 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.
Comment 41 Paolo Carlini 2005-11-29 14:00:07 UTC
Ok, agreed. I'm eager to finally close the oldest open libstdc++ PR... ;)
Comment 42 Eric Botcazou 2005-12-04 16:34:12 UTC
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
Comment 43 Paolo Carlini 2005-12-04 16:43:27 UTC
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...
Comment 44 Paolo Carlini 2005-12-04 17:11:50 UTC
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.
Comment 45 Eric Botcazou 2005-12-04 19:31:15 UTC
> 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
Comment 46 Paolo Carlini 2005-12-04 19:46:49 UTC
(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...
Comment 47 Pedro Lamarão 2005-12-04 20:11:34 UTC
Any reason why libsupc++ can't include the stuff in config/ ?
I'm interested in seeing this bug go, I'd work on it.
Comment 48 Paolo Carlini 2005-12-04 20:20:08 UTC
(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?

Comment 49 Paolo Carlini 2005-12-04 20:29:31 UTC
(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. 
Comment 50 Paolo Carlini 2005-12-04 20:52:34 UTC
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 !?!
Comment 51 Eric Botcazou 2005-12-04 21:01:25 UTC
> 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.
Comment 52 Paolo Carlini 2005-12-04 21:04:51 UTC
(In reply to comment #51)

> +#define __cpluplus 1

                 ^
Gosh! Thanks Eric for noticing and further testing.
Comment 53 Eric Botcazou 2005-12-04 21:22:21 UTC
> 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
Comment 54 Paolo Carlini 2005-12-04 21:33:36 UTC
(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.
Comment 55 Marc Glisse 2006-05-09 13:55:31 UTC
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 :-)
Comment 56 Marc Glisse 2006-05-09 14:24:19 UTC
(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)
Comment 57 Gabriel Dos Reis 2006-05-09 15:15:39 UTC
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
Comment 58 Benjamin Kosnik 2007-03-28 17:32:42 UTC
Request to re-assign to me.

-benjamin
Comment 59 gdr@cs.tamu.edu 2007-03-28 17:43:13 UTC
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
Comment 60 Benjamin Kosnik 2007-03-28 17:48:41 UTC
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)
Comment 61 Benjamin Kosnik 2007-03-28 17:49:22 UTC
mine, try two
Comment 62 gdr@cs.tamu.edu 2007-03-28 17:54:14 UTC
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
Comment 63 Benjamin Kosnik 2007-03-28 18:18:44 UTC

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.

Comment 64 Marc Glisse 2007-03-29 12:29:41 UTC
(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?
Comment 65 Benjamin Kosnik 2007-04-02 09:49:24 UTC
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

Comment 66 bss03@volumehost.net 2007-08-19 01:51:15 UTC
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.

Comment 67 Chris Jefferson 2008-12-19 11:45:09 UTC
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?
Comment 68 Jonathan Wakely 2010-04-29 09:49:05 UTC
(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)
Comment 69 Paolo Carlini 2010-04-29 09:53:53 UTC
For testing, I would suggest also involving Rainer, now he is quite active on Solaris.
Comment 70 Marc Glisse 2010-04-29 10:27:42 UTC
(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...
Comment 71 Jonathan Wakely 2011-03-07 15:57:59 UTC
N.B. The latest C++0x draft, N3042, specifies the value 201103L
Comment 72 Paolo Carlini 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?)
Comment 73 ro@CeBiTec.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
Comment 74 Marc Glisse 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.
Comment 75 Paolo Carlini 2011-03-07 19:58:24 UTC
For 4.7, if Rainer can help testing, we can certainly seriously attack and resolve this issue.
Comment 76 ro@CeBiTec.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
Comment 77 Paolo Carlini 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.
Comment 78 ro@CeBiTec.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
Comment 79 Jonathan Wakely 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
Comment 80 __vic 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?
Comment 81 Paolo Carlini 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...
Comment 82 ro@CeBiTec.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
Comment 83 Paolo Carlini 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...
Comment 84 ro@CeBiTec.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
Comment 85 Paolo Carlini 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.
Comment 86 ro@CeBiTec.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
Comment 87 Paolo Carlini 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...
Comment 88 ro@CeBiTec.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
Comment 89 Paolo Carlini 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...
Comment 90 Marc Glisse 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.
Comment 91 Marc Glisse 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.
Comment 92 Marc Glisse 2011-07-30 21:08:20 UTC
Created attachment 24874 [details]
for Solaris 11

Still some bugs. And I didn't include the patch to mangle std::tm/ldiv_t/... as if they were in the global namespace so the ABI is broken. And the c++config bit would need proper guarding. And the patch includes unrelated stuff I had to patch along the way.
Comment 93 Paolo Carlini 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!
Comment 94 Marc Glisse 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.
Comment 95 Marc Glisse 2011-07-31 14:03:39 UTC
Created attachment 24877 [details]
More solaris fixinclude
Comment 96 ro@CeBiTec.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
Comment 97 ro@CeBiTec.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
Comment 98 Marc Glisse 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).
Comment 99 Marc Glisse 2011-08-01 14:38:24 UTC
Created attachment 24883 [details]
Solaris fixinclude

This should wrap the pow overloads to remove them in C++0X instead of always (as in cmath). Untested (my virtualbox solaris doesn't answer ssh today).
Comment 100 Marc Glisse 2011-08-01 16:17:25 UTC
Created attachment 24884 [details]
Alter mangling of std::tm and std::ldiv_t

And I attach a patch that mangles std::tm as ::tm, and the same for ldiv_t. Of course it would also require div_t, lconv, and whatever else a grep will turn up. Note that I don't understand half of the macros in the patch (everything to do with TYPE is likely useless) but it seems to work.

Note also that I don't answer the question of whether we want to do such a thing (which should allow compatibility with older gcc and can be reverted at the next ABI break), or even do it just for solaris.

(if anyone wants to try, you'll likely hit PR 49914, which can be worked around by s/abs/llabs/ wherever it complains)
Comment 101 Paolo Carlini 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...
Comment 102 ro@CeBiTec.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
Comment 103 Marc Glisse 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.
Comment 104 Andrew Paprocki 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.
Comment 105 Andrew Paprocki 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
$
Comment 106 Marc Glisse 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__...
Comment 107 Marc Glisse 2011-08-04 14:20:12 UTC
Created attachment 24917 [details]
tested patch

I tested this patch on S10 (the headers are really the same as in S11) and it doesn't seem to cause unexpected failures in libstdc++. The mangling patch, on the other hand, is broken: it forgets "const", for example in "const std::tm*". I am not sure what I am doing wrong (I basically copied the code used to give a special mangling to std::string).

The list of all structs in namespace std is: div_t, lconv, ldiv_t, tm.
Comment 108 Paolo Carlini 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?
Comment 109 Marc Glisse 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?
Comment 110 Paolo Carlini 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?
Comment 111 Marc Glisse 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.
Comment 112 Marc Glisse 2011-08-05 15:11:43 UTC
Created attachment 24921 [details]
Mangling compatibility

Checking cp_type_quals (the documentation advertises the long-dead CP_TYPE_QUALS macro) helped, but the substitution stack ended up shifted by one. Patching write_unscoped_name is easier and abi_check now passes. Anyway, this is more a proof of concept so we can decide if we want to tinker with mangling, as I am sure a C++ FE guy could rewrite something much cleaner.
Comment 113 ro@CeBiTec.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
Comment 114 Rainer Orth 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
Comment 115 Rainer Orth 2011-08-18 17:38:13 UTC
Finally fixed for 4.7.0, many thanks to all contributors for patches, analysis
and support.

  Rainer
Comment 116 Paolo Carlini 2011-08-21 22:02:23 UTC
Thank you Rainer, and Marc, for the huge analysis and programming and testing effort.
Comment 117 Ruben Van Boxem 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.
Comment 118 Jonathan Wakely 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
Comment 119 Paolo Carlini 2011-09-28 12:23:51 UTC
If you ask me, no way.
Comment 120 Ruben Van Boxem 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++*?
Comment 121 Marc Glisse 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.
Comment 122 Jonathan Wakely 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.
Comment 123 Jason Merrill 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
Comment 124 Bruce Adams 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
Comment 125 Paolo Carlini 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.
Comment 126 Paolo Carlini 2011-11-25 19:22:06 UTC
"201103" of course.
Comment 127 Bruce Adams 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?
Comment 128 Jonathan Wakely 2011-11-26 12:30:25 UTC
Your test script runs blah twice, but you probably meant to run blah2
Comment 129 Bruce Adams 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.