public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "thakis at chromium dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/64816] New: gcc claims that constructor is private when it should be accessible Date: Tue, 27 Jan 2015 06:09:00 -0000 [thread overview] Message-ID: <bug-64816-4@http.gcc.gnu.org/bugzilla/> (raw) 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.
next reply other threads:[~2015-01-27 6:09 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-27 6:09 thakis at chromium dot org [this message] 2015-01-27 12:45 ` [Bug c++/64816] " ville.voutilainen at gmail dot com 2015-01-27 17:55 ` thakis at chromium dot org 2015-08-21 11:13 ` ville.voutilainen at gmail dot com 2015-08-21 14:54 ` paolo.carlini at oracle dot com 2015-08-21 14:59 ` ville.voutilainen at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-64816-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).