public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/67152] New: [concepts] bogus "partial specialization of ‘foo<T>’ after instantiation" error
@ 2015-08-07 23:39 eric.niebler at gmail dot com
  2015-08-08 22:02 ` [Bug c++/67152] " jason at gcc dot gnu.org
  2015-08-08 22:13 ` jason at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: eric.niebler at gmail dot com @ 2015-08-07 23:39 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5143 bytes --]

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

            Bug ID: 67152
           Summary: [concepts] bogus "partial specialization of ‘foo<T>’
                    after instantiation" error
           Product: gcc
           Version: c++-concepts
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

The error happens on constrained partial specializations of a template that has
already been instantiated. But the template that got instantiated would fail
the constraint anyway, so the error is complaining about nothing AFAICT.
Consider:

template <class T>
concept bool HasType = requires { typename T::type; };

template<class T>
struct trait {
  using type = void;
};

struct has_type { using type = void; };

// Instantiation here
trait<has_type>::type foo() {}

// constrained version here. Type "has_type" would fail this
// constraint so this partial specialization would not have been
// selected.
template<class T>
  requires !HasType<T>
struct trait<T> {
  using type = void;
};


...yields the following:

test.cpp:17:8: error: partial specialization of ‘struct trait<T>’ after
instantiation of ‘struct trait<has_type>’ [-fpermissive]
 struct trait<T> {
        ^

If the partial specialization is the following instead:

template<class T>
struct trait<T*> {
  using type = void;
};

then there is no error. It seems to me that for partial specializations, a
constraints failure should be treated similarly to a pattern match failure WRT
such errors.
>From gcc-bugs-return-494387-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 07 23:54:26 2015
Return-Path: <gcc-bugs-return-494387-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 105369 invoked by alias); 7 Aug 2015 23:54:26 -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 105334 invoked by uid 48); 7 Aug 2015 23:54:21 -0000
From: "ncm at cantrip dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67153] New: integer optimizations 53% slower than std::bitset<>
Date: Fri, 07 Aug 2015 23:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ncm at cantrip dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created
Message-ID: <bug-67153-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-08/txt/msg00529.txt.bz2
Content-length: 1584

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

            Bug ID: 67153
           Summary: integer optimizations 53% slower than std::bitset<>
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ncm at cantrip dot org
  Target Milestone: ---

Created attachment 36146
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id6146&actioníit
The std::bitset<> version

I have attached two small, semantically equivalent C++14 programs.

One uses std::bitset<26> for its operations; the other uses raw unsigned int.
The one that uses unsigned int runs 53% slower than the bitset<> version, as
compiled with g++-5.1 and running on a 2013-era Haswell i7-4770.  While this
represents, perhaps, a stunning triumph in the optimization of inline member
and lambda functions operating on structs, it may represent an equally
intensely embarrassing, even mystifying, failure for optimization of the
underlying raw integer operations.

For both, build and test was with

  $ g++-5 -O3 -march=native -mtune=native -g3 -Wall $PROG.cc
  $ time ./a.out | wc -l
  2818

Times on a 3.2GHz Haswell are consistently 0.25s for the unsigned int
version, 0.16s for the std::bitset<26> version.

These programs are archived at <https://github.com/ncm/nytm-spelling-bee/>.

The runtimes of the two versions are identical as built and run on my
2009 Westmere 2.4GHz i5-M520, and about the same as the integer version
on Haswell.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug c++/67152] [concepts] bogus "partial specialization of ‘foo<T>’ after instantiation" error
  2015-08-07 23:39 [Bug c++/67152] New: [concepts] bogus "partial specialization of ‘foo<T>’ after instantiation" error eric.niebler at gmail dot com
@ 2015-08-08 22:02 ` jason at gcc dot gnu.org
  2015-08-08 22:13 ` jason at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: jason at gcc dot gnu.org @ 2015-08-08 22:02 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Sat Aug  8 22:01:39 2015
New Revision: 226739

URL: https://gcc.gnu.org/viewcvs?rev=226739&root=gcc&view=rev
Log:
        PR c++/67152
        * pt.c (process_partial_specialization): Call
        associate_classtype_constraints.

Added:
    trunk/gcc/testsuite/g++.dg/concepts/partial-spec6.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/pt.c


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug c++/67152] [concepts] bogus "partial specialization of ‘foo<T>’ after instantiation" error
  2015-08-07 23:39 [Bug c++/67152] New: [concepts] bogus "partial specialization of ‘foo<T>’ after instantiation" error eric.niebler at gmail dot com
  2015-08-08 22:02 ` [Bug c++/67152] " jason at gcc dot gnu.org
@ 2015-08-08 22:13 ` jason at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: jason at gcc dot gnu.org @ 2015-08-08 22:13 UTC (permalink / raw)
  To: gcc-bugs

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org
   Target Milestone|---                         |6.0

--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-08-08 22:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-07 23:39 [Bug c++/67152] New: [concepts] bogus "partial specialization of ‘foo<T>’ after instantiation" error eric.niebler at gmail dot com
2015-08-08 22:02 ` [Bug c++/67152] " jason at gcc dot gnu.org
2015-08-08 22:13 ` jason at gcc dot gnu.org

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