[Bug libstdc++/65899] New: std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private

[Bug libstdc++/65899] New: std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private

[bastian.beischer@rwth-aachen.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65899

            Bug ID: 65899
           Summary: std::basic_stringbuf member __xfer_bufptrs should be
                    explicitly declared private
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: trivial
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bastian.beischer@rwth-aachen.de
  Target Milestone: ---

I'm trying to compile code with GCC 5.1.0 which makes use of the good ole:

#define private public

hack (for some reason). I know, I know, but it's not my code and I'd like it to
compile out of the box...

Now the issue is this: In GCC 5.1.0's version of the sstream header one finds
the following:

  template<typename _CharT, typename _Traits, typename _Alloc>
    class basic_stringbuf : public basic_streambuf<_CharT, _Traits>
    {
      struct __xfer_bufptrs;
    public:
      // Types:
      typedef _CharT                                    char_type;
      typedef _Traits                                   traits_type;

[...]

    private:

[...]

      struct __xfer_bufptrs
      {

[...]


The problem is that the member __xfer_bufptrs is implicitly private when it's
declared but then later it's expliclity marked private.

Then, due to the #define private public, the second one turns public but the
first one does not and there's a conflict leading to this error:

/usr/include/c++/5.1.0/sstream:335:7: error: ‘struct
std::basic_stringbuf<_CharT, _Traits, _Alloc>::__xfer_bufptrs’ redeclared with
different access
       struct __xfer_bufptrs
       ^


Any chance to mark the first instance private explicitly?
>From gcc-bugs-return-484719-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 27 12:10:21 2015
Return-Path: <gcc-bugs-return-484719-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8251 invoked by alias); 27 Apr 2015 12:10:21 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8204 invoked by uid 48); 27 Apr 2015 12:10:17 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
Date: Mon, 27 Apr 2015 12:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65886-4-N2azXs109R@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65886-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65886-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg02271.txt.bz2
Content-length: 677

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide886

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #12)
> First of all, why is this filed as a GCC bug?  And what is PIE specific on
> the issue?  I mean, if -Bsymbolic doesn't cope well with like copy
> relocations, then
> the testcase doesn't work on most targets when the binary is normal
> executable rather than PIE.

It is true that the testcase doesn't work with normal executable.  I
don't believe GCC is wrong to generate copy relocation in PIE.  It
is only a GCC bug that PIE worked before, it doesn't work now and
there is no command option to make PIE to work.

[Bug libstdc++/65899] std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65899

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
No. Use -fno-access-control which does it properly.

[Bug libstdc++/65899] std::basic_stringbuf member __xfer_bufptrs should be explicitly declared private

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65899

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Ugh, -fno-access-control doesn't prevent the error.

Then I suggest using -include sstream, so that stringstream is included before
some idiot comes along and redefines a keyword.

But I'm not interested in supporting -Dprivate=public, it's just wrong.