* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
@ 2013-05-11 13:14 ` daniel.kruegler at googlemail dot com
2013-06-26 9:53 ` scottbaldwin at gmail dot com
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: daniel.kruegler at googlemail dot com @ 2013-05-11 13:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
2013-05-11 13:14 ` [Bug c++/57239] " daniel.kruegler at googlemail dot com
@ 2013-06-26 9:53 ` scottbaldwin at gmail dot com
2013-06-26 10:16 ` redi at gcc dot gnu.org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: scottbaldwin at gmail dot com @ 2013-06-26 9:53 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
2013-05-11 13:14 ` [Bug c++/57239] " daniel.kruegler at googlemail dot com
2013-06-26 9:53 ` scottbaldwin at gmail dot com
@ 2013-06-26 10:16 ` redi at gcc dot gnu.org
2013-06-26 10:29 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-26 10:16 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
` (2 preceding siblings ...)
2013-06-26 10:16 ` redi at gcc dot gnu.org
@ 2013-06-26 10:29 ` redi at gcc dot gnu.org
2013-06-26 10:55 ` scottbaldwin at gmail dot com
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-26 10:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
` (3 preceding siblings ...)
2013-06-26 10:29 ` redi at gcc dot gnu.org
@ 2013-06-26 10:55 ` scottbaldwin at gmail dot com
2013-06-26 11:32 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: scottbaldwin at gmail dot com @ 2013-06-26 10:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
` (4 preceding siblings ...)
2013-06-26 10:55 ` scottbaldwin at gmail dot com
@ 2013-06-26 11:32 ` redi at gcc dot gnu.org
2013-06-26 12:08 ` scottbaldwin at gmail dot com
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-26 11:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
` (5 preceding siblings ...)
2013-06-26 11:32 ` redi at gcc dot gnu.org
@ 2013-06-26 12:08 ` scottbaldwin at gmail dot com
2013-06-26 14:23 ` scottbaldwin at gmail dot com
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: scottbaldwin at gmail dot com @ 2013-06-26 12:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
` (6 preceding siblings ...)
2013-06-26 12:08 ` scottbaldwin at gmail dot com
@ 2013-06-26 14:23 ` scottbaldwin at gmail dot com
2013-06-26 15:23 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: scottbaldwin at gmail dot com @ 2013-06-26 14:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
` (7 preceding siblings ...)
2013-06-26 14:23 ` scottbaldwin at gmail dot com
@ 2013-06-26 15:23 ` redi at gcc dot gnu.org
2013-06-26 16:04 ` scottbaldwin at gmail dot com
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2013-06-26 15:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
` (8 preceding siblings ...)
2013-06-26 15:23 ` redi at gcc dot gnu.org
@ 2013-06-26 16:04 ` scottbaldwin at gmail dot com
2013-06-26 17:56 ` paolo.carlini at oracle dot com
2021-12-03 3:45 ` pinskia at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: scottbaldwin at gmail dot com @ 2013-06-26 16:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
` (9 preceding siblings ...)
2013-06-26 16:04 ` scottbaldwin at gmail dot com
@ 2013-06-26 17:56 ` paolo.carlini at oracle dot com
2021-12-03 3:45 ` pinskia at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: paolo.carlini at oracle dot com @ 2013-06-26 17:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
2013-05-10 15:53 [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
` (10 preceding siblings ...)
2013-06-26 17:56 ` paolo.carlini at oracle dot com
@ 2021-12-03 3:45 ` pinskia at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-03 3:45 UTC (permalink / raw)
To: gcc-bugs
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");
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
^ permalink raw reply [flat|nested] 13+ messages in thread