[Bug c++/64816] New: gcc claims that constructor is private when it should be accessible

[Bug c++/64816] New: gcc claims that constructor is private when it should be accessible

[thakis at chromium dot org]

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

            Bug ID: 64816
           Summary: gcc claims that constructor is private when it should
                    be accessible
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thakis at chromium dot org

I came across this while trying to build chromium for android with libc++ and
gcc. Here's an attempt at a reduction:


$ cat repro2.cc
namespace std {

template <class _Iter> class __wrap_iter {
private:
  __wrap_iter(_Iter __x) {}

  template <class _CharT> friend class basic_string;
  template <class _Tp> friend class vector;
};

template <class _CharT> class basic_string {
public:
  typedef const char *const_pointer;
  typedef __wrap_iter<const_pointer> const_iterator;

  const_iterator begin() const {return const_iterator(const_pointer(0));}
};
typedef basic_string<char> string;

template <class _Tp> class vector {
public:
  typedef const _Tp *const_pointer;
  typedef __wrap_iter<const_pointer> const_iterator;

  const_iterator begin() const {return const_iterator(const_pointer(0));}
};

} // namespace std

void g(const std::vector<char> &v) { v.begin(); }

# gcc doesn't like this (also broken in 4.4 and 4.9):
$ gcc-4.8.1 -c repro2.cc 
gcc-4.8.1: warning: couldn’t understand kern.osversion ‘14.0.0
repro2.cc: In instantiation of ‘std::vector<_Tp>::const_iterator
std::vector<_Tp>::begin() const [with _Tp = char;
std::vector<_Tp>::const_iterator = std::__wrap_iter<const char*>]’:
repro2.cc:30:46:   required from here
repro2.cc:5:3: error: ‘std::__wrap_iter<_Iter>::__wrap_iter(_Iter) [with _Iter
= const char*]’ is private
   __wrap_iter(_Iter __x) {}
   ^
repro2.cc:25:71: error: within this context
   const_iterator begin() const {return const_iterator(const_pointer(0));}
                                                                       ^

It's true that the constructor is private, but vector is also a friend.

clang likes it (icc too):

$ bin/clang -c repro2.cc


To make this more mysterious, gcc stops rejecting the problem if:

1.) I change `typedef const char *const_pointer;` to `typedef const _CharT
*const_pointer;`

2.) or I declare `template <class _Tp> class vector;` before class __wrap_iter

3.) or I remove class basic_string (and typedef string) -- even though they
aren't referenced anywhere.
>From gcc-bugs-return-475004-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 27 06:40:01 2015
Return-Path: <gcc-bugs-return-475004-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25283 invoked by alias); 27 Jan 2015 06:39:48 -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 25074 invoked by uid 48); 27 Jan 2015 06:39:13 -0000
From: "amker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can
Date: Tue, 27 Jan 2015 06:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: jiwang at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62173-4-hWod8VWs7i@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62173-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62173-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-01/txt/msg02998.txt.bz2
Content-length: 1718

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

--- Comment #26 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #17)
> I really wonder why IVOPTs calls convert_affine_scev with
> !use_overflow_semantics.
I don't understand below code in convert_affine_scev:

  enforce_overflow_semantics = (use_overflow_semantics
                && nowrap_type_p (type));
According to comments,

   "USE_OVERFLOW_SEMANTICS is true if this function should assume that
   the rules for overflow of the given language apply (e.g., that signed
   arithmetics in C does not overflow) -- i.e., to use them to avoid
unnecessary
   tests, but also to enforce that the result follows them."

Seems to me we need to enforce overflow check for result if we take advantage
of USE_OVERFLOW_SEMANTICS to prove there is no overflow for src.  So shouldn't
we set enforce_overflow_semantics according to "nowrap_type_p (TREE_TYPE
(*base))", rather than the result type.  Also it is noted at the end of
function, that we can't use the fact "signed variables do not overflow" when we
are checking for result.

But the function is used widespread in scev, there shouldn't be anything so
wrong.


>
> Note that for the original testcase 'i' may be negative or zero and thus 'd'
> may be zero.  We do a bad analysis here because IVOPTs follows complete
> peeling immediately...  but at least we have range information that looks
> useful:

The case also holds for O2, at this level gcc won't completely unroll the first
loop.

An irrelevant question.  Isn't cunroll too aggressive in GCC?  For cases like
this one, the code size is bloated and may hurt Icache performance, while only
saving several increment instruction.

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-27
                 CC|                            |ville.voutilainen at gmail dot com
     Ever confirmed|0                           |1
      Known to fail|                            |4.8.2, 4.9.1, 5.0

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[thakis at chromium dot org]

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

--- Comment #1 from thakis at chromium dot org ---
(Here's a patch with a libc++-side workaround: http://reviews.llvm.org/D7201
But it'd be good to fix this in the compiler too, of course.)

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

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

--- Comment #2 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Looks like the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66957
may have fixed this. Paolo, would you like to clean this up with a testcase?

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Hi Ville. Unfortunately it still fails for me, in the same way. Are you using
the complete testcase, including the line outside namespace std?

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Sorry for the noise, I managed to drop out that last line, bummer. So no, this
hasn't been fixed yet.