[Bug c++/66686] New: Instantiation of dependent template template parameter with non-dependent template rejected

[Bug c++/66686] New: Instantiation of dependent template template parameter with non-dependent template rejected

[ppalka at gcc dot gnu.org]

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

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

            Bug ID: 66686
           Summary: Instantiation of dependent template template parameter
                    with non-dependent template rejected
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

The following code should probably compile:

template <template <int> class>
struct A { };

template <int>
struct Y { };

template <class A, class B, template <template <B> class Z> class C>
struct X
{
    C<Y> a;
};

X<int, int, A> a;


With GCC 5.1 it does not:

foo.cc:10:8: error: type/value mismatch at argument 1 in template parameter
list for ‘template<template<B <anonymous> > class Z> class C’
     C<Y> a;
        ^
foo.cc:10:8: error:   expected a template of type ‘template<B <anonymous> >
class Z’, got ‘template<int <anonymous> > struct Y’

Is this valid code in the first place?
>From gcc-bugs-return-490872-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 26 23:25:34 2015
Return-Path: <gcc-bugs-return-490872-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 90671 invoked by alias); 26 Jun 2015 23:25:33 -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 90602 invoked by uid 48); 26 Jun 2015 23:25:29 -0000
From: "danglin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/66685] [6 Regression] conftest.c:16:1: internal compiler error: in as_a, at is-a.h:192
Date: Fri, 26 Jun 2015 23:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: danglin at gcc dot gnu.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:
Message-ID: <bug-66685-4-e5FhyE6JbR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66685-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66685-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-06/txt/msg03204.txt.bz2
Content-length: 5673

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

--- Comment #3 from John David Anglin <danglin at gcc dot gnu.org> ---
Backtrace:

Breakpoint 1, _Z4as_aIP13rtx_jump_insn8rtx_insnET_PT0_ (p=0x7ae2beb0)
    at ../../gcc/gcc/is-a.h:192
192       gcc_checking_assert (is_a <T> (p));
(gdb) bt
Python Exception <type 'exceptions.ImportError'> Failed to load
/home/gnu/lib/python2.7/lib-dynload/itertools.sl:
#0  _Z4as_aIP13rtx_jump_insn8rtx_insnET_PT0_ (p=0x7ae2beb0)
    at ../../gcc/gcc/is-a.h:192
#1  0x007bab4c in _Z20emit_jump_insn_afterP7rtx_defS0_ (pattern=0x7ae2beb0,
    after=0x7ae2bca8) at ../../gcc/gcc/emit-rtl.c:4749
#2  0x0093a994 in _Z22emit_return_into_blockbP15basic_block_def (
    simple_púlse, bb=0x7aeb8200) at ../../gcc/gcc/function.c:5633
#3  0x0093b2fc in _Z20emit_return_for_exitP8edge_defb (
    exit_fallthru_edge=0x7ae2bcd0, simple_púlse)
    at ../../gcc/gcc/function.c:5779
#4  0x0093bbcc in _Z34thread_prologue_and_epilogue_insnsv ()
    at ../../gcc/gcc/function.c:5961
#5  0x0093d41c in _ZL43rest_of_handle_thread_prologue_and_epiloguev ()
    at ../../gcc/gcc/function.c:6443
#6  0x0093d544 in
_ZN12_GLOBAL__N_133pass_thread_prologue_and_epilogue7executeEP8function
(this=0x40442528) at ../../gcc/gcc/function.c:6481
#7  0x01198304 in _Z16execute_one_passP8opt_pass (pass=0x40442528)
    at ../../gcc/gcc/passes.c:2328
#8  0x01198750 in _ZL19execute_pass_list_1P8opt_pass (pass=0x40442528)
    at ../../gcc/gcc/passes.c:2381
#9  0x011987a4 in _ZL19execute_pass_list_1P8opt_pass (pass=0x40442330)
    at ../../gcc/gcc/passes.c:2382
#10 0x011987a4 in _ZL19execute_pass_list_1P8opt_pass (pass=0x40441688)
    at ../../gcc/gcc/passes.c:2382
---Type <return> to continue, or q <return> to quit---
#11 0x01198874 in _Z17execute_pass_listP8functionP8opt_pass (fn=0x7ae28068,
    pass=0x4043f0d8) at ../../gcc/gcc/passes.c:2392
#12 0x005654f0 in _ZN11cgraph_node6expandEv (this=0x7aeb6000)
    at ../../gcc/gcc/cgraphunit.c:1932
#13 0x00566014 in _ZL20expand_all_functionsv ()
    at ../../gcc/gcc/cgraphunit.c:2068
#14 0x00567454 in _ZN12symbol_table7compileEv (this=0x7ae28000)
    at ../../gcc/gcc/cgraphunit.c:2421
#15 0x00567800 in _ZN12symbol_table25finalize_compilation_unitEv (
    this=0x7ae28000) at ../../gcc/gcc/cgraphunit.c:2508
#16 0x0140c714 in _ZL12compile_filev () at ../../gcc/gcc/toplev.c:575
#17 0x014118b4 in _ZL10do_compilev () at ../../gcc/gcc/toplev.c:2065
#18 0x01411f64 in _ZN6toplev4mainEiPPc (this=0x7eff0688, argc\x13,
    argv=0x7eff051c) at ../../gcc/gcc/toplev.c:2166
#19 0x01dc7988 in main (argc\x13, argv=0x7eff051c) at ../../gcc/gcc/main.c:39
(gdb) p *p
$1 = {<rtx_def> = {code = INSN, mode = VOIDmode, jump = 0, call = 0,
    unchanging = 0, volatil = 0, in_struct = 0, used = 0, frame_related = 0,
    return_val = 0, u2 = {original_regno = 16, insn_uid = 16,
      symbol_ref_flags = 16, var_location_status = 16, num_elem = 16}, u = {
      fld = {{rt_int = 2061679784, rt_uint = 2061679784,
          rt_str = 0x7ae2bca8 "", rt_rtx = 0x7ae2bca8, rt_rtvec = 0x7ae2bca8,
          rt_type = 2061679784, rt_addr_diff_vec_flags = {min_align = 122,
            base_after_vec = 1, min_after_vec = 1, max_after_vec = 1,
            min_after_base = 0, max_after_base = 0, offset_unsigned = 0, 2,
            scale = 188}, rt_cselib = 0x7ae2bca8, rt_tree = 0x7ae2bca8,
          rt_bb = 0x7ae2bca8, rt_mem = 0x7ae2bca8, rt_constant = 0x7ae2bca8,
          rt_cfi = 0x7ae2bca8}}, hwint = {8854847249166024328}, reg = {
        regno = 2061679784, nregs = 122, unused = 14859912,
        attrs = 0x7aeb8200}, block_sym = {fld = {{rt_int = 2061679784,
            rt_uint = 2061679784, rt_str = 0x7ae2bca8 "",
            rt_rtx = 0x7ae2bca8, rt_rtvec = 0x7ae2bca8, rt_type = 2061679784,
            rt_addr_diff_vec_flags = {min_align = 122, base_after_vec = 1,
              min_after_vec = 1, max_after_vec = 1, min_after_base = 0,
              max_after_base = 0, offset_unsigned = 0, 2, scale = 188},
            rt_cselib = 0x7ae2bca8, rt_tree = 0x7ae2bca8, rt_bb = 0x7ae2bca8,
            rt_mem = 0x7ae2bca8, rt_constant = 0x7ae2bca8,
            rt_cfi = 0x7ae2bca8}, {rt_int = 2061680264, rt_uint = 2061680264,
            rt_str = 0x7ae2be88 "", rt_rtx = 0x7ae2be88,
---Type <return> to continue, or q <return> to quit---
            rt_rtvec = 0x7ae2be88, rt_type = 2061680264,
            rt_addr_diff_vec_flags = {min_align = 122, base_after_vec = 1,
              min_after_vec = 1, max_after_vec = 1, min_after_base = 0,
              max_after_base = 0, offset_unsigned = 0, 2, scale = 190},
            rt_cselib = 0x7ae2be88, rt_tree = 0x7ae2be88, rt_bb = 0x7ae2be88,
            rt_mem = 0x7ae2be88, rt_constant = 0x7ae2be88,
            rt_cfi = 0x7ae2be88}}, block = 0x7aeb8200,
        offset = 6614249635839}, rv = {cl = 1, decimal = 1, sign = 1,
        signalling = 1, canonical = 0, uexp = 48413864, sig = {2061680264,
          2062254592, 2062279856, 1539, 4294967295}}, fv = {data = {
          low = 8854847249166024328, high = 8857316030728103088},
        mode = 1539}, hwiv = {elem = {
          8854847249166024328}}}}, <No data fields>}
(gdb) p debug_rtx (p)
(insn 16 10 15 2 (parallel [
            (return)
            (use (reg:SI 2 %r2))
        ])
Breakpoint 1, rtx_insn const* as_a<rtx_insn const*, rtx_def const>(rtx_def
const*) () at ../../gcc/gcc/is-a.h:192
192       gcc_checking_assert (is_a <T> (p));
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(_Z9debug_rtxPK7rtx_def) will be abandoned.
When the function is done executing, GDB will silently stop.

[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The code doesn't look valid to me: Y is not a valid template argument for the
template template parameter C.

Of the compilers I tried GCC, EDG eccp, and IBM XLC++ all reject it (the latter
two with a clear error message confirming the above).  Clang is the only one
that accepts it.

[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected

[ppalka at gcc dot gnu.org]

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

--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #1)
> The code doesn't look valid to me: Y is not a valid template argument for
> the template template parameter C.

But once "struct X" gets instantiated like in the very last line, doesn't it
become a valid template argument?  There, B is set to int, thus the template
parameter C gets the type "template <int> class" which is exactly the type of
the template Y.

[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #2)
> (In reply to Martin Sebor from comment #1)
> > The code doesn't look valid to me: Y is not a valid template argument for
> > the template template parameter C.
> 
> But once "struct X" gets instantiated like in the very last line, doesn't it
> become a valid template argument?  There, B is set to int, thus the template
> parameter C gets the type "template <int> class" which is exactly the type
> of the template Y.

Err, I meant the parameter Z gets the type "template <int> class" which is
exactly the type of the template Y. So it seems that early-rejecting this
template definition is too pessimistic because there exist template arguments
that make the instantiated code valid.

[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
Y takes a non-type template argument which isn't provided and can't be deduced
in the instantiation (i.e., what would the value of N be in Y<N>?)

Modifying the test case a bit to see the type Clang gives a.a shows that it
winds up instantiating an object of type A<Y> even though no such type exists,
indicating it's a Clang bug.

$ cat t.cpp && /build/llvm-3.6.0/bin/clang++ -Wall -Wextra -Wpedantic
t.cpptemplate <template <int> class> struct A { };
template <int> struct Y { };
template <class, class B, template <template <B> class> class C>
struct X { C<Y> a; };
X<int, int, A> a;
template <class T> void foo (T);

int main () { foo (a.a); }
/tmp/t-310f66.o: In function `main':
t.cpp:(.text+0x9): undefined reference to `void foo<A<Y> >(A<Y>)'
clang-3.6: error: linker command failed with exit code 1 (use -v to see
invocation)

[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #4)
> Y takes a non-type template argument which isn't provided and can't be
> deduced in the instantiation (i.e., what would the value of N be in Y<N>?)

Can't you say that for all templates passed as arguments to template template
parameters?

> 
> Modifying the test case a bit to see the type Clang gives a.a shows that it
> winds up instantiating an object of type A<Y> even though no such type
> exists, indicating it's a Clang bug.

I'm not sure I understand when you say that the type A<Y> does not exist.  I
can declare the variable "A<Y> zzz;" just fine, and I can declare a function
that takes an A<Y> as an argument, for example.  A<Y> seems like a standard
template.

> 
> $ cat t.cpp && /build/llvm-3.6.0/bin/clang++ -Wall -Wextra -Wpedantic
> t.cpptemplate <template <int> class> struct A { };
> template <int> struct Y { };
> template <class, class B, template <template <B> class> class C>
> struct X { C<Y> a; };
> X<int, int, A> a;
> template <class T> void foo (T);
> 
> int main () { foo (a.a); }
> /tmp/t-310f66.o: In function `main':
> t.cpp:(.text+0x9): undefined reference to `void foo<A<Y> >(A<Y>)'
> clang-3.6: error: linker command failed with exit code 1 (use -v to see
> invocation)

Sorry for my misunderstanding, I can't quite see the problem here.

[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
The misunderstanding was mine -- I had forgotten that a template template can
be instantiated on a template without providing or deducing the arguments for
the latter.  Please disregard my comment #4.

[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected

[ppalka at gcc dot gnu.org]

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

--- Comment #7 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Author: ppalka
Date: Wed Jul  1 01:07:35 2015
New Revision: 225220

URL: https://gcc.gnu.org/viewcvs?rev=225220&root=gcc&view=rev
Log:
Fix PR c++/66686 (dependent template template substitution)

gcc/cp/ChangeLog:

        PR c++/66686
        * pt.c (coerce_template_template_parm) [PARM_DECL]: Don't
        return 0 if tsubst returns a dependent type.

gcc/testsuite/ChangeLog:

        PR c++/66686
        * g++.dg/template/pr66686.C: New test.


Added:
    trunk/gcc/testsuite/g++.dg/template/pr66686.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/pt.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |6.0

--- Comment #8 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed.