[Bug c++/70141] New: [6.0 regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

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

Bug ID: 70141
   Summary: [6.0 regression] template parameter not deducible in
partial specialization of template inside template
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kholdstare0.0 at gmail dot com
  Target Milestone: ---

Created attachment 37899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37899&action=edit
Preprocessed source

The code below works on gcc 4.8, 5.2, and clang 3.6, but fails to compile on
gcc 6:

template 
struct outer
{
template 
struct inner
{

};
};


template 
struct is_inner_for
{
template 
struct predicate
{
static constexpr bool value = false;
};

template 
struct predicate::template inner>
{
static constexpr bool value = true;
};
};

static_assert(
is_inner_for::template predicate<
outer::inner
>::value,
"Yay!"
);

The commandline:

g++ -std=c++1y -c main.cpp

Here is the error:

main.cpp:22:9: error: template parameters not deducible in partial
specialization:
  struct predicate::template inner> :
std::true_type
 ^~~
main.cpp:22:9: note: 'U'
main.cpp:26:1: error: static assertion failed: Yay!
 static_assert(
 ^

Another thing I noticed is that *I get the error even if I don't use the
"is_inner_for" template*. It looks like some rule that gets applied before
template instantiation - maybe it's too strict...

[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

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

--- Comment #3 from Alexander Kondratskiy  ---
Sorry, I take the "fishy" comment back. I'm not familiar enough with the code.

[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

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

--- Comment #2 from Alexander Kondratskiy  ---
Looking at the diffs in r229628 linked by Jakub, I find the changes to lines
8791 and 8793 in pt.c to be kinda fishy:

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/pt.c?r1=229628&r2=229627&pathrev=229628

[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

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

--- Comment #7 from Alexander Kondratskiy  ---
To add some color, maybe this is related to non-deduced contexts from
14.8.2.5p5 in the standard:

The non-deduced contexts are:
— The nested-name-specifier of a type that was specified using a qualified-id.

So I agree that this should not work for code like the following, where the T
in outer is being deduced:

template 
struct outer
{
template 
struct inner
{

};
};

// doesn't work, because non-deduced context
template 
void foo(typename outer::template inner val)
{ }

void bar()
{
foo(typename outer::template inner{});
}

But in the situation mentioned here, outer is a concrete type, so anything
within it should be deducible. If I get rid of the template parameter on outer,
everything works fine, and the following code compiles:

// no outer template!
struct outer
{
template 
struct inner
{

};
};


struct is_inner_for
{
template 
struct predicate
{
static constexpr bool value = false;
};

template 
struct predicate>
{
static constexpr bool value = true;
};
};

static_assert(
is_inner_for::predicate<
outer::inner
>::value,
"Yay!"
);

This simplified case where outer has no template parameter, in my mind should
not be any different from the original problem - it's just that we had a
template parameter but it was fully specified.

[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

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

--- Comment #8 from Alexander Kondratskiy  ---
I'm sorry Markus, but "clang issues a warning" is not a good enough reason to
mark this invalid. By the same token, the warning in clang could have been
introduced "because gcc issues an error". What happened to independent
implementations?

The example you gave:

template  struct X {};
template  struct X {};

is not the same situation as I posted originally. Here, the nested type foo is
nested inside a type trying to be deduced. I would never expect this to work,
and I agree with clang that it should be an error

My original example is closer to something like:

struct outer{ template  struct foo { }; };
template  struct X {};
template  struct X> {};

The outer type is concrete here, and in my original example.

Please, take another look.

Thank you.

[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

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

--- Comment #10 from Alexander Kondratskiy  ---
My issue is that this code was accepted since gcc 4.8 completely fine. Unless
there is a specific line in the standard that prevents this from working, I
don't understand how appealing to potential failures in other compilers is a
valid argument.

[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

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

--- Comment #12 from Alexander Kondratskiy  ---
Ok, I will ask stackoverflow.

Thanks.

[Bug c++/70141] [6.0 regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

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

--- Comment #14 from Alexander Kondratskiy  ---
Stackoverflow question/answer:

http://stackoverflow.com/questions/35875829/template-parameters-not-deducible-in-partial-specialization-in-gcc6-for-a-case

[Bug c++/70141] [6 Regression] template parameter not deducible in partial specialization of template inside template

[kholdstare0.0 at gmail dot com]

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

--- Comment #20 from Alexander Kondratskiy  ---
Awesome! Thank you Jason!

[Bug c++/69302] New: Using bswap in template function with -ftrack-macro-expansion=0 results in a false compiler error

[kholdstare0.0 at gmail dot com]

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

Bug ID: 69302
   Summary: Using bswap in template function with
-ftrack-macro-expansion=0 results in a false compiler
error
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kholdstare0.0 at gmail dot com
  Target Milestone: ---

Here is the a minimal test.cpp:

#include 

template 
unsigned int foo()
{
return bswap_32(0x0FFF);
}

unsigned int bar()
{
return foo();
}

If the template is removed, everything compiles fine. The compilation command:

g++ -std=c++1y -c -ftrack-macro-expansion=0 -Werror -Wall -Wextra
test.cpp -o test.o

If -ftrack-macro-expansion=0 is removed, everything compiles fine. The error
that results:

main.cpp: In instantiation of 'unsigned int foo() [with BLAH = int]':
main.cpp:11:18:   required from here
main.cpp:6:9: error: address requested for '__x', which is declared
'register' [-Werror=extra]
  return bswap_32(0x0FFF);
 ^
cc1plus: all warnings being treated as errors


This is eerily reminiscent of these bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60955

[Bug c++/69302] Using bswap in template function with -ftrack-macro-expansion=0 results in a false compiler error

[kholdstare0.0 at gmail dot com]

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

--- Comment #2 from Alexander Kondratskiy  ---
Created attachment 37363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37363&action=edit
Preprocessed source that results in error

g++ -std=c++1y -c -Werror -Wall -Wextra preprocessed.cpp -o test.o

[Bug c++/78282] New: [6/7 Regression] Overload resolution failure, in parameter pack expansion, inside a template class

[kholdstare0.0 at gmail dot com]

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

Bug ID: 78282
   Summary: [6/7 Regression] Overload resolution failure, in
parameter pack expansion, inside a template class
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kholdstare0.0 at gmail dot com
  Target Milestone: ---

Created attachment 40009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40009&action=edit
Preprocessed source. Changing "auto" to "Key" on line 21037 fixes the issue.

Hi,

Apologies in advance for such a large example, I couldn't simplify it any more
and trigger the behavior. Here is the minimal source:

#include 
#include 

template 
struct my_tuple : std::tuple
{
private:
using base_t = std::tuple;
public:
using base_t::base_t;
};

using std::get;

#define TRIGGER_BUG 1
#if TRIGGER_BUG  
template 
auto && get(my_tuple&& m)
{
return std::get(std::move(m));
}

#else
template 
Key && get(my_tuple&& m)
{
return std::get(std::move(m));
}  
#endif

namespace detail
{
template 
struct inheritor
{
private:
using storage_type = my_tuple;
storage_type values_;

public:
template 
struct impl : private Ts::impl...
{
public:
impl(inheritor&& unsealed)
: impl(std::move(unsealed),
std::index_sequence_for{})
{ }

template 
impl(inheritor&& outer,
std::index_sequence)
:
Ts::impl(get(std::move(outer.values_)))...
{ }
};

inheritor(storage_type&& values)
: values_(std::move(values))
{ }
};
}

struct null_node
{
struct impl
{
impl(null_node&&) { }
};
};

void test()
{
detail::inheritor
example{std::forward_as_tuple(null_node{})};
struct whatever {};
detail::inheritor::impl
result(std::move(example));
}



I have also attached the preprocessed source. Here is the example on godbolt:
https://godbolt.org/g/4i1v31



Here is the error:

main.cpp: In instantiation of
'detail::inheritor::impl::impl(detail::inheritor&&,
std::index_sequence) [with long unsigned int ...indices = {0ul};
Derived = test()::whatever; Ts = {null_node}; std::index_sequence
= std::integer_sequence]':
main.cpp:46:66:   required from
'detail::inheritor::impl::impl(detail::inheritor&&) [with
Derived = test()::whatever; Ts = {null_node}]'
main.cpp:73:72:   required from here
main.cpp:51:56: error: no matching function for call to
'null_node::impl::impl()'
  : Ts::impl(get(std::move(outer.values_)))...

   
^~~
main.cpp:65:3: note: candidate: null_node::impl::impl(null_node&&)
   impl(null_node&&) { }

   ^~~~
main.cpp:65:3: note:   candidate expects 1 argument, 0 provided
main.cpp:63:9: note: candidate: constexpr null_node::impl::impl(const
null_node::impl&)
  struct impl

 ^~~~
main.cpp:63:9: note:   candidate expects 1 argument, 0 provided
main.cpp:63:9: note: candidate: constexpr
null_node::impl::impl(null_node::impl&&)
main.cpp:63:9: note:   candidate expects 1 argument, 0 provided


It seems to be a weird interaction between "lockstep" parameter pack expansion,
overload resolution and auto type deduction. Things to note:

* I bring std::get into scope
* my_tuple is a light wrapper around std::tuple that allows a more specific
overload to be made for the get function. Note this is the get by type rather
than by index.
* Later in inheritor::impl I am constructing base classes by grabbing them from
my_tuple using the index_sequence trick. I am calling get

[Bug c++/78282] [6/7 Regression] Overload resolution failure, in parameter pack expansion, inside a template class

[kholdstare0.0 at gmail dot com]

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

--- Comment #1 from Alexander Kondratskiy  ---
Created attachment 40010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40010&action=edit
The source before the preprocessing step

[Bug demangler/86664] New: Demangler segfaults

[kholdstare0.0 at gmail dot com]

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

Bug ID: 86664
   Summary: Demangler segfaults
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kholdstare0.0 at gmail dot com
  Target Milestone: ---

Created attachment 44432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44432&action=edit
mangled_symbol

[Bug demangler/86664] Demangler segfaults

[kholdstare0.0 at gmail dot com]

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

--- Comment #1 from Alexander Kondratskiy  ---
Calling c++filt on the symbol (see attachment) results in a segfault.

This may be a similar issue to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82890

[Bug c++/92849] New: call to 'operator()' incorrectly considered ambiguous, when inherited twice with different type parameters

[kholdstare0.0 at gmail dot com]

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

Bug ID: 92849
   Summary: call to 'operator()' incorrectly considered ambiguous,
when inherited twice with different type parameters
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kholdstare0.0 at gmail dot com
  Target Milestone: ---

Minimal test case:

#include 

template 
struct declfunc;

template 
struct declfunc
{
Result operator() (Args...);
};

template 
struct decloverload
: declfunc...
{ };

using overload_set = decloverload;
static_assert(std::is_invocable_v);

Expected result: compilation succeeds. See the godbolt link below, and try it
with clang - clang accepts the code since version 4

Actual result:

/opt/compiler-explorer/gcc-9.2.0/include/c++/9.2.0/type_traits:2336:26: error:
request for member 'operator()' is ambiguous

 2336 |   std::declval<_Fn>()(std::declval<_Args>()...)

  |   ~~~^~

:9:16: note: candidates are: 'Result declfunc::operator()(Args ...) [with Result = void; Args = {int, int}]'

9 | Result operator() (Args...);

  |^~~~

:9:16: note: 'Result declfunc::operator()(Args ...) [with Result = void; Args = {int}]'

:18:24: error: static assertion failed

   18 | static_assert(std::is_invocable_v);

  |   ~^

Compiler returned: 1


Godbolt link with test case as well as '-E' preprocessor output:
https://godbolt.org/z/D9nTBr


I suspect the ambiguity comes from the fact that two call operators are
inherited from the same class (`declfunc` in this case), and the call operators
"look the same" - i.e both are `Result operator() (Args...)`. However since
`declfunc` is instantiated with different template paramaters, the concrete
instances of the call operators are in fact different - Args is `{int}` in one
case and `{int, int}` in another. The compiler mentions this in the error
message. Perhaps the overload check should descend deeper (using the concrete
parameters for `Args...`)

[Bug c++/92849] call to 'operator()' incorrectly considered ambiguous, when inherited twice with different type parameters

[kholdstare0.0 at gmail dot com]

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

--- Comment #1 from Alexander Kondratskiy  ---
Actually, this might be bogus. If I do an explicit `using`, everything works:

#include 

template 
struct declfunc;

template 
struct declfunc
{
Result operator() (Args...);
};

template 
struct decloverload
: declfunc...
{
using declfunc::operator()...;
};

using overload_set = decloverload;
static_assert(std::is_invocable_v);

Godbolt link: https://godbolt.org/z/VJwPV4

[Bug c++/92849] call to 'operator()' incorrectly considered ambiguous, when inherited twice with different type parameters

[kholdstare0.0 at gmail dot com]

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

--- Comment #3 from Alexander Kondratskiy  ---
I think you're right. I think the bug can be closed.

[Bug c++/93147] New: std::tuple of empty structs with member equality operators has ambiguous equality operator

[kholdstare0.0 at gmail dot com]

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

Bug ID: 93147
   Summary: std::tuple of empty structs with member equality
operators has ambiguous equality operator
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kholdstare0.0 at gmail dot com
  Target Milestone: ---

The following code:

#include 

struct A {
bool operator == (A) const { return true; }
};

struct B {
bool operator == (B) const { return true; }
};

using Tuple = std::tuple;

bool example(Tuple a, Tuple b)
{
return a == b;
}

Results in an error:

: In function 'bool example(Tuple, Tuple)':
:18:21: error: request for member 'operator==' is ambiguous
   18 | return a == b;
  | ^
:4:14: note: candidates are: 'bool A::operator==(A) const'
4 | bool operator == (A) const { return true; }
  |  ^~~~
:8:14: note: 'bool B::operator==(B) const'
8 | bool operator == (B) const { return true; }
  |  ^~~~
Compiler returned: 1

Here is the godbolt link, with the preprocessor output on the side: 
https://godbolt.org/z/a4TuB3

Some things to note:
 - This compiles fine with Clang
 - If the structs are non-empty, this also compiles fine
 - If the comparison operators are non-members this also compiles fine
 - The failure is exactly the same going back all the way to gcc 4

My suspicion is that tuple indirectly inherits the types `A` and `B`, and even
though it may be private inheritance, the compiler still finds both comparison
operators and considers them ambiguous. GCC tries to implicitly convert
`std::tuple` into `A` and `B` to call `operator ==`.

[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator

[kholdstare0.0 at gmail dot com]

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

--- Comment #2 from Alexander Kondratskiy  ---
Hi, it compiles fine with both.

See godbolt link for Clang using GCC's libstdc++ : https://godbolt.org/z/iFHemn

[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator

[kholdstare0.0 at gmail dot com]

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

--- Comment #6 from Alexander Kondratskiy  ---
Interesting. Some thoughts I had - 

- If this is the correct behavior given the C++ standard, then that means the
tuple implementation in the library has to be fixed.
- If this is incorrect behavior, then something in the frontend needs to be
fixed regarding member function lookup. What's strange here is that if one of
the structs isn't empty, the problem goes away - it's more subtle than "the
compiler sees the equality operators". Could the empty-base optimization play a
role? Common initial sequence?

[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator

[kholdstare0.0 at gmail dot com]

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

--- Comment #9 from Alexander Kondratskiy  ---
Ah, that explains everything. Thank you for clarifying.