[Bug c++/78308] Hiding of member function templates introduced by using-decl

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
A rejects-valid case:

struct C {
template void f();
};

struct D : C {
template void f();
using C::f;
};

int main(){
D().f<0>();
}

GCC rejects as ambiguous, Clang accepts as it only considers the template
one.

[Bug c++/79549] ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
-std=c++1z, of course.

http://melpon.org/wandbox/permlink/kxNlvdtfvjCW5fNN

[Bug c++/79550] New: ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack

[rs2740 at gmail dot com]

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

Bug ID: 79550
   Summary: ICE in tsubst, at cp/pt.c:13474 with partial
specialization of auto... template parameter pack
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

template 
struct meow;

template 
struct meow { };

template struct meow<1>;

prog.cc: In substitution of 'template struct meow [with auto C =
1]':
prog.cc:7:17:   required from here
prog.cc:7:17: internal compiler error: in tsubst, at cp/pt.c:13474
 template struct meow<1>;
 ^~~
0x5d6a8c tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13474
0x5df37c tsubst_template_args
../../source/gcc/cp/pt.c:11638
0x5d5d5b tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13695
0x5d49f7 get_partial_spec_bindings
../../source/gcc/cp/pt.c:21511
0x5d4cbd most_specialized_partial_spec
../../source/gcc/cp/pt.c:21741
0x5ef83b instantiate_class_template_1
../../source/gcc/cp/pt.c:10183
0x5ef83b instantiate_class_template(tree_node*)
../../source/gcc/cp/pt.c:10751
0x652235 complete_type(tree_node*)
../../source/gcc/cp/typeck.c:133
0x5ead7b do_type_instantiation(tree_node*, tree_node*, int)
../../source/gcc/cp/pt.c:22011
0x64661f cp_parser_explicit_instantiation
../../source/gcc/cp/parser.c:16210
0x627581 cp_parser_declaration
../../source/gcc/cp/parser.c:12467
0x64d05b cp_parser_declaration_seq_opt
../../source/gcc/cp/parser.c:12391
0x64d342 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4366
0x64d342 c_parse_file()
../../source/gcc/cp/parser.c:38425
0x71b2a3 c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/79549] New: ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack

[rs2740 at gmail dot com]

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

Bug ID: 79549
   Summary: ICE in tsubst, at cp/pt.c:13474 with partial
specialization of auto... template parameter pack
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

template 
struct meow;

template 
struct meow { };

template struct meow<1>;

prog.cc: In substitution of 'template struct meow [with auto C =
1]':
prog.cc:7:17:   required from here
prog.cc:7:17: internal compiler error: in tsubst, at cp/pt.c:13474
 template struct meow<1>;
 ^~~
0x5d6a8c tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13474
0x5df37c tsubst_template_args
../../source/gcc/cp/pt.c:11638
0x5d5d5b tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13695
0x5d49f7 get_partial_spec_bindings
../../source/gcc/cp/pt.c:21511
0x5d4cbd most_specialized_partial_spec
../../source/gcc/cp/pt.c:21741
0x5ef83b instantiate_class_template_1
../../source/gcc/cp/pt.c:10183
0x5ef83b instantiate_class_template(tree_node*)
../../source/gcc/cp/pt.c:10751
0x652235 complete_type(tree_node*)
../../source/gcc/cp/typeck.c:133
0x5ead7b do_type_instantiation(tree_node*, tree_node*, int)
../../source/gcc/cp/pt.c:22011
0x64661f cp_parser_explicit_instantiation
../../source/gcc/cp/parser.c:16210
0x627581 cp_parser_declaration
../../source/gcc/cp/parser.c:12467
0x64d05b cp_parser_declaration_seq_opt
../../source/gcc/cp/parser.c:12391
0x64d342 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4366
0x64d342 c_parse_file()
../../source/gcc/cp/parser.c:38425
0x71b2a3 c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/70844] spurious -Wuseless-cast warning with inherited constructors

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
The attached test case doesn't reproduce in 6.2.0, presumably due to the fix
for 70972. The following (slightly modified) test case still produces a
-Wuseless-cast warning on trunk and 6.3.0:

struct base {
base (int const &);
};

struct derived : public base {
using base::base;
};

derived d(0);

What appears to be happening is that the inheriting constructor calls
forward_parm to perfectly forward the arguments, which in turn calls
build_static_cast to construct the equivalent of static_cast(p)
where p is of type const int &, which emits a -Wuseless-cast warning. 

Consistent with this hypothesis, 6.1 emits a warning for the original test case
because it was emitting the equivalent of static_cast(p) where `p`'s type
is `int`; GCC >= 6.2, which has the 70972 fix, emits the equivalent of
static_cast<int&&>(p), which doesn't trigger the warning. GCC < 6 doesn't have
forward_parm and doesn't unconditionally build a static_cast, so doesn't hit
this warning either.

[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified

[rs2740 at gmail dot com]

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

--- Comment #1 from TC  ---
While we are here, the `return {{forward<_Types>(__t)...}};` in the body should
call std::forward qualified.

[Bug libstdc++/79195] New: make_array should not ask for common_type when the type is explicitly specified

[rs2740 at gmail dot com]

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

Bug ID: 79195
   Summary: make_array should not ask for common_type when the
type is explicitly specified
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

This does not compile:

#include 

struct A {};
struct B : A {};
struct C : A {};
auto arr = std::experimental::make_array(B{}, C{});

because make_array's return type computes

conditional_t<is_void_v<_Dest>, common_type_t<_Types...>, _Dest>

which instantiates common_type_t<B,C> and results in a substitution failure.
There shouldn't be a need to instantiate it when the desired element type is
explicitly specified.

[Bug libstdc++/77451] Cannot convert lambda [](auto&&...){} to std::function<void()>

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is not a libstdc++ bug. It's caused by GCC misparsing the ... in
[](auto&&...) {} (i.e., a dup of bug 64095).

Under the mistaken parse (which is equivalent to [](auto&&, ...) {}),
std::function<void()>'s constructor correctly refuses to accept the lambda.

[Bug libstdc++/77528] std::queue default constructor unnecessarily creates temporary of underlying Container

[rs2740 at gmail dot com]

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

--- Comment #10 from TC  ---
C'ing the relevant parts of my email to the lists here for the record:

The new default member initializers use {}, and it's not too hard to find test
cases where {} and value-initialization do different things, including cases
where {} doesn't compile but () does. (So much for "uniform" initialization.)

> Because the default constructor is defined as defaulted it will be
> deleted when the underlying sequence isn't default constructible,

That's not correct. There's no implicit deletion due to the presence of DMIs.
The reason the explicit instantiation works is that constructors explicitly
defaulted at their first declaration are not implicitly defined until ODR-used.

So, unlike the SFINAE-based approach outlined in [comment #1], this patch
causes is_default_constructible> to trigger a
hard error (though the standard's version isn't SFINAE-friendly either).

[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union

[rs2740 at gmail dot com]

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

--- Comment #7 from TC  ---
(In reply to Jakub Jelinek from comment #6)
> Sure, I just wanted to understand why the r211318 change has been done and
> my comment lists why I think that happened.

Ah, my fault for not actually reading the patch. (FWIW, the sentence I quoted
was introduced by the same paper that relaxed the static data member
restrictions (N2544), so I'm not sure how that description makes sense, but
certainly it appears that r211318's author somehow thought so - possibly due to
paragraph numbering changes between C++03 and C++11?)

[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union

[rs2740 at gmail dot com]

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

--- Comment #5 from TC  ---
(In reply to Jakub Jelinek from comment #4)
> Apparently what changed in C++11 is that it allows static
> data members in unions and those clearly can have reference type, so that is
> the reason why the restriction has been removed and nothing added the
> restriction that non-static data members still may not have reference type.

...I quoted the part of the standard that says this is ill-formed in comment
#3?

[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
[class.union]/3 in the current WP (/2 in N3337/N4140) says (among other
things):

If a union contains a non-static data member of reference type the program is
ill-formed.

[Bug c++/78928] New: void(*); accepted in block scope

[rs2740 at gmail dot com]

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

Bug ID: 78928
   Summary: void(*); accepted in block scope
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

From http://stackoverflow.com/q/41326047/2756719.

GCC accepts this plainly invalid code:

void f() {
void(*);
}

It appears that any combination of ptr-operators within the parentheses is
accepted as well.

[Bug c++/78693] New: [6/7 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[rs2740 at gmail dot com]

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

Bug ID: 78693
   Summary: [6/7 Regression] Bogus 'inconsistent deduction for
‘auto’' error when having a dependent initializer and
a nondependent one in the same declaration
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

template
void foo (T t) {
  auto i = t, j = 1;
} 

prog.cc: In function 'void foo(T)':
prog.cc:3:3: error: inconsistent deduction for 'auto': 'auto' and then 'int'
   auto i = t, j = 1;
   ^~~~

Accepted by GCC 5.3, Clang, MSVC (CL 19 on gcc.beta.godbolt.org, whatever that
corresponds to) and ICC 17 (but with a bogus warning). Rejected by 6.1 and 7
(on Wandbox).

[Bug c++/78457] attempt to instantiate unused template

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Doesn't seem to be a bug to me. This is caused by basically the same issue as
the one noted in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69116#c2.

std::endl names a function template, so it's a nondeduced context. Deduction
for `std::ostream& operator<<(std::ostream& os, Y const& )` therefore
succeeds with Ts..., not otherwise deduced, deduced be to an empty pack. Then
during overload resolution the compiler instantiates the definition of `Y<>` to
see if it can be constructed from std::endl; that instantiation triggers a hard
error outside the immediate context as expected.

[Bug c++/78446] New: Ambiguous member lookup for operator() in a function call expression treated as hard error in SFINAE context

[rs2740 at gmail dot com]

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

Bug ID: 78446
   Summary: Ambiguous member lookup for operator() in a function
call expression treated as hard error in SFINAE
context
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Reduced from http://stackoverflow.com/q/40706399/2756719:

struct A { void operator()(); };
struct B { void operator()(); };
struct C : A, B {};

template
decltype(T()()) foo(int);

template int foo(...);

using type = decltype(foo(0));
using type = int;

produces:

prog.cc: In substitution of 'template decltype (T()()) foo(int) [with
T = C]':
prog.cc:10:31:   required from here
prog.cc:6:13: error: request for member 'operator()' is ambiguous
 decltype(T()()) foo(int);
  ~~~^~
prog.cc:2:17: note: candidates are: void B::operator()()
 struct B { void operator()(); };
 ^~~~
prog.cc:1:17: note: void A::operator()()
 struct A { void operator()(); };
 ^~~~
prog.cc: In substitution of 'template decltype (T()()) foo(int) [with
T = C]':
prog.cc:10:31:   required from here
prog.cc:6:13: error: request for member 'operator()' is ambiguous
 decltype(T()()) foo(int);
  ~~~^~
prog.cc:2:17: note: candidates are: void B::operator()()
 struct B { void operator()(); };
 ^~~~
prog.cc:1:17: note: void A::operator()()
 struct A { void operator()(); };
 ^~~~

(Yes, the error messages are repeated, see
http://melpon.org/wandbox/permlink/nZj4Wn9ZgFMMm63l)

Surprisingly enough, using 'decltype(T().operator()())' compiles
(http://melpon.org/wandbox/permlink/2sJ0ZGcA4ZIvqfvn), so it seems that this
doesn't affect all name lookup, only when the overloaded operator() is used by
a function call expression.

[Bug libstdc++/78389] New: list::merge and list::sort are not exception safe

[rs2740 at gmail dot com]

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

Bug ID: 78389
   Summary: list::merge and list::sort are not exception safe
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

If a comparison throws in the middle of the loop,
- list::merge will have spliced some elements over without updating the size of
the lists.
- list::sort will destroy any elements that have been transferred into the
temporary lists.

The former leaves the lists in an invariant-broken state. The latter is
surprising at best.

[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless

[rs2740 at gmail dot com]

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

--- Comment #9 from TC  ---
The ugly fix in Comment #6 should be performant, if, well, ugly.

It may be worth considering holding the nodes via a different type. There's no
real reason why the temporary holders need to be a `list` or have a copy of the
allocator as long as we make sure that everything in there is spliced back into
*this when we exit sort() (by exception or normal return).

Speaking of exceptions, merge() appears to have exception safety problems. I'll
file a separate bug.

[Bug c++/78388] New: Bogus "declaration shadows template parameter" error with parenthesized function-style casts

[rs2740 at gmail dot com]

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

Bug ID: 78388
   Summary: Bogus "declaration shadows template parameter" error
with parenthesized function-style casts
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Reduced from http://stackoverflow.com/q/40637781/2756719: 

template
void f()
{
(int((void(i), 1))) + 0;
}


prog.cc: In function 'void f()':
prog.cc:4:17: error: declaration of 'void i' shadows template parameter
 (int((void(i), 1))) + 0;
 ^
prog.cc:1:10: note: template parameter 'i' declared here
 template
  ^~~

Accepted by Clang and GCC 4.3.6 on Wandbox
(http://melpon.org/wandbox/permlink/BHMa6ZyICjlVpvZi); rejected since 4.4,
apparently.

[Bug libstdc++/78371] New: list::sort doesn't work with non-default-constructible allocators

[rs2740 at gmail dot com]

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

Bug ID: 78371
   Summary: list::sort doesn't work with non-default-constructible
allocators
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

It default constructs the 1+64 temporary lists, which 1) likely does the wrong
thing for stateful allocators and 2) won't compile if the allocator used is not
default constructible.

[Bug c++/78358] [7 Regression] wrong types for std::tuple decomposition

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
In particular, [dcl.type.simple]/4, bullet 1:

> if e is an unparenthesized id-expression naming an lvalue or
> reference introduced from the identifier-list of a decomposition
> declaration, decltype(e) is the referenced type as given in the
> specification of the decomposition declaration ([dcl.decomp]);

And [dcl.decomp]/3 specifies that the referenced type for the i-th identifier
is std::tuple_element<i, E>::type:

> Otherwise, if the expression std::tuple_size::value is a 
> well-formed integral constant expression [...] Given the type
> Ti designated by std::tuple_element<i, E>::type, each vi is 
> a variable of type “reference to Ti” initialized with the
> initializer, where the reference is an lvalue reference if
> the initializer is an lvalue and an rvalue reference otherwise;
> the referenced type is Ti.

[Bug libstdc++/78302] is_move_constructible_v<tuple> should be false

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
Ugh, quasi-dup, I suppose. But if I'm reading the correspondence correctly, the
ABI breaking is only because of triviality, correct?

So if we just want to make is_move_constructible not lie, it should be possible
to do something like adding an empty base at the top level that is either
movable or not depending on __and_...> so that
the tuple(tuple&&) =default; will become deleted for nonmovable elements?

[Bug libstdc++/78302] New: is_move_constructible_v<tuple> should be false

[rs2740 at gmail dot com]

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

Bug ID: 78302
   Summary: is_move_constructible_v<tuple> should be
false
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

#include 
#include 

struct nonmovable
{
nonmovable(nonmovable&&) = delete;
};
static_assert(!std::is_move_constructible_v<std::tuple>); //fires

It's not clear whether this is required by the standard (the standard depicts a
defaulted move constructor, and core language rules say that a defaulted move
constructor is defined as deleted if a subobject cannot be moved), but in any
event this should probably return false as a QoI matter.

[Bug libstdc++/78273] New: The transparent version of {map,set}::count should call _M_count_tr

[rs2740 at gmail dot com]

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

Bug ID: 78273
   Summary: The transparent version of {map,set}::count should
call _M_count_tr
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

They are currently

>  template
>   auto
>   count(const _Kt& __x) const
>   -> decltype(_M_t._M_count_tr(__x))
>   { return _M_t._M_find_tr(__x) == _M_t.end() ? 0 : 1; }

but there is no requirement that at most one key in the container compare
equivalent to the heterogeneous key; the only requirement is that the keys of
the elements in the container be suitably partitioned with respect to the
heterogeneous key. Thus, they should simply return _M_t._M_count_tr(__x);.

[Bug c++/70163] C++ DR 257 constructor forward to virtual base class's constructor in an abstract class required

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
Also bug 53878.

[Bug c++/78163] ref-qualified function type incorrectly accepted in function parameter type

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
(In reply to Martin Liška from comment #1)
> For:
> $ gcc --version
> gcc (SUSE Linux) 6.2.1 20160830 [gcc-6-branch revision 239856]
> 
> $ gcc pr78163.c
> pr78163.c:1:16: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token
>  void f(void () &);
> ^
> pr78163.c:2:19: error: expected ‘;’, ‘,’ or ‘)’ before ‘&’ token
>  void g(void (*)() &);
>^
> pr78163.c:3:14: error: expected ‘)’ before ‘&’ token
>  void h(void (&)() &);
>   ^
> pr78163.c:4:22: error: expected ‘)’ before ‘&’ token
>  void i(void (* const &)() &);
>   ^
> Same for all releases I have, all of declarations are rejected. What's wrong?

This report is for C++, not C?

[Bug c++/78163] New: ref-qualified function type incorrectly accepted in function parameter type

[rs2740 at gmail dot com]

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

Bug ID: 78163
   Summary: ref-qualified function type incorrectly accepted in
function parameter type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

void f(void () &);
void g(void (*)() &);
void h(void (&)() &);
void i(void (* const &)() &);

None of these should be accepted. GCC accepts them all.

[Bug c++/69905] Digit separators break literal operators

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
>   template
>   struct _Number_help
>   {
> using __digit = _Digit<_Base, _Dig>;
> using __valid_digit = typename __digit::__valid;
> using __next = _Number_help<_Base,
> __valid_digit::value ? _Pow / _Base : _Pow,
> _Digs...>;
> using type = __ull_constant<_Pow * __digit::value + __next::type::value>;
> static_assert((type::value / _Pow) == __digit::value,
>   "integer literal does not fit in unsigned long long");
>   };

The issue is that when __valid_digit is false_type (i.e., we have a digit
separator), the static_assert check should not be done. In this case, __next is
computed using the same _Pow, and __digit::value is zero, which means that it
currently fires whenever the next digit is nonzero.

I think the fix is simply

 static_assert(!__valid_digit::value || (type::value / _Pow) ==
__digit::value,
   "integer literal does not fit in unsigned long long");

[Bug c++/67200] Copy elision and implicit move in return performed in cases not allowed by standard

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from TC  ---
Appears to be fixed in GCC 6, presumably by the delayed folding changes:

main.cpp: In function 'A f()':
main.cpp:9:23: error: use of deleted function 'A::A(const A&)'
 return true ? a : a;
   ^
main.cpp:3:5: note: declared here
 A(const A&) = delete;
 ^

[Bug c++/77712] New: int() is incorrectly treated as a null pointer constant in C++11 and later

[rs2740 at gmail dot com]

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

Bug ID: 77712
   Summary: int() is incorrectly treated as a null pointer
constant in C++11 and later
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

GCC accepts

int *p = int();

even though per DR 903, only integer literals with the value zero are null
pointer constants.

This causes http://stackoverflow.com/q/39662995/2756719.

[Bug c++/77616] A variadic polymorphic lambda call fails with zero arguments

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Looks like a dup of 64095 (and 68071).

[Bug libstdc++/77619] New: uninitialized_meow_construct and friends not exception safe

[rs2740 at gmail dot com]

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

Bug ID: 77619
   Summary: uninitialized_meow_construct and friends not exception
safe
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

The new uninitialized_{default,value}_construct(_n)? and
uninitialized_move(_n)? implementations are not exception safe: previously
constructed objects are leaked if a subsequent construction throws.

[Bug c++/77575] New: Bogus error when alias template yielding a reference type used as template template argument

[rs2740 at gmail dot com]

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

Bug ID: 77575
   Summary: Bogus error when alias template yielding a reference
type used as template template argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Reduced from http://stackoverflow.com/q/39460120/2756719:

template class> struct meow {};
template using kitty = T&;

meow u;

results in the following bogus error:

prog.cc: In instantiation of 'struct meow':
prog.cc:4:13:   required from here
prog.cc:1:46: error: type/value mismatch at argument 1 in template parameter
list for 'template<template class > struct meow'
 template class> struct meow {};
  ^
prog.cc:1:46: note:   expected a class template, got 'kitty'
prog.cc:1:46: error: type/value mismatch at argument 1 in template parameter
list for 'meow<  >::meow'
prog.cc:1:46: note:   expected a class template, got 'kitty'

It compiles fine if 'kitty' is instead defined as T or T*.

[Bug libstdc++/77528] std::queue default constructor unnecessarily creates temporary of underlying Container

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
This makes the default constructor implicit, though that's probably how it
should be anyway.

[Bug c++/76262] list-initialization prefers initializer_list over copy constructor

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
(In reply to Jonathan Wakely from comment #2)
> In which case both EDG and Clang get this wrong, as they print "12"

I know that Clang 3.7+ implemented DR1467 without 2137 (in which case "12"
would be the right output) - that led to
https://llvm.org/bugs/show_bug.cgi?id=23812.

I'm not familiar with EDG.

[Bug c++/76262] list-initialization prefers initializer_list over copy constructor

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Post-DR2137, [dcl.init.list]/3.1 no longer applies to non-aggregates. Instead,
[dcl.init.list]/3.6 applies:

> Otherwise, if T is a class type, constructors are considered.
> The applicable constructors are enumerated and the best one
> is chosen through overload resolution ([over.match],
> [over.match.list]).

And [over.match.list] makes clear that initializer-list constructors are
preferred if at all viable:

> When objects of non-aggregate class type T are list-initialized
> such that [dcl.init.list] specifies that overload resolution
> is performed according to the rules in this section, overload
> resolution selects the constructor in two phases:
>  - Initially, the candidate functions are the initializer-list 
>constructors ([dcl.init.list]) of the class T and the argument
>list consists of the initializer list as a single argument.

[over.ics.rank] is irrelevant because the non-initializer-list constructors are
not even candidates.

[Bug c++/56701] [C++11] The *this* pointer fails to bind to rvalue reference to pointer type

[rs2740 at gmail dot com]

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

--- Comment #7 from TC  ---
*** Bug 69208 has been marked as a duplicate of this bug. ***

[Bug c++/69208] &*this should not be const-qualified

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from TC  ---
Fixed as part of 56701.

*** This bug has been marked as a duplicate of bug 56701 ***

[Bug c++/71774] New: Bogus "is protected" error when list-initializing a base class with a defaulted protected constructor and a virtual function

[rs2740 at gmail dot com]

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

Bug ID: 71774
   Summary: Bogus "is protected" error when list-initializing a
base class with a defaulted protected constructor and
a virtual function
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Reduced from http://stackoverflow.com/q/38213809/2756719. Repro:

class Meow
{
  protected:
Meow() =default;
virtual void f() {}
};

class Purr : public Meow
{
  public:
Purr()
  : Meow{}
{}  
};

prog.cc: In constructor 'Purr::Purr()':
prog.cc:12:14: error: 'constexpr Meow::Meow()' is protected within this context
   : Meow{}
  ^
prog.cc:4:5: note: declared protected here
 Meow() =default;
 ^~~~

Possibly related to PR63151, however this example reproduces in GCC 4.7.3 and
4.8.5 (on Wandbox), while that PR is known to work in 4.8.2.

[Bug c++/71332] Passing non-copyable type by reference to variadic generic lambda after a copyable type by value results in a compile-time error

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095.

The ... is (incorrectly) being parsed as C-style varargs, which then triggers
the error.

[Bug c++/71099] New: Misleading diagnostic message with 'virtual' used in out-of-line definitions of class template member functions

[rs2740 at gmail dot com]

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

Bug ID: 71099
   Summary: Misleading diagnostic message with 'virtual' used in
out-of-line definitions of class template member
functions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

GCC correctly diagnoses the problem with this ill-formed code:

struct foo {
virtual void f();
};

virtual void foo::f() {}

+ g++ -std=c++14 -Wall -pedantic main.cpp
main.cpp:5:1: error: 'virtual' outside class declaration
 virtual void foo::f() {}
 ^~~

But if `foo` is a template, the error message is significantly less helpful:

template
struct foo {
virtual void f();
};

template
virtual void foo::f() {}

+ g++ -std=c++14 -Wall -pedantic main.cpp
main.cpp:7:1: error: templates may not be 'virtual'
 virtual void foo::f() {}
 ^~~

Clang correctly diagnoses the problem in both cases ("main.cpp:7:1: error:
'virtual' can only be specified inside the class definition").

[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
It occurred to me that one issue here is whether initialization of the
parameter object (of the constructor) is considered a "value computation [or]
side effect associated with" an initializer-clause. If not, then the current
behavior is correct - the increments are sequenced relative to each other but
not to the initialization of the parameter objects (which reads from 'i').

[Bug c++/70972] [6/7 Regression] Inheriting constructors taking parameters by value should move them, not copy

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
Not exactly that familiar with GCC, but looking at
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/method.c?r1=233719=233718=233719

  tree type = TREE_TYPE (parm);
  if (DECL_PACK_P (parm))
type = PACK_EXPANSION_PATTERN (type);
  exp = build_static_cast (type, exp, tf_warning_or_error);

This seems to do the equivalent of `static_cast(p)` (which is a
copy) rather than the desired `static_cast(p)`. Consistent with
this hypothesis, with -fno-elide-constructors, a copy constructor call is
emitted *in addition to* a move constructor call
(http://coliru.stacked-crooked.com/a/5dd154da9c26472f), rather than instead of
one.

[Bug c++/70972] [6/7 Regression] Inheriting constructors taking parameters by value should move them, not copy

[rs2740 at gmail dot com]

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

--- Comment #1 from TC  ---
Originally from http://stackoverflow.com/q/37064993/2756719

[Bug c++/70972] New: [6/7 Regression] Inheriting constructors taking parameters by value should move them, not copy

[rs2740 at gmail dot com]

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

Bug ID: 70972
   Summary: [6/7 Regression] Inheriting constructors taking
parameters by value should move them, not copy
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Keywords: rejects-valid, wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

The following code, accepted by GCC 5.3, fails to compile in GCC 6.1 and 7:

struct moveonly {
moveonly(moveonly&&) = default;
moveonly() = default;
};

struct A {
A(moveonly) {}
};
struct B : A {
using A::A;
};

B b(moveonly{});

with a bogus error:

+ g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp
main.cpp: In constructor 'B::B(moveonly)':
main.cpp:10:14: error: use of deleted function 'constexpr
moveonly::moveonly(const moveonly&)'
 using A::A;
  ^
main.cpp:1:8: note: 'constexpr moveonly::moveonly(const moveonly&)' is
implicitly declared as deleted because 'moveonly' declares a move constructor
or move assignment operator
 struct moveonly {
^~~~
main.cpp: At global scope:
main.cpp:13:15: note: synthesized method 'B::B(moveonly)' first required here 
 B b(moveonly{});

Per N4140 [class.inhctor]/8, an implicitly defined inheriting constructor
should cast a passed-by-value parameter to an rvalue before forwarding it to
the base class constructor:

> Each expression in the expression-list [of the mem-initializer for the base 
> class] is of the form static_cast<T&&>(p), where p is the name of the 
> corresponding constructor parameter and T is the declared type of p.

(The code above remains valid under the new inheriting constructor semantics in
P0136R1.)

However, GCC 6.1 looks for a copy constructor instead, and would call them
instead of move:

struct abort_on_copy{
abort_on_copy(abort_on_copy&&) = default;
abort_on_copy(const abort_on_copy&) { __builtin_abort(); }
abort_on_copy() = default;
};

struct A {
A(abort_on_copy) {}
};
struct B : A {
using A::A;
};

int main() {
B b(abort_on_copy{}); // aborts
}

[Bug c++/70942] [6/7 Regression] [c++14] Incorrect deduction of generic lambda `auto&&` parameter

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
This only appears to affect captureless generic lambdas with a deduced return
type.

It might have something to do with the conversion function template to function
pointer - I'm guessing that it was somehow instantiated for the wrong template
argument during overload resolution, which result in the lambda's body being
instantiated with the wrong argument too (to deduce the return type), which
triggers the error.

[Bug c++/70943] New: 'conflicting declaration' error with repeated typedefs in function templates

[rs2740 at gmail dot com]

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

Bug ID: 70943
   Summary: 'conflicting declaration' error with repeated typedefs
in function templates
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

template
void foo(T t) {
using meow = T;
using meow = int;
}

template void foo(int);

Accepted by clang, rejected by GCC:

main.cpp: In function 'void foo(T)':
main.cpp:4:21: error: conflicting declaration 'using meow = '
 using meow = int;
 ^
main.cpp:3:19: note: previous declaration as 'using meow = T'
 using meow = T;

[Bug c++/70942] [c++14] Incorrect deduction of generic lambda `auto&&` parameter

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Reduced:

int main()
{
int x = 0;
[](auto&& xv){
static_cast<decltype(xv)>(xv) = 1;
}(x);
}

OK on GCC 5. Fails with a bogus error on 6 and 7:
main.cpp: In instantiation of 'main()::<lambda(auto:1&&)> [with auto:1 = int]':
main.cpp:5:17:   required by substitution of 'template
main()::<lambda(auto:1&&)>::operator decltype
(((main()::<lambda(auto:1&&)>)0u).operator()(static_cast<auto:1&&>()))
(*)(auto:1&&)() const [with auto:1 = int]'
main.cpp:7:8:   required from here
main.cpp:6:39: error: using xvalue (rvalue reference) as lvalue
 static_cast<decltype(xv)>(xv) = 1;
 ~~^~~

[Bug libstdc++/70101] Allocator-extended priority_queue constructors are badly broken

[rs2740 at gmail dot com]

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

--- Comment #1 from TC  ---
Test case for everything except the first:

#include 
#include 
#include 
#include 
#include 

struct Cmp : std::less {
explicit Cmp(int) {};
};

Cmp comp(1);
std::allocator alloc;
std::vector vec;

using PQ = std::priority_queue;

PQ pq2(comp, alloc);
PQ pq3(comp, vec, alloc);
PQ pq4(comp, std::move(vec), alloc);
PQ pq5(pq2, alloc);
PQ pq6(std::move(pq2), alloc);

[Bug c++/70796] New: [DR 1030] Initialization order with braced-init-lists still broken

[rs2740 at gmail dot com]

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

Bug ID: 70796
   Summary: [DR 1030] Initialization order with braced-init-lists
still broken
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

The following modified test case (replacing postfix ++ with prefix and
adjusting the expected values accordingly) from PR61382 still aborts on Wandbox
(http://melpon.org/wandbox/permlink/IQojTl16DtIxCd2M) and also gives a bogus
-Wsequence-point warning:

struct A
{
  int i,j;
  A(int i,int j):i(i),j(j){}
};

int main()
{
  int i = 0;
  A a{++i, ++i};
  if (a.i != 1 || a.j != 2)
__builtin_abort();
}

[Bug libstdc++/70766] New: stream iterators, shared_lock, and atomic should all use addressof and not

[rs2740 at gmail dot com]

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

Bug ID: 70766
   Summary: stream iterators, shared_lock, and atomic should
all use addressof and not &
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

1) istream_iterator and ostream_iterator's constructors and istream_iterator's
operator-> should use __addressof (this is LWG issue 2576).

2) shared_lock's constructors should use addressof (LWG issue 2577).
unique_lock's constructors already do that.

3) The primary atomic<_Tp> template uses & in many places where it should be
using addressof.

[Bug libstdc++/70472] is_copy_constructible<vector<unique_ptr>>::value is true

[rs2740 at gmail dot com]

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

--- Comment #7 from TC  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to TC from comment #5)
> > In any event, it would be wrong to SFINAE on
> > std::is_copy_constructible. The requirement is CopyInsertable,
> > not CopyConstructible. The allocator's construct() can mutilate the
> > constructor arguments to its heart's content before passing them on, and I
> > don't see a way to check this.
> 
>  has this:
> 
>   // true if _Alloc::value_type is CopyInsertable into containers using
> _Alloc
>   template
> struct __is_copy_insertable
> : __is_copy_insertable_impl<_Alloc>::type
> { };
> 
> But using it requires that std::vector::~vector() is defined as defaulted,
> which would not be a simple change.
> 
> We used to use that for the unordered containers until r204790.

That also requires the allocator's `construct` be SFINAE-friendly. Most aren't.

[Bug c++/70667] SFINAE error disambiguating using alignas

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
The error here (in the definition of `A`) certainly looks like it's outside the
immediate context...?

[Bug c++/60799] access checking within injected friend functions does not happen in the context of the enclosing class

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
(In reply to Casey Carter from comment #3)
> >  I'm inclined to the second interpretation, which would imply the behavior 
> > described in this bug report is what the standard intends.
> 
> This is me stumbling over my words attempting to say "I think this is NOT a
> bug."

I don't think that reading makes much sense. Among member-declarations that do
not declare a member are static_assert-declarations and unnamed bit-field
declarations, so that reading disallows

class A {
constexpr static bool value = true;
friend class B;
};

class B {
static_assert(B::value, "");
};

And disallows D in the below example but not E:

class C {
constexpr static int value = 4;
friend class D;
friend class E;
};

class D {
int : C::value;
};

class E {
int i : C::value;
};

[Bug libstdc++/70472] is_copy_constructible<vector<unique_ptr>>::value is true

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #5 from TC  ---
In any event, it would be wrong to SFINAE on
std::is_copy_constructible. The requirement is CopyInsertable, not
CopyConstructible. The allocator's construct() can mutilate the constructor
arguments to its heart's content before passing them on, and I don't see a way
to check this.

[Bug c++/70642] New: Invalid alias template instantiation not rejected if previously used in SFINAE context

[rs2740 at gmail dot com]

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

Bug ID: 70642
   Summary: Invalid alias template instantiation not rejected if
previously used in SFINAE context
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Reduced from http://stackoverflow.com/q/36578055/2756719.

The following ill-formed code is incorrectly accepted by GCC:

template<bool, class> struct enable_if {};
template struct enable_if<true, T> { using type = T; };

template 
struct foo
{
 template 
 using meow = typename enable_if<sizeof(X) == 0, R>::type;

 template// 1
 meow bar () = delete;

 int bar ()
 {
meow i;  // 2
return 0; // 3
 }
};

int j = foo().bar();

Attempting to use i (by changing line #3 to 'return i;') causes an ICE:

prog.cc: In instantiation of 'int foo::bar() [with X = long int]':
prog.cc:20:25:   required from here
prog.cc:16:16: internal compiler error: in tsubst_copy, at cp/pt.c:14043
 return i;
^
0x6019dd tsubst_copy
/home/heads/gcc/gcc-source/gcc/cp/pt.c:14041
0x602021 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16993
0x5fdcd8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15802
0x5fda06 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15114
0x5fd454 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15104
0x5fdb73 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15290
0x5fc36f instantiate_decl(tree_node*, int, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:22014
0x618c8b instantiate_pending_templates(int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:22131
0x636eed c_parse_final_cleanups()
/home/heads/gcc/gcc-source/gcc/cp/decl2.c:4599
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.

The problem appears to only arise if the types in Lines #1 and #2 match (i.e.,
when the alias template has been instantiated in a SFINAE context already); if
either (but not both) is changed to, e.g., void, or if the first bar() overload
is removed, then the error is correctly diagnosed.

[Bug c++/70587] 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|6.0 |5.3.0
 Resolution|--- |FIXED

--- Comment #3 from TC  ---
Bah, wrong version field. This should be against 5 (because I was using
Coliru), but I neglected to test 6.

[Bug c++/70587] New: 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier

[rs2740 at gmail dot com]

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

Bug ID: 70587
   Summary: 0e1_p+0 should not be parsed as a single pp-number in
C++14 and earlier
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

p/P followed by +/- is not part of the pp-number production in C++ before
C++17, but GCC includes them anyway. This results in the following code being
erroneously rejected in C++11/14 mode:

long double operator""_p(long double) { return {}; }
auto x = 0e1_p+0; // should be parsed as 0e1_p + 0
  // but parsed as a single pp-number instead and rejected

[Bug c++/70585] New: Bogus 'ambiguous template instantiation' error with partial specializations involving a pack expansion

[rs2740 at gmail dot com]

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

Bug ID: 70585
   Summary: Bogus 'ambiguous template instantiation' error with
partial specializations involving a pack expansion
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:

template class meow;
template struct purr;

template
struct purr<T, meow...> {};

template
struct purr<int, meow...> {};

template struct purr<int, meow>;

gcc HEAD 6.0.0 20160407 (experimental) on Wandbox prints:

prog.cc:10:17: error: ambiguous template instantiation for 'struct purr<int,
meow >'
 template struct purr<int, meow>;
 ^~~~
prog.cc:6:8: note: candidates are: template struct
purr<T, meow...> [with T = int; Ts = {int}]
 struct purr<T, meow...> {};
^~~~
prog.cc:8:8: note: template struct purr<int,
meow...> [with Ts = {int}]
 struct purr<int, meow...> {};
^~
prog.cc:10:17: error: explicit instantiation of 'struct purr<int, meow >'
before definition of template
 template struct purr<int, meow>;
 ^~~~

Clang compiles this code.

[Bug c++/70383] New: Bogus error when attempting to capture a reference to function by copy

[rs2740 at gmail dot com]

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

Bug ID: 70383
   Summary: Bogus error when attempting to capture a reference to
function by copy
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:

void meow() {
void purr();
void ()() = purr;
[f]{};
}

Per [expr.prim.lambda]/15, capturing a reference to a function by copy should
result in an unnamed data member that is also a reference to a function. GCC
instead complains:

prog.cc: In function 'void meow()':
prog.cc:4:6: error: field 'meow()::<lambda()>::' invalidly declared
function type
 [f]{};
  ^

[Bug c++/53637] NRVO not applied where there are two different variables involved

[rs2740 at gmail dot com]

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

--- Comment #8 from TC  ---
The standard specifies when copy elision is allowed
(http://eel.is/c++draft/class.copy#31). "return param ? a : b;" is not one of
them. "param ? a : b" is hardly "the name of a non-volatile automatic
object..."

[Bug c++/53637] NRVO not applied where there are two different variables involved

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #6 from TC  ---
(In reply to Thomas Braun from comment #4)
> (I'm no gcc dev at all)
> 
> In general gcc is much better in doing NRVO/URVO than other compilers
> according to my analysis [1]. So maybe the competitors need to get better
> first ;)
> 
> [1]: http://www.byte-physics.de/cpp-copy-elision

The three cases (L, P, R) where GCC is "better" is actually non-conforming.

[Bug libstdc++/70101] New: Allocator-extended priority_queue constructors are badly broken

[rs2740 at gmail dot com]

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

Bug ID: 70101
   Summary: Allocator-extended priority_queue constructors are
badly broken
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

None of them is implemented correctly, and several won't compile if actually
used.

  template>
explicit
priority_queue(const _Alloc& __a)
: c(__a) { }

should be ": c(__a), comp()" (the standard says that it value-initializes
comp).

  template>
priority_queue(const _Compare& __x, const _Alloc& __a)
: c(__x, __a) { }

should be ": c(__a), comp(__x)".

  template>
priority_queue(const _Compare& __x, const _Sequence& __c,
   const _Alloc& __a)
: c(__x, __c, __a) { }

should be ": c(__c, __a), comp(__x)", and per LWG 2537 should also call
std::make_heap.

  template>
priority_queue(const _Compare& __x, _Sequence&& __c, const _Alloc& __a)
: c(__x, std::move(__c), __a) { }

should be ": c(std::move(__c), __a), comp(__x)", and per LWG 2537 should also
call std::make_heap.

  template>
priority_queue(const priority_queue& __q, const _Alloc& __a)
: c(__q.c, __a) { }

should be ": c(__q.c, __a), comp(__q.comp)".

  template>
priority_queue(priority_queue&& __q, const _Alloc& __a)
: c(std::move(__q.c), __a) { }

should be ": c(std::move(__q.c), __a), comp(std::move(__q.comp))".

[Bug c++/67013] Compilation error for well-formed program with empty declaration in the global namespace

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #11 from TC  ---
This was not allowed in C++03, as there was no such thing as an
empty-declaration. The production for simple-declaration would seem to accept
';', but it's banned by [dcl.dcl]/3 and /7.

This was changed by http://wg21.link/cwg569.

[Bug c++/69778] New: Bogus "qualifiers cannot be applied" error with redundant (but legal) 'typename'

[rs2740 at gmail dot com]

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

Bug ID: 69778
   Summary: Bogus "qualifiers cannot be applied" error with
redundant (but legal) 'typename'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Modified repro from http://stackoverflow.com/q/35352168/2756719:

struct A {
typedef int& reference;
};

void f(const A::reference);  // OK
void g(const typename A::reference); // error: 'const' qualifiers cannot be 
 // applied to 'A::reference {aka int&}'

[Bug c++/69774] Corrupted 'this' passed through lambda.

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
You have a dangling reference - the lambda in Thread's constructor captures
`task` by reference, and in this case `task` is bound to the temporary object
created by the lambda expression in A's constructor, which is immediately
destroyed at the semicolon.

[Bug libstdc++/68515] std::result_of<F(X)> doesn't work when F is abstract (with pure virtual functions)

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
FWIW, I don't see a bug here. The note in [temp.deduct]/8 explicitly calls out
"Attempting to create a function type in which a parameter type or the return
type is an abstract class type" as a cause for deduction failure. What one
plans to do with the type is irrelevant; deduction fails as soon as you attempt
to form one.

In any event, the only reason this is an issue for the original example is
because it uses result_of incorrectly. The actual call is 'f(x[i])' - i.e., it
is calling a const F lvalue with the result of vector's const operator[], which
returns 'typename vector::const_reference' (which is const T& except for
vector). The correct result_of invocation is therefore 'typename
std::result_of::const_reference)>::type'
(which should probably be then decayed since the example creates a vector of
it).

[Bug c++/69139] [4.9/5/6 Regression] deduction failure with trailing return type in function template argument

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
Another test case, slightly modified from the original in the linked SO
question:

struct X {
  auto get(int) const & -> int { return {}; }
  auto get(int) && -> long { return {}; }
};

template  auto f(auto (X::*)(int) const & -> R) -> R {}

using I = decltype(f(::get));
using I = int;

The fix needs to also handle the cv-qualifier-seq and ref-qualifier in the
function type, if any.

[Bug c++/69515] New: partial specialization of variable templates is broken

[rs2740 at gmail dot com]

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

Bug ID: 69515
   Summary: partial specialization of variable templates is broken
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Reduced from http://stackoverflow.com/q/35027853/2756719:

struct A { A(int = 0); };

template class meow;

template A foo;
template A foo<meow> = 1;

auto&& a = foo<meow>;
auto&& b = foo<meow<int, int>>;

Output:

/tmp/ccpeDea7.s: Assembler messages:
/tmp/ccpeDea7.s:24: Error: symbol `foo' is already defined

Additionally, attempting to explicitly instantiate 'foo' using the partial
specialization causes a bogus error:

template A foo;  // OK
template A foo<meow>; // Error

prog.cc:11:12: error: 'foo' is not a static data member of a class template
 template A foo<meow>;
^~

[Bug libstdc++/69478] New: [4.9/5/6 Regression] std::copy/std::move broken with trivial move-only types

[rs2740 at gmail dot com]

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

Bug ID: 69478
   Summary: [4.9/5/6 Regression] std::copy/std::move broken with
trivial move-only types
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Reduced from http://stackoverflow.com/q/35002402/2756719, repro:

#include 
#include 

class A {
public:
A() = default;
A(A const & a) = delete;
A& operator =(A const & a) = delete;
A(A && a) = default;
A& operator =(A && a) = default;
};

int main() {
A a[1], b[1];
std::copy(std::make_move_iterator(a), std::make_move_iterator(a + 1), b);
std::move(a, a+1, b);
}

Compiles on 4.8.2 on Wandbox; fails with 4.9+ with a bogus static assert:

In file included from
/usr/local/gcc-head/include/c++/6.0.0/bits/char_traits.h:39:0,
 from /usr/local/gcc-head/include/c++/6.0.0/ios:40,
 from /usr/local/gcc-head/include/c++/6.0.0/ostream:38,
 from /usr/local/gcc-head/include/c++/6.0.0/iterator:64,
 from prog.cc:1:
/usr/local/gcc-head/include/c++/6.0.0/bits/stl_algobase.h: In instantiation of
'static _Tp* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*) [with
_Tp = A; bool _IsMove = true]':
/usr/local/gcc-head/include/c++/6.0.0/bits/stl_algobase.h:384:44:   required
from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = true; _II =
A*; _OI = A*]'
/usr/local/gcc-head/include/c++/6.0.0/bits/stl_algobase.h:420:45:   required
from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = true; _II =
A*; _OI = A*]'
/usr/local/gcc-head/include/c++/6.0.0/bits/stl_algobase.h:453:8:   required
from '_OI std::copy(_II, _II, _OI) [with _II = std::move_iterator<A*>; _OI =
A*]'
prog.cc:15:76:   required from here
/usr/local/gcc-head/include/c++/6.0.0/bits/stl_algobase.h:361:4: error: static
assertion failed: type is not assignable
static_assert( is_copy_assignable<_Tp>::value,
^

[Bug libstdc++/69478] [4.9/5/6 Regression] std::copy/std::move broken with trivial move-only types

[rs2740 at gmail dot com]

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

--- Comment #1 from TC  ---
It seems that the static_assert should check _IsMove and use either
is_copy_assignable<_Tp> or is_move_assignable<_Tp> depending on its value.

[Bug c++/69449] New: Some invalid fold expressions incorrectly accepted

[rs2740 at gmail dot com]

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

Bug ID: 69449
   Summary: Some invalid fold expressions incorrectly accepted
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:

struct A { A(int = 0); A operator+(A) const; };
struct B { B(int = 0); operator int() const; };

template
void f(){
(A() + A() + ... + A(Is)); // compiles!
}

template
void g(){
(B() + B() + ... + B(Is)); // error: binary expression in operand 
   //of fold-expression
}

Both function templates should be rejected, because neither A() + A() nor B() +
B() is a cast-expression, but only the one calling the built-in operator + is.

[Bug c++/69448] New: Abbreviated function templates with deduced return type still broken

[rs2740 at gmail dot com]

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

Bug ID: 69448
   Summary: Abbreviated function templates with deduced return
type still broken
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

PR64969 fixed cases where an abbreviated function template returns 'auto' or
'decltype(auto)' (or have a trailing return type), but returning `auto*` and
`auto&` etc. is still broken:

long x;
auto& f(auto) { return x; }
auto* g(auto) { return  }
auto r = f(1);
auto p = g(1);

prog.cc: In instantiation of 'auto& f(auto:1) [with auto:1 = int]':
prog.cc:4:13:   required from here
prog.cc:2:24: error: invalid initialization of non-const reference of type
'int&' from an rvalue of type 'int'
 auto& f(auto) { return x; }
^

prog.cc: In instantiation of 'auto* g(auto:2) [with auto:2 = int]':
prog.cc:5:13:   required from here
prog.cc:3:25: error: cannot convert 'long int*' to 'int*' in return
 auto* g(auto) { return  }
 ^

[Bug c++/69436] Method returning "auto&" fails to resolve "*this" (-std=c++17)

[rs2740 at gmail dot com]

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

--- Comment #4 from TC  ---
Although this still breaks on trunk GCC on Wandbox:

long x;
auto& f(auto) { return x; }
auto* g(auto) { return  }
auto r = f(1);
auto p = g(1);

prog.cc: In instantiation of 'auto& f(auto:1) [with auto:1 = int]':
prog.cc:4:13:   required from here
prog.cc:2:24: error: invalid initialization of non-const reference of type
'int&' from an rvalue of type 'int'
 auto& f(auto) { return x; }
^

prog.cc: In instantiation of 'auto* g(auto:2) [with auto:2 = int]':
prog.cc:5:13:   required from here
prog.cc:3:25: error: cannot convert 'long int*' to 'int*' in return
 auto* g(auto) { return  }
 ^

I guess PR64969's fix only handled functions returning 'auto', and not
something more complicated.

[Bug c++/69436] Method returning "auto&" fails to resolve "*this" (-std=c++17)

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
Another manifestation of PR64969 and friends?

[Bug libstdc++/69287] libstdc++-v3/include/debug/functions.h:297: bad comparison ?

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This code is correct as written, as explained by the comment right above:

  // Verify that the < operator for elements in the sequence is a
  // StrictWeakOrdering by checking that it is irreflexive.

[Bug c++/69215] New: Improve diagnostic for 'for(i : v)'

[rs2740 at gmail dot com]

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

Bug ID: 69215
   Summary: Improve diagnostic for  'for(i : v)'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Something like

#include 

int main(){
std::vector v;
for(i : v) {}
}

produces a storm of not-very-enlightening errors on trunk:

prog.cc: In function 'int main()':
prog.cc:5:11: error: found ':' in nested-name-specifier, expected '::'
 for(i : v) {}
   ^

prog.cc:5:9: error: 'i' has not been declared
 for(i : v) {}
 ^

prog.cc:6:1: error: expected primary-expression before '}' token
 }
 ^

prog.cc:6:1: error: expected ';' before '}' token
prog.cc:6:1: error: expected primary-expression before '}' token
prog.cc:6:1: error: expected ')' before '}' token
prog.cc:6:1: error: expected primary-expression before '}' token

in contrast to clang's:

prog.cc:5:9: error: range-based for loop requires type for loop variable
for(i : v) {}
^

Perhaps the code implementing N3994, removed by r229632, can be repurposed
instead to produce a better error message?

[Bug c++/69208] New: &*this should not be const-qualified

[rs2740 at gmail dot com]

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

Bug ID: 69208
   Summary: &*this should not be const-qualified
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:

struct A
{
  void f(){ A*&& a = &*this; }
};

results in:

prog.cc: In member function 'void A::f()':
prog.cc:3:24: error: binding 'A* const' to reference of type 'A*&&' discards
qualifiers
   void f(){ A*&& a = &*this; }
^~~~

PR56701 fixed the case where 'this' instead of '&*this' is used, but the above
test case still breaks.

[Bug libstdc++/69116] [4.9/5/6 Regression] compile error when including valarray

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
I don't think this has anything to do with `end`. Consider the following code:

#include 

template struct foo {
T f();
void g(T);
};
template void operator<<(const T&, const foo&) {}

struct x : public std::ostream
{
  virtual void flush() = 0;
};

void bar(x& os)
{
  os << std::endl;
}

I don't have access to 4.8.0, but this compiles on 4.7.3 and fails on 4.8.1+.
(In the  case, std::operator<<(const T&, const valarray&) is
picked up by ADL.)

Deduction for this operator<< function template succeeds: `T` is deduced to be
`x` from the left operand; the right operand is a non-deduced context because
the supplied argument names a function template. Then substitution takes place,
and we instantiate valarray (whose definition is needed to decide if it can
be constructed from std::endl), which triggers a hard error because you can't
return or take an abstract type by value. This is not diagnosed in GCC 4.7.3,
likely due to PR51184.

[Bug c++/69139] New: [4.9/5/6 Regression] deduction failure with trailing return type in function template argument

[rs2740 at gmail dot com]

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

Bug ID: 69139
   Summary: [4.9/5/6 Regression] deduction failure with trailing
return type in function template argument
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Test case (modified from http://stackoverflow.com/q/31229359/2756719):

auto get(int) -> int { return {}; }
template  int f(auto (*)(int) -> R) { return {}; }
int i = f(get);

Compiles on 4.8.2, fails on 4.9 and later:

prog.cc:3:14: error: no matching function for call to 'f(int (&)(int))'
 int i = f(get);
  ^

prog.cc:2:24: note: candidate: template int f(auto:1
(*)(int))
 template  int f(auto (*)(int) -> R) { return {}; }
^

prog.cc:2:24: note:   template argument deduction/substitution failed:
prog.cc:3:14: note:   couldn't deduce template parameter 'R'
 int i = f(get);
  ^

It seems as if the 'auto' indicating the trailing return type is being treated
as introducing another template parameter, as if in abbreviated function
templates, and then the trailing return type is just ignored.

[Bug c++/69131] New: [4.9/5/6 Regression] default constructor of union incorrectly deleted

[rs2740 at gmail dot com]

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

Bug ID: 69131
   Summary: [4.9/5/6 Regression] default constructor of union
incorrectly deleted
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

From http://stackoverflow.com/q/34581372/2756719, repro:

struct X
{
~X() {}
};

union U
{
X x;
~U() {}
};

U u;

The default constructor of `X` is trivial. Nothing in [class.ctor]/4 applies,
so U's default constructor shouldn't be deleted. However, GCC 4.9 and later
rejects this code with:

prog.cc:12:3: error: use of deleted function 'U::U()'
 U u;
   ^

prog.cc:6:7: note: 'U::U()' is implicitly deleted because the default
definition would be ill-formed:
 union U
   ^

GCC 4.6-4.8 and all versions of Clang I tested accept this code.

[Bug libstdc++/69114] New: A couple allocator-related helpers should use __addressof

[rs2740 at gmail dot com]

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

Bug ID: 69114
   Summary: A couple allocator-related helpers should use
__addressof
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

__use_alloc in  and __outermost in 
take the address of an allocator with &. They should use __addressof instead.

(__outermost doesn't seem to actually require the actual address at all; the
result is only used for disambiguating overload resolution.)

[Bug c++/68071] Generic lambda variadic argument pack cannot be empty

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
This looks like a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095

[Bug c++/69103] New: Misleading diagnostic for invalid constexpr initialization

[rs2740 at gmail dot com]

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

Bug ID: 69103
   Summary: Misleading diagnostic for invalid constexpr
initialization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Consider:

static int i;
static int* temp = 
static constexpr int *& = static_cast<int*&&>(temp) + 1;

This correctly doesn't compile, but produces the misleading error message

prog.cc:3:57: error: modification of '_ZGRL1r0' is not a constant-expression
 static constexpr int *& = static_cast<int*&&>(temp) + 1;
 ^

We aren't modifying anything in the initializer.

In contrast, Clang produces:

prog.cc:3:25: error: constexpr variable 'r' must be initialized by a constant
expression
static constexpr int *& = static_cast<int*&&>(temp) + 1;
^   ~
prog.cc:3:29: note: read of non-constexpr variable 'temp' is not allowed in a
constant expression
static constexpr int *& = static_cast<int*&&>(temp) + 1;
^
prog.cc:2:13: note: declared here
static int* temp = 

[Bug libstdc++/69106] New: std::promise should tolerate overloaded

[rs2740 at gmail dot com]

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

Bug ID: 69106
   Summary: std::promise should tolerate overloaded &
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Test case:

#include 

struct foo {
void operator&() const = delete;
};

int main() {
std::promise p;
p.set_value(foo());
}

results in:

In file included from prog.cc:1:0:
/usr/local/gcc-head/include/c++/6.0.0/future: In instantiation of 'static
std::__future_base::_State_baseV2::_Setter<_Res, _Arg&&>
std::__future_base::_State_baseV2::__setter(std::promise<_Res>*, _Arg&&) [with
_Res = foo; _Arg = foo]':
/usr/local/gcc-head/include/c++/6.0.0/future:1081:50:   required from 'void
std::promise<_Res>::set_value(_Res&&) [with _Res = foo]'
prog.cc:9:22:   required from here
/usr/local/gcc-head/include/c++/6.0.0/future:510:49: error: use of deleted
function 'void foo::operator&() const'
   return _Setter<_Res, _Arg&&>{ __prom, &__arg };
 ^~

prog.cc:4:10: note: declared here
 void operator&() const = delete;
  ^~~~

[Bug libstdc++/69105] New: front_/back_/insert_iterator should use addressof

[rs2740 at gmail dot com]

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

Bug ID: 69105
   Summary: front_/back_/insert_iterator should use addressof
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Test case:

#include 
#include 

struct test : std::deque {
void operator&() const = delete;
};

int main() {
test t;
std::back_insert_iterator b(t);
std::front_insert_iterator f(t);
std::insert_iterator i(t, t.begin());
}

http://wg21.link/LWG2324 requires std::addressof to be used.

[Bug libstdc++/69092] New: basic_string constructor and throwing iterators

[rs2740 at gmail dot com]

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

Bug ID: 69092
   Summary: basic_string constructor and throwing iterators
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

basic_string(ForwardIt, ForwardIt) eventually calls _S_copy_chars(), which is
marked _GLIBCXX_NOEXCEPT, so an exception thrown from an iterator operation
inside _S_copy_chars() results in a call to std::terminate().

For instance:

#include
#include

struct hate_T_iterator : std::iterator<std::forward_iterator_tag, char> {
explicit hate_T_iterator(char* p) : p(p) {}
char* p;
hate_T_iterator& operator++() { ++p; return *this; }
hate_T_iterator operator++(int) { auto r = *this; ++*this; return r; }
char& operator*() const { if(*p == 'T') throw 1; else return *p; }
char* operator->() const { return p; }
bool operator== (hate_T_iterator other) const { return p == other.p;}
bool operator!= (hate_T_iterator other) const { return p != other.p;}
};

int main(){
char test_str[4] = "ATA";
try {
std::string s(hate_T_iterator{test_str}, hate_T_iterator{test_str+3});
}
catch(...) {
}
}

[Bug c++/69016] In C++14 standard, function with auto as return and arguments returns result with the datatype of first argument only

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
Dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969 and friends?

[Bug c++/69023] bitset whose name is used in constant-expression rejected

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
[basic.scope.class]/1, item 2:

A name N used in a class S shall refer to the same declaration in its context
and when re-evaluated in the completed scope of S. No diagnostic is required
for a violation of this rule.

[Bug c++/67669] Wrong works fwrite or fread or both

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #5 from TC  ---
I can reproduce this with both MSYS2/MinGW64 GCC 5.2.0 and Clang 3.7+libc++, so
not a GCC problem. This also reproduces with Visual Studio 2015.

This is likely caused by a bug in Microsoft's C runtime library.

Presumably Borland C++ Builder has its own C runtime.

[Bug libstdc++/68995] Including both and can cause ADL problems in std::function SFINAE

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I think TR1 is considered as non-supported now.
> 
> Pretty much.

The documentation may need updating if that's the case.

> people trying to mix C++11 and TR1 are weird and should be shunned.

I don't disagree :)

[Bug c++/58109] alignas() fails to compile with constant expression

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #5 from TC  ---
The test cases in this bug appear to work with GCC 4.9.0 or later; however a
somewhat similar example from http://stackoverflow.com/q/34376921/2756719 fails
to compile:

template 
struct Base {
  constexpr static int Align_ = alignof(T);
};

template 
struct Derived : Base {
  using Base_ = Base;
  using Base_::Align_;
  alignas(Align_) char buf[1];
};

[Bug libstdc++/68995] New: Including both and can cause ADL problems in std::function SFINAE

[rs2740 at gmail dot com]

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

Bug ID: 68995
   Summary: Including both  and  can
cause ADL problems in std::function SFINAE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro adapted from http://stackoverflow.com/q/34334735/2756719:

#include 
#include 
#include  

std::tr1::shared_ptr test() { return {}; }

std::function<std::tr1::shared_ptr()> func = test;

This compiles iff the #include  is commented out. When both
 and  are included, however, we get an error,
apparently because

template
using _Invoke = decltype(__callable_functor(std::declval<_Functor&>())
 (std::declval<_ArgTypes>()...) );

in std::function does an unqualified call to __callable_functor, and picks up
both std::__callable_functor in  from normal unqualified lookup,
and std::tr1::__callable_functor in  from ADL, resulting in an
ambiguity, which in turn causes substitution failure in the converting
constructor template.

[Bug c++/68957] New: Wrong overload resolution for unscoped enums with fixed underlying type

[rs2740 at gmail dot com]

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

Bug ID: 68957
   Summary: Wrong overload resolution for unscoped enums with
fixed underlying type
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:

#include 

enum E : char { e };

void f(char) { puts(__PRETTY_FUNCTION__); }
void f(int) { puts(__PRETTY_FUNCTION__); }

int main() {
f(e);  // ambiguous
}

Before DR1601 (http://wg21.link/CWG1601), this should be ambiguous. After
DR1601, this should print 'void f(char)' because promotion to the underlying
type is preferred over promotion to the promoted underlying type.

GCC does neither and prints 'void f(int)' instead.

[Bug libstdc++/68869] New: map::insert(P&&) broken in some cases

[rs2740 at gmail dot com]

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

Bug ID: 68869
   Summary: map::insert(P&&) broken in some cases
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

According to the standard ([map.modifiers]), 

template  pair<iterator, bool> insert(P&& x);

is equivalent to return emplace(std::forward(x)), provided that
std::is_constructible<value_type, P&&>::value is true.

The following code does not compile when insert() is used, but does compile
when emplace() is used. The same issue also affects multimap.

#include 
#include 
#include 
#include 

struct S {
operator std::pair() const && { return {}; }
};

static_assert(std::is_constructible<std::pair, S&&>::value,
"!!");
static_assert(std::is_constructible<std::pair,
int>, std::pair<std::unique_ptr, int>&&>::value, "!!");

int main(){
std::map<std::unique_ptr, int> m;
std::map<int, int> m2;
m.insert(std::make_pair(std::make_unique(), 1));  // Error
m2.insert(S());  // Error

m.emplace(std::make_pair(std::make_unique(), 1)); // OK
m2.emplace(S()); // OK
}

[Bug libstdc++/68869] map::insert(P&&) broken in some cases

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
This was http://cplusplus.github.io/LWG/lwg-defects.html#2005. 

I don't think the S example breaks any rule in the pre-LWG2005 version, either.
That version requires that "P shall be convertible to value type", and

static_assert(std::is_convertible::value, "!!");

doesn't fire.

[Bug c++/68288] botched floating-point UDL

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This behavior looks correct to me. (Clang behaves identically.)

0e1_e+0 is a valid pp-number, so per max munch it must be parsed that way, as a
single preprocessing token; it then fails to convert to a valid literal token.

0e1_a+0 isn't a valid pp-number (the only thing in the pp-number production
that can precede + in C++ is e/E), so it's parsed as three tokens, 0e1_a, +,
and 0. Ditto for 0e1_e*0.

However, GCC is treating 0e1_p+0 as a single pp-number, and rejecting

long double operator""_p(long double) { return {}; }
auto x = 0e1_p+0;

which isn't correct in C++.

[Bug c++/68071] Generic lambda variadic argument pack cannot be empty

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
auto l = [](auto&& x, auto&&...y) { return x; };
l(1);

compiles in GCC. This looks like a parsing issue - the ... is being parsed as
C-style varargs instead of a pack.

[Bug c++/68177] New: Lambda capture doesn't work correctly when lambda is used in a pack expansion

[rs2740 at gmail dot com]

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

Bug ID: 68177
   Summary: Lambda capture doesn't work correctly when lambda is
used in a pack expansion
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:

void swallow(...) {}
template
void foo() {
  int t = 0;
  swallow(
   ([]{return 0;}(), Is)...
  );
}


int main()
{
  foo<1, 2>();
  return 0;
}

gcc HEAD 6.0.0 20151031 (experimental) reports:

prog.cc: In instantiation of 'void foo() [with int ...Is = 1, 2]':
prog.cc:13:13:   required from here
prog.cc:6:5: error: member 'foo() [with int ...Is = 1, 2]::<lambda()>::' is uninitialized reference
([]{return 0;}(), Is)...
 ^

It appears that only the capture in the first element in the pack expansion
gets initialized correctly.

Clang accepts this code, as does MSVC.

[Bug libstdc++/68139] New: rethrow_if_nested should tolerate overloaded unary operator

[rs2740 at gmail dot com]

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

Bug ID: 68139
   Summary: rethrow_if_nested should tolerate overloaded unary
operator&
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Test case:

#include 
struct C {
virtual ~C(){}
void operator&() const = delete;
};

int main() { std::rethrow_if_nested(C()); }

This results in:

In file included from /usr/local/gcc-head/include/c++/6.0.0/exception:169:0,
 from prog.cc:1:
/usr/local/gcc-head/include/c++/6.0.0/bits/nested_exception.h: In instantiation
of 'static void std::_Rethrow_if_nested_impl<_Tp, 
>::_S_rethrow(const _Tp&) [with _Tp = C; bool  = true]':
/usr/local/gcc-head/include/c++/6.0.0/bits/nested_exception.h:161:47:  
required from 'void std::rethrow_if_nested(const _Ex&) [with _Ex = C]'
prog.cc:7:40:   required from here
/usr/local/gcc-head/include/c++/6.0.0/bits/nested_exception.h:145:56: error:
use of deleted function 'void C::operator&() const'
  if (auto __tp = dynamic_cast(&__t))
^
prog.cc:4:10: note: declared here
 void operator&() const = delete;

I don't see anything in the standard saying that the type passed to
rethrow_if_nested cannot overload unary &, so the implementation should use
std::addressof or equivalent.