[Bug c++/57239] New: GCC cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
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
struct Foo {};
template
struct is_instantiation_of__nontypes
{
template class TT, typename T>
struct check : std::false_type {};
template class TT, Ts... Args>
struct check> : std::true_type {};
};
int main() {
using FooInstantiation = Foo;
std::cout << ((is_instantiation_of__nontypes::check::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
template > class TT, class T>
template template > class TT, class T> struct
gcc_bug_demo_3::is_instantiation_of__nontypes::check’
sandbox_cpp11.cpp:122:88: error: expected a template of type
‘template template > class TT’, got
‘template 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> : std::true_type {};
^
sandbox_cpp11.cpp:116:30: error: template argument 2 is invalid
struct check> : 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
template > class TT, class T>
template template > class TT, class T> struct
gcc_bug_demo_3::is_instantiation_of__nontypes::check’
std::cout << ((is_instantiation_of__nontypes::check::value) ? "yes" : "no") << endl;
^
sandbox_cpp11.cpp:122:88: error: expected a template of type
‘template template > class TT’, got
‘template 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'
[Bug c++/57240] New: decltype() on a template non-type parameter causes "internal compiler error"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57240
Bug ID: 57240
Summary: decltype() on a template non-type parameter causes
"internal compiler error"
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scottbaldwin at gmail dot com
GCC 4.8.x (4.8.0 and 4.8.1-20130427) have an "internal compiler error" when
decltype()'s argument is a template non-type parameter.
The following code is a simple demo of the bug. The demo also includes a
"workaround" to show the issue does not occur when the non-type parameter is
"converted" to an equivalent value (i.e., something that is no longer a
template non-type parameter).
---
template
struct FuncPointerType { // wrap a function pointer type (for demo
purposes)
typedef _fptype type;
};
void some_func() {} // some function w/ signature of void(void)
template< void(*func_ptr)(void) >
void bug_demo()
{
// crashes w/ "internal compiler error"
using FPT = FuncPointerType< decltype(func_ptr) >; // crashes compiler
in 4.8.0/4.8.1 (works in 4.7.2)
// workaround (if uncommented): pass decltype() an equivalent value
that is not a template nontype parameter
//auto fp = func_ptr;
//using FPT = FuncPointerType< decltype(fp) >; // works fine now
// next line should output "[1]" (if correct)
std::cout << "[" << std::is_same::value << "]" << std::endl;
}
int main() {
bug_demo();
return 0;
}
[gcc 4.8.1]
make[1]: compiling [sandbox_cpp11.cpp] (gcc 4.8.1 20130427)
g++ -c sandbox_cpp11.cpp -o dbg-mt/sandbox_cpp11.o -pthread -Wall -Werror
-Wno-unused -Wno-unused-variable -std=c++11 -rdynamic -g3 -O0 -m64 -D__64BIT__
-I./dbg-mt -I. -I.
sandbox_cpp11.cpp: In instantiation of ‘void gcc_bug_demo_1::bug_demo()
[with void (* func_ptr)() = gcc_bug_demo_1::some_func]’:
sandbox_cpp11.cpp:71:23: required from here
sandbox_cpp11.cpp:57:52: internal compiler error: in finish_decltype_type,
at cp/semantics.c:5373
using FPT = FuncPointerType< decltype(func_ptr) >; // crashes compiler
in 4.8.0/4.8.1 (works in 4.7.2)
^
0x5a3680 finish_decltype_type(tree_node*, bool, int)
../../srcdir/gcc/cp/semantics.c:5373
0x5157d0 tsubst(tree_node*, tree_node*, int, tree_node*)
../../srcdir/gcc/cp/pt.c:11812
0x51b352 tsubst_template_args
../../srcdir/gcc/cp/pt.c:9630
0x522010 tsubst_aggr_type
../../srcdir/gcc/cp/pt.c:9827
0x515d45 tsubst(tree_node*, tree_node*, int, tree_node*)
../../srcdir/gcc/cp/pt.c:11190
0x523d36 tsubst_decl
../../srcdir/gcc/cp/pt.c:10648
0x516087 tsubst(tree_node*, tree_node*, int, tree_node*)
../../srcdir/gcc/cp/pt.c:1
0x518eea tsubst_expr
../../srcdir/gcc/cp/pt.c:12894
0x518cdc tsubst_expr
../../srcdir/gcc/cp/pt.c:12843
0x518f80 tsubst_expr
../../srcdir/gcc/cp/pt.c:13033
0x518433 instantiate_decl(tree_node*, int, bool)
../../srcdir/gcc/cp/pt.c:18910
0x52cb8b instantiate_pending_templates(int)
../../srcdir/gcc/cp/pt.c:19009
0x5445bf cp_write_global_declarations()
../../srcdir/gcc/cp/decl2.c:4043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [dbg-mt/sandbox_cpp11.o] Error 1
make: *** [objs] Error 2
[gcc 4.8.0]
make[1]: compiling [sandbox_cpp11.cpp] (gcc 4.8.0)
g++ -c sandbox_cpp11.cpp -o dbg-mt/sandbox_cpp11.o -pthread -Wall -Werror
-Wno-unused -Wno-unused-variable -std=c++11 -rdynamic -g3 -O0 -m64 -D__64BIT__
-I./dbg-mt -I. -I.
sandbox_cpp11.cpp: In instantiation of ‘void gcc_bug_demo_1::bug_demo()
[with void (* func_ptr)() = gcc_bug_demo_1::some_func]’:
sandbox_cpp11.cpp:71:23: required from here
sandbox_cpp11.cpp:57:52: internal compiler error: in finish_decltype_type,
at cp/semantics.c:5365
using FPT = FuncPointerType< decltype(func_ptr) >; // crashes compiler
in 4.8.0/4.8.1 (works in 4.7.2)
^
0x5a2ac0 finish_decltype_type(tree_node*, bool, int)
../../srcdir/gcc/cp/semantics.c:5365
0x51e50c tsubst(tree_node*, tree_node*, int, tree_node*)
../../srcdir/gcc/cp/pt.c:11772
0x5217c2 tsubst_template_args
../../srcdir/gcc/cp/pt.c:9607
0x524000 tsubst_aggr_type
[Bug c++/57241] New: GCC still issues -Wmultichar warnings despite a #pragma diagnostic ignored -Wmultichar directive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57241
Bug ID: 57241
Summary: GCC still issues -Wmultichar warnings despite a
#pragma diagnostic ignored -Wmultichar directive
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scottbaldwin at gmail dot com
In GCC 4.7.2 and 4.8.x, the #pragma ignore directive for -Wmultichar has no
effect. The code below demonstrates a -Wmultichar which is still emitted as a
warning despite the #pragma directive to ignore it. Specifying -Wno-multichar
on the command line works fine, so this is just an issue with trying to
suppress it with a #pragma directive (which I need for finer-grained control).
Note: I didn't test the other diagnostic options to see if there are others
besides -Wmultichar that have the same issue, so you might want to do a full
check on all diagnostic options.
Here's the demo code and unsuppressed compiler warnings:
int main() {
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wmultichar"
typedef boost::mpl::string<'0123', '4567', '89ab', 'cdef'> hex_chars; //
-Wmultichar (gcc still issues warnings, despite #pragma ignore directive)
#pragma GCC diagnostic pop
return 0;
}
warnings in gcc 4.7.2:
sandbox_cpp11.cpp:148:29: warning: multi-character character constant
[-Wmultichar]
sandbox_cpp11.cpp:148:37: warning: multi-character character constant
[-Wmultichar]
sandbox_cpp11.cpp:148:45: warning: multi-character character constant
[-Wmultichar]
sandbox_cpp11.cpp:148:53: warning: multi-character character constant
[-Wmultichar]
warnings in gcc 4.8.x:
sandbox_cpp11.cpp:148:29: warning: multi-character character constant
[-Wmultichar]
typedef boost::mpl::string<'0123', '4567', '89ab', 'cdef'> hex_chars;
^
sandbox_cpp11.cpp:148:37: warning: multi-character character constant
[-Wmultichar]
typedef boost::mpl::string<'0123', '4567', '89ab', 'cdef'> hex_chars;
^
sandbox_cpp11.cpp:148:45: warning: multi-character character constant
[-Wmultichar]
typedef boost::mpl::string<'0123', '4567', '89ab', 'cdef'> hex_chars;
^
sandbox_cpp11.cpp:148:53: warning: multi-character character constant
[-Wmultichar]
typedef boost::mpl::string<'0123', '4567', '89ab', 'cdef'> hex_chars;
[Bug pch/57242] New: gcc ignores precompiled headers unless the .gch and TU's are compiled with certain combinations of -g flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57242 Bug ID: 57242 Summary: gcc ignores precompiled headers unless the .gch and TU's are compiled with certain combinations of -g flag Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: scottbaldwin at gmail dot com In GCC 4.7.2 and 4.8.x, precompiled headers (PCH) .gch file is ignored unless a certain combination of '-gN' debug options are used. To demonstrate, consider the following g++ commands to generate PCH (my_pch.hpp.gch) and compile a TU (foo.cpp) using the PCH cache: g++ $(PCH_DEBUG_FLAGS) -std=c++11 -m64 -Wall -Werror -Wno-unused -Wno-unused-variable -I./dbg-mt -I. -I. ./dbg-mt/my_pch.hpp -o ./dbg-mt/my_pch.hpp.gch g++ $(CPP_DEBUG_FLAGS) -std=c++11 -m64 -Wall -Werror -Wno-unused -Wno-unused-variable -I./dbg-mt -I. -I. -c foo.cpp -o dbg-mt/foo.o The only difference between these two commands (other than the input file) is the $(PCH_DEBUG_FLAGS) vs $(CPP_DEBUG_FLAGS). However, in order for the precompiled headers (.gch file) to be used when compiling the source files (e.g., foo.cpp), both of the following conditions must be met: 1) The '-g' or '-g2' or '-g3' flag must be used when building the precompiled headers (.gch file). 2) The '-g3' flag (and no less) must be used when compiling each TU (.c/.cpp file), and In other words: PCH_DEBUG_FLAGS = -g3 or -g2 or -g (specifying no 'g' at all will cause PCH cache to be ignored) CPP_DEBUG_FLAGS = -g3 (specifying -g2 or -g or no 'g' at all will cause PCH cache to be ignored) I put a #warning in the my_pch.hpp file to be sure of when PCH were being ignored (though, the long delay also made it quite obvious). This bug is present in all 3 versions of gcc I tested (4.7.2, 4.8.0, 4.8.1_20130427).
[Bug pch/57242] gcc ignores precompiled headers unless the .gch and TU's are compiled with certain combinations of -g flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57242 --- Comment #3 from etherice --- (In reply to Andrew Pinski from comment #1) > This is by design as -g changes the information produced by the front-end > and maybe even predefines too. I think you may have read the report too quickly :) When building the .gch file, and then subsequently building the translation unit that uses the .gch ... even if you do not specify a -gN at all, or specify the SAME -gN (unless both are -g3), the .gch will be ignored when compiling the TU. For example, using -g2 for both (.gch and TU) will cause pch to be ignored. Or using no -g flag at all for both (.gch and TU) will cause pch to be ignored. You MUST specify a -g flag (either -g -g2 or -g3) when building the .gch, and you must specify EXACTLY -g3 when building the TU. I hope that clarifies it.
[Bug c++/57241] GCC still issues -Wmultichar warnings despite a #pragma diagnostic ignored -Wmultichar directive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57241 --- Comment #3 from etherice --- (In reply to Andrew Pinski from comment #2) > (In reply to Paolo Carlini from comment #1) > > In general, it's safe to say that #pragma diagnostic ignored is very buggy > > (in C++ at least), we have got many long standing PRs. > > Well the whole token ahead of time for C++ front-end causes this and another > issue with respect of #pragma's. Fixing it would certainly help those of us using -Wall and -Werror and wanting fine-grained control of when to allow specific cases (such as -Wmultichar when defining a boost::mpl::string, or making a signed/unsigned comparison, etc.).
[Bug c++/57240] decltype() on a template non-type parameter causes "internal compiler error"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57240 --- Comment #2 from etherice --- (In reply to Paolo Carlini from comment #1) > Already fixed. > > *** This bug has been marked as a duplicate of bug 57092 *** Yep that's it, fixed 3 days after my April 27 version of the 4.8 branch. Looks like the bug was specific to function-pointer non-type parameters.
[Bug pch/57242] precompiled headers ignored unless the .gch and TU's are compiled with certain combinations of -g flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57242
--- Comment #4 from etherice ---
(In reply to Andrew Pinski from comment #1)
> This is by design as -g changes the information produced by the front-end
> and maybe even predefines too.
I created a simpler test to demonstrate the bug. Two files:
--
pch.hpp
--
#ifndef __PCH_HPP__
#define __PCH_HPP__
#pragma message "[ not using pre-compiled headers ]"
#include
#endif
--
test.cpp
--
#include
int main() {
std::cout << "hello world" << std::endl;
return 0;
}
--
If you run commands [1] and [2] below, you will notice that pch is ignored.
[1] g++ -I. pch.hpp -o pch.hpp.gch
[2] g++ -I. -c test.cpp -o test.o
[3] g++ -I. -c test.cpp -o test.o -include pch.hpp
However, if you add -g3 to commands [1] and [2], then pch will be used in
command [2]. More specifically, you must use a combination of the -g flags I
described in the report for pch to be utilized.
One more note: Using the -include option (even though it's unnecessary in this
case) makes the -g3 flags no longer needed. To confirm this, execute commands
[1] and [3] and observe that pch is no longer ignored, even without the -g3
flags.
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #2 from etherice ---
(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 and ) 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.
[Bug pch/57242] precompiled headers ignored unless the .gch and TU's are compiled with certain combinations of -g flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57242
--- Comment #6 from etherice ---
(In reply to Richard Biener from comment #5)
> (In reply to etherice from comment #4)
> > (In reply to Andrew Pinski from comment #1)
> > > This is by design as -g changes the information produced by the front-end
> > > and maybe even predefines too.
> >
> > I created a simpler test to demonstrate the bug. Two files:
> >
> > --
> > pch.hpp
> > --
> > #ifndef __PCH_HPP__
> > #define __PCH_HPP__
> > #pragma message "[ not using pre-compiled headers ]"
> > #include
> > #endif
> >
> > --
> > test.cpp
> > --
> > #include
> > int main() {
> > std::cout << "hello world" << std::endl;
> > return 0;
> > }
> >
> > --
> >
> > If you run commands [1] and [2] below, you will notice that pch is ignored.
> >
> > [1] g++ -I. pch.hpp -o pch.hpp.gch
> > [2] g++ -I. -c test.cpp -o test.o
> > [3] g++ -I. -c test.cpp -o test.o -include pch.hpp
>
> How? I see
>
> rguenther@murzim:/tmp> g++-4.7 -I. pch.hpp -o pch.hpp.gch
> pch.hpp:3:19: note: #pragma message: [ not using pre-compiled headers ]
> rguenther@murzim:/tmp> g++-4.7 -I. -c test.cpp -o test.o
> rguenther@murzim:/tmp> g++-4.7 -I. -c test.cpp -o test.o -include pch.hpp
>
> rguenther@murzim:/tmp> g++-4.8 -I. pch.hpp -o pch.hpp.gch
> pch.hpp:3:19: note: #pragma message: [ not using pre-compiled headers ]
>#pragma message "[ not using pre-compiled headers ]"
>^
> rguenther@murzim:/tmp> g++-4.8 -I. -c test.cpp -o test.o
> rguenther@murzim:/tmp> g++-4.8 -I. -c test.cpp -o test.o -include pch.hpp
>
> the issue is probably that there are pre-installed precompiled headers
> for libstdc++ which use certain flags. Maybe in your case this confuses
> things? (disclaimer: I always install gcc built with
> --disable-libstdcxx-pch)
> Try removing them.
I did a clean rebuild of 4.8 with --disable-libstdcxx-pch and results were the
same, pch ignored, but... after triple-checking some things I realized ccache
was still being used.
Once ccache was disabled, the issue went away and gcc-pch worked as expected.
So this appears to be a bug with ccache, not gcc.
Fortunately, the workaround is simple (using '-g3' or the '-include' option).
[Bug c++/32204] friend from global namespace in template class ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204
etherice changed:
What|Removed |Added
CC||scottbaldwin at gmail dot
||com
--- Comment #7 from etherice 2012-10-27
08:11:45 UTC ---
As Jonathan explains in comment #5, gcc is right to reject this code and MSVC
is wrong to accept it. You will have to add a forward declaration of the
class/function in order to declare it as a friend in the namespaced class. For
example:
// on gcc 4.7.0 (linux), these forward declarations are required for the friend
declarations in ns::NamespacedClass
class GlobalClass;
void globalFunction();
namespace ns {
struct NamespacedClass {
friend ::GlobalClass; // same result whether '::' or 'class' is part of
declaration
friend void ::globalFunction();
private:
NamespacedClass() {}
};
}
struct GlobalClass {
GlobalClass() { ns::NamespacedClass foo; }
};
void globalFunction() {
ns::NamespacedClass foo;
}
[Bug c++/32204] friend from global namespace in template class ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204
--- Comment #8 from etherice 2012-10-27
08:52:10 UTC ---
In MSVC's defense, the standard is vague (or insufficient) in this regard for
'friend class' declarations. It says:
"If a friend declaration appears in a local class (9.8) and the name specified
is an unqualified name, a prior declaration is looked up without considering
scopes that are outside the innermost enclosing non-class scope."
...
"For a friend class declaration, if there is no prior declaration, the class
that is specified belongs to the innermost enclosing non-class scope, but if it
is subsequently referenced, its name is not found by name lookup until a
matching declaration is provided in the innermost enclosing nonclass scope."
The standard *should* specify whether the 'friend class declaration' case
applies to qualified names. For example:
namespace ns {
class NSClass {
friend class ::SomeGlobalClass;
};
}
Since ::SomeGlobalClass is qualified (via scope resolution operator) it
explicitly belongs to the global namespace. However, the standard says that it
shall "belong to the innermost enclosing non-class scope", which is a
contradiction (or nonsense). This is why the standard *should* specify a case
for qualified vs unqualified names in friend class declarations (as it does for
normal friend declarations).
The assumption MSVC makes not only seems reasonable, but is also convenient for
developers as it allows *hidden* forward declarations of names in outer
namespaces. This avoids having to make an unnecessary explicit forward
declaration.
Perhaps GCC should "interpret" this part of the standard similarly.
[Bug c++/32204] friend from global namespace in template class ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32204 --- Comment #10 from etherice 2012-10-27 13:39:05 UTC --- (In reply to comment #9) Jonathan- You're right on all counts. Thanks for clarifying (and apologies for getting a bit off-topic).
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #3 from etherice --- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #6 from etherice ---
(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
and . Here it is w/ those includes:
#include
#include
template
struct Foo {};
template
struct is_instantiation_of__nontypes
{
template class TT, typename T>
struct check : std::false_type {};
template class TT, Ts... Args>
struct check> : std::true_type {};
};
int main() {
using FooInstantiation = Foo;
std::cout << ((is_instantiation_of__nontypes::check::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> : std::true_type {};
^
error: template argument 2 is invalid
struct check> : std::true_type {};
^
error: type/value mismatch at argument 1 in template parameter list for
‘template template > class
TT, class T> template template > class TT,
class T> struct is_instantiation_of__nontypes::check’
std::cout << ((is_instantiation_of__nontypes::check::value) ? "yes" : "no") << std::endl;
error: expected a template of type ‘template template > class TT’, got ‘template 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 struct value_holder {
template apply { }; // Values is a non-type template parameter
pack
// and a pack expansion
};
[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #8 from etherice --- (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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #10 from etherice --- (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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239 --- Comment #12 from etherice --- (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.
