[Bug c++/57239] New: GCC cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[Bug c++/57239] New: GCC cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[scottbaldwin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

            Bug ID: 57239
           Summary: GCC cannot handle inner/nested class templates with
                    non-type parameter packs that were declared in the
                    outer/containing class
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: scottbaldwin at gmail dot com

GCC 4.7.2 and 4.8.x cannot handle inner/nested class templates with non-type
parameter packs that were declared in the outer/containing class's template
parameter list. This bug can result in either an "internal compile error", or
even generate incorrect code (both are demonstrated), which is why I marked
this bug as "major".

I encountered this bug while trying to implement a helper template called
is_instantiation_of__nontypes<> which is a non-type-parameter counterpart to
the is_instantiation_of<> template described at
[http://stackoverflow.com/questions/11251376/].

The demos below (one for compile-time error demo, one for run-time error demo)
are implementations of this is_instantiation_of__nontypes<> template and work
fine in clang, but in gcc 4.7.2 and 4.8.x fail to compile or produce incorrect
results. These demos should compile "out of the box" as they have no
dependencies other than the standard libraries.

----------------------------------------
compile-time error demo
----------------------------------------

    // generic version of is_instantiation_of__nontypes<> (the template to
check against is template-template parameter 'TT', taking "values" of the
non-type parameter pack 'Ts...' declared in outer/containing class)

    template<bool BoolVal, char CharVal>
    struct Foo {};

    template<typename... Ts>
    struct is_instantiation_of__nontypes
    {
        template<template<Ts...> class TT, typename T>
        struct check : std::false_type {};

        template<template<Ts...> class TT, Ts... Args>
        struct check<TT, TT<Args...>> : std::true_type {};
    };

    int main() {
        using FooInstantiation = Foo<false, 'x'>;
        std::cout << ((is_instantiation_of__nontypes<bool, char>::check<Foo,
FooInstantiation>::value) ? "yes" : "no") << endl;
    }
---
This fails to compile in gcc 4.7.2/4.8.x with the following errors:

[gcc 4.7.2]:
    make[1]: compiling [sandbox_cpp11.cpp] (gcc 4.7.2)
    sandbox_cpp11.cpp: In function ‘void gcc_bug_demo_3::_go_()’:
    sandbox_cpp11.cpp:122:88: error: type/value mismatch at argument 1 in
template parameter list for ‘template<class ... Ts>
template<template<template<Ts ...<anonymous> > class TT, class T>
template<class ... Ts> template<Ts ...<anonymous> > class TT, class T> struct
gcc_bug_demo_3::is_instantiation_of__nontypes<Ts>::check’
    sandbox_cpp11.cpp:122:88: error:   expected a template of type
‘template<class ... Ts> template<Ts ...<anonymous> > class TT’, got
‘template<bool BoolVal, char CharVal> struct gcc_bug_demo_3::Foo’
    make[1]: *** [dbg-mt/sandbox_cpp11.o] Error 1
    make: *** [objs] Error 2

[gcc 4.8.x]:
    make[1]: compiling [sandbox_cpp11.cpp] (gcc 4.8.x)
    sandbox_cpp11.cpp:116:27: error: ‘Ts ...’ is not a valid type for a
template non-type parameter
       struct check<TT, TT<Args...>> : std::true_type {};
                               ^
    sandbox_cpp11.cpp:116:30: error: template argument 2 is invalid
       struct check<TT, TT<Args...>> : std::true_type {};
                                  ^
    sandbox_cpp11.cpp: In function ‘void gcc_bug_demo_3::_go_()’:
    sandbox_cpp11.cpp:122:88: error: type/value mismatch at argument 1 in
template parameter list for ‘template<class ... Ts>
template<template<template<Ts ...<anonymous> > class TT, class T>
template<class ... Ts> template<Ts ...<anonymous> > class TT, class T> struct
gcc_bug_demo_3::is_instantiation_of__nontypes<Ts>::check’
       std::cout << ((is_instantiation_of__nontypes<bool, char>::check<Foo,
FooInstantiation>::value) ? "yes" : "no") << endl;
                                                                               
        ^
    sandbox_cpp11.cpp:122:88: error:   expected a template of type
‘template<class ... Ts> template<Ts ...<anonymous> > class TT’, got
‘template<bool BoolVal, char CharVal> struct gcc_bug_demo_3::Foo’
    make[1]: *** [dbg-mt/sandbox_cpp11.o] Error 1
    make: *** [objs] Error 2

4.8.x is slightly more verbose with the additional "error: ‘Ts ...’ is not a
valid type for a template non-type parameter", which is incorrect since 'Ts...'
was properly declared as a parameter pack in the containing class's template
parameter list.
In fact, if you simplify the code (by removing template-template parameter 'TT'
and replacing it w/ hard-coded template class 'Foo') then it compiles fine, but
has incorrect results at runtime, as demonstrated in the following code ...

----------------------------------------
run-time error demo
----------------------------------------

    // simplified version of is_instantiation_of__nontypes<> (the template to
check against is hardcoded as template 'Foo', instead of being
template-template parameter 'TT')
    // compiles without error in all 4 compilers tested (gcc 4.7.2, 4.8.0,
4.8.1, and clang 3.3), but only has correct runtime results (output of "yes")
when compiled with clang.

    template<bool BoolVal, char CharVal>
    struct Foo {};

    template<typename... Ts>
    struct is_instantiation_of__nontypes // hard-coded for class template Foo
    {
        template<typename T>
        struct check : std::false_type {};

        template<Ts... Args>
        struct check<Foo<Args...>> : std::true_type {};
    };

    int main() {
        using FooInstantiation = Foo<false, 'x'>;
        // the next line will output "yes" if the compiler has correct logic,
or "no" otherwise
        std::cout << ((is_instantiation_of__nontypes<bool,
char>::check<FooInstantiation>::value) ? "yes" : "no") << std::endl;
    }

This demo outputs "yes" when compiled with clang (3.3), but outputs "no" when
compiled with gcc (4.7.2 or 4.8.x).
>From gcc-bugs-return-422035-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 10 16:05:46 2013
Return-Path: <gcc-bugs-return-422035-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13499 invoked by alias); 10 May 2013 16:05:46 -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 13451 invoked by uid 48); 10 May 2013 16:05:41 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57239] GCC cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
Date: Fri, 10 May 2013 16:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: UNCONFIRMED
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_severity
Message-ID: <bug-57239-4-DA6ov8LROt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57239-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57239-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: 2013-05/txt/msg00708.txt.bz2
Content-length: 298

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW239

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
The report misses a complete example. The following is a reduced form and free
of library stuff:

//-------------------------------------------------------
struct true_type { enum { value = true }; };
struct false_type { enum { value = false }; };

template<bool BoolVal, char CharVal>
struct Foo {};

template<typename... Ts>
struct is_instantiation_of_nontypes
{
  template<template<Ts...> class TT, typename T>
  struct check : false_type {};

  template<template<Ts...> class TT, Ts... Args>
  struct check<TT, TT<Args...>> : true_type {};
};

static_assert(is_instantiation_of_nontypes<bool, char>::check<Foo, Foo<false,
'x'> >::value, "Ouch");
//-------------------------------------------------------

compiled with gcc 4.9.0 20130505 (experimental) gives the error

"main.cpp|14|error: 'Ts ...' is not a valid type for a template non-type
parameter|
main.cpp|14|error: template argument 2 is invalid|
main.cpp|17|error: type/value mismatch at argument 1 in template parameter list
for 'template<class ... Ts> template<template<template<Ts ...<anonymous> >
class TT, class T> template<class ... Ts> template<Ts ...<anonymous> > class
TT, class T> struct is_instantiation_of_nontypes<Ts>::check'|
\main.cpp|17|error:   expected a template of type 'template<class ... Ts>
template<Ts ...<anonymous> > class TT', got 'template<bool BoolVal, char
CharVal> struct Foo'"
>From gcc-bugs-return-422083-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 11 15:15:08 2013
Return-Path: <gcc-bugs-return-422083-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1693 invoked by alias); 11 May 2013 15:15:08 -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 1625 invoked by uid 48); 11 May 2013 15:15:03 -0000
From: "scottbaldwin at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
Date: Sat, 11 May 2013 15:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: scottbaldwin at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-57239-4-hjgzHP9DOM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57239-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57239-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg00756.txt.bz2
Content-length: 1127

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #2 from etherice <scottbaldwin at gmail dot com> ---
(In reply to Daniel Krügler from comment #1)
> The report misses a complete example. The following is a reduced form and
> free of library stuff:
> 
> //-------------------------------------------------------
> ...

The reason I provided two separate examples (which both appear complete to me,
and only use standard headers <iostream> and <type_traits>) was to demonstrate
that the bug can either result in compilation errors, but in some cases not
have any compilation errors at all (in which case incorrect code is generated
unless explicitly checked for with a static_assert or template
metaprogramming-based error).

The "compile-time error demo" (the one you reduced), by itself, does not
demonstrate the latter case since the test (whether it's a static or runtime
test) can never be "reached" due to the compile error ("'Ts ...' is not a valid
type for a template non-type parameter", which is essentially the same in
4.7/4.8/4.9). So both examples were needed to show the full extent.
>From gcc-bugs-return-422084-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 11 17:08:04 2013
Return-Path: <gcc-bugs-return-422084-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22344 invoked by alias); 11 May 2013 17:08:03 -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 22194 invoked by uid 48); 11 May 2013 17:08:00 -0000
From: "steven at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions, other compilers generate better code than gcc
Date: Sat, 11 May 2013 17:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: missed-optimization, ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: steven at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_reconfirmed_on short_desc
Message-ID: <bug-55278-4-qRmNhDwjdE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55278-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55278-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: 2013-05/txt/msg00757.txt.bz2
Content-length: 702

http://gcc.gnu.org/bugzilla/show_bug.cgi?idU278

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2013-03-23 00:00:00         |2013-05-11 0:00
            Summary|[4.8/4.9 Regression] Botan  |[4.8/4.9 Regression] Botan
                   |performance regressions     |performance regressions,
                   |apparently due to LRA       |other compilers generate
                   |                            |better code than gcc

--- Comment #13 from Steven Bosscher <steven at gcc dot gnu.org> ---
Per comment #11, not an LRA issue.

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[scottbaldwin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #3 from etherice <scottbaldwin at gmail dot com> ---
Status is still unconfirmed... How long does it typically take to confirm a
bug?

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Until someone analyses it and convinces themselves it's a bug.

Not providing a complete testcase doesn't help. Code missing headers, even
standard ones, is not complete, and certainly doesn't compile "out of the box"
because I need to add headers. http://gcc.gnu.org/bugs/ clearly says not to
leave headers out, why should I have to figure out which headers you failed to
include in the testcase to analyse your bug report?

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
N.B. Clang trunk aborts on Daniel's testcase and your first one.

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[scottbaldwin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #6 from etherice <scottbaldwin at gmail dot com> ---
(In reply to Jonathan Wakely from comment #4)
> Until someone analyses it and convinces themselves it's a bug.
> 
> Not providing a complete testcase doesn't help. Code missing headers, even
> standard ones, is not complete, and certainly doesn't compile "out of the
> box" because I need to add headers. http://gcc.gnu.org/bugs/ clearly says
> not to leave headers out, why should I have to figure out which headers you
> failed to include in the testcase to analyse your bug report?

----------------------------------------

1) Did you see the reply from Daniel Krügler? He included a complete example.

----------------------------------------

2) My example was complete except for needing a couple #includes for <iostream>
and <type_traits>. Here it is w/ those includes:

#include <type_traits>
#include <iostream>

template<bool BoolVal, char CharVal>
struct Foo {};

template<typename... Ts>
struct is_instantiation_of__nontypes
{
    template<template<Ts...> class TT, typename T>
    struct check : std::false_type {};

    template<template<Ts...> class TT, Ts... Args>
    struct check<TT, TT<Args...>> : std::true_type {};
};

int main() {
    using FooInstantiation = Foo<false, 'x'>;
    std::cout << ((is_instantiation_of__nontypes<bool, char>::check<Foo,
FooInstantiation>::value) ? "yes" : "no") << std::endl;
}

----------------------------------------

3) clang version 3.3 (trunk 176796) compiles it fine and produces the correct
output of "yes", while gcc (all versions) blow up with some variant of:

error: ‘Ts ...’ is not a valid type for a template non-type parameter
   struct check<TT, TT<Args...>> : std::true_type {};
                           ^
error: template argument 2 is invalid
   struct check<TT, TT<Args...>> : std::true_type {};
                              ^
error: type/value mismatch at argument 1 in template parameter list for
‘template<class ... Ts> template<template<template<Ts ...<anonymous> > class
TT, class T> template<class ... Ts> template<Ts ...<anonymous> > class TT,
class T> struct is_instantiation_of__nontypes<Ts>::check’
   std::cout << ((is_instantiation_of__nontypes<bool, char>::check<Foo,
FooInstantiation>::value) ? "yes" : "no") << std::endl;

error:   expected a template of type ‘template<class ... Ts> template<Ts
...<anonymous> > class TT’, got ‘template<bool BoolVal, char CharVal> struct
Foo’

----------------------------------------

4) Convincing oneself that this is a bug should not be difficult. Section
14.1.15 of the C++11 standard makes it very clear that this code contains a
valid expansion of a non-type template parameter pack declared in a different
template-parameter-list. It even offers a very similar example, taken directly
from § 14.1.15:

template<class... T> struct value_holder {
template<T... Values> apply { }; // Values is a non-type template parameter
pack
// and a pack expansion
};
>From gcc-bugs-return-425185-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 26 11:12:31 2013
Return-Path: <gcc-bugs-return-425185-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5462 invoked by alias); 26 Jun 2013 11:12:31 -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 5424 invoked by uid 48); 26 Jun 2013 11:12:25 -0000
From: "petschy at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57723] Missed optimization: recursion around empty function
Date: Wed, 26 Jun 2013 11:12: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: petschy at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-57723-4-QGYBVwobCw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57723-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57723-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: 2013-06/txt/msg01564.txt.bz2
Content-length: 345

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW723

--- Comment #4 from petschy at gmail dot com ---
Ooops, the test case won't perform the freeing completely, since the recursive
call is not inside the 'down' traversal loop, so only the first node on the
given level would be recursively freed, but this doesn't affect the missed
optimization.

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-26
     Ever confirmed|0                           |1

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to etherice from comment #6)
> 2) My example was complete except for needing a couple #includes [...]

So it was not complete then!

This bug has already been confirmed, except for updating the status (see how
unhelpful that is?)


If five people try to analyse the bug report then five people have to waste
their time fixing your testcase because you didn't paste in two little lines
which you already had in your version of the code.

I think this can be confirmed, but please read the bug submission guidelines
next time.

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[scottbaldwin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #8 from etherice <scottbaldwin at gmail dot com> ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to etherice from comment #6)
> > 2) My example was complete except for needing a couple #includes [...]
> 
> So it was not complete then!
> 
> This bug has already been confirmed, except for updating the status (see how
> unhelpful that is?)
> 
> If five people try to analyse the bug report then five people have to waste
> their time fixing your testcase because you didn't paste in two little lines
> which you already had in your version of the code.
>
> I think this can be confirmed, but please read the bug submission guidelines
> next time.

Good, and points taken.

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[scottbaldwin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #10 from etherice <scottbaldwin at gmail dot com> ---
(In reply to Paolo Carlini from comment #9)
> By the way, much more generally, I'm under the impression that often bug
> submitters attach way too much importance to the status change unconfirmed
> -> confirmed: I think it would be easy to prove that quite often bugs are
> fixed when still unconfirmed or that hard bugs are fixed when maintainers
> actually can do the work (eg, the timeframe when a bug is filed matters much
> more than its confirmed status to predict whether it will be fixed soon)

Isn't it defeating the purpose of having a 'status' field if it's not being
used? It seems especially important for the situation you mentioned -- for the
"hard bugs" that take longer to fix, an *initial* status update informs the
submitter that the bug report has been reviewed and is on the dev team's radar.
Otherwise, it's like the report is never even acknowledge until it's actually
fixed, and I imagine most submitters will seek *some* kind of status update
eventually.

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to etherice from comment #10)
> Isn't it defeating the purpose of having a 'status' field if it's not being
> used?

What makes you think it isn't used?  Paolo is saying that the difference
between UNCONFIRMED and NEW is often irrelevant for the submitter's purposes,
that doesn't mean the entire field isn't used. The ASSIGNED and RESOLVED values
are obviously not the same as UNCONFIRMED/NEW.

> It seems especially important for the situation you mentioned -- for
> the "hard bugs" that take longer to fix, an *initial* status update informs
> the submitter that the bug report has been reviewed and is on the dev team's
> radar. Otherwise, it's like the report is never even acknowledge until it's
> actually fixed, and I imagine most submitters will seek *some* kind of
> status update eventually.

But there is no "dev team" so there's no radar for it to meaningfully be on. 
That's not how GCC works.  Confirming the bug means at least one person agrees
it's a real bug, and noone else has disagreed strongly enough to say it's
INVALID, it doesn't mean it's on anyone's TODO list or a fix is in progress.

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[scottbaldwin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #12 from etherice <scottbaldwin at gmail dot com> ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to etherice from comment #10)
> > Isn't it defeating the purpose of having a 'status' field if it's not being
> > used?
> 
> What makes you think it isn't used?

His comment that "quite often bugs are fixed when still unconfirmed". In those
cases, when it isn't used, the submission isn't even acknowledged until the bug
is fixed.

> Paolo is saying that the difference
> between UNCONFIRMED and NEW is often irrelevant for the submitter's
> purposes, that doesn't mean the entire field isn't used. The ASSIGNED and
> RESOLVED values are obviously not the same as UNCONFIRMED/NEW.

The point was more about setting an initial status -- something -- to
acknowledge the submission was reviewed.

> But there is no "dev team" so there's no radar for it to meaningfully be on.

I meant the group of developers maintaining gcc.

> That's not how GCC works. Confirming the bug means at least one person
> agrees it's a real bug, and noone else has disagreed strongly enough to say
> it's INVALID, it doesn't mean it's on anyone's TODO list or a fix is in
> progress.

But you agree that it says *something*, which is better than nothing. It's some
kind of acknowledgement to the submitter that the report was reviewed by
someone and not just lost in the shuffle.

Paulo's observation that "often bug submitters attach way too much importance
to the status change". I can't speak for everyone, but it sounds like bug
submitters eventually become curious about the status of their submissions,
after enough time passes.

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239

--- Comment #13 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Curious, I understand, assuming they don't take new as a solid indication that
a fix is forthcoming. assigned normally is more reliable for that, still not
much more, unless, as I tried to explain, there are other reasons like the bug
is a regression, a release is close, etc.

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
clang accepts the reduced testcase in comment #1 but MSVC and ICC both reject
it too.

MSVC:

<source>(18): error C3201: the template parameter list for class template 'Foo'
does not match the template parameter list for template parameter 'TT'
<source>(18): error C2955: 'is_instantiation_of_nontypes<bool,char>::check':
use of class template requires template argument list
<source>(12): note: see declaration of
'is_instantiation_of_nontypes<bool,char>::check'
<source>(18): error C2338: Ouch

ICC:
<source>(11): error: parameter pack "Ts" was referenced but not expanded
    template<template<Ts...> class TT, typename T>
                      ^

<source>(14): error: parameter pack "Ts" was referenced but not expanded
    template<template<Ts...> class TT, Ts... Args>
                      ^

<source>(14): warning #885: constant "Args" is not used in or cannot be deduced
from the template argument list of class template
"is_instantiation_of_nontypes<Ts...>::check<TT, TT<Args...>> [with Ts=<bool,
char>]"
    template<template<Ts...> class TT, Ts... Args>
                                             ^
          detected during instantiation of class
"is_instantiation_of_nontypes<Ts...> [with Ts=<bool, char>]" at line 18

<source>(18): error: static assertion failed with "Ouch"
  static_assert(is_instantiation_of_nontypes<bool, char>::check<Foo, Foo<false,
'x'> >::value, "Ouch");
  ^


GCC rejects it with:
<source>:15:27: error: expansion pattern '<anonymous>' contains no parameter
packs
   15 |   struct check<TT, TT<Args...>> : true_type {};
      |                           ^~~
<source>:15:30: error: template argument 2 is invalid
   15 |   struct check<TT, TT<Args...>> : true_type {};
      |                              ^~
<source>:18:87: error: static assertion failed: Ouch
   18 | static_assert(is_instantiation_of_nontypes<bool, char>::check<Foo,
Foo<false, 'x'> >::value, "Ouch");
      |              
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~