[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||ville.voutilainen at gmail dot 
com

--- Comment #4 from Ville Voutilainen  ---
Another test:

struct T 
{ 
int x = 0; 
bool y = 0; 
constexpr T() {}
};

int main()
{
constexpr T t = (T{} = T{});
}

prog.cc: In function 'int main()':
prog.cc:10:31: error: accessing value of '' through a 'char [5]'
glvalue in a constant expression
 constexpr T t = (T{} = T{});
   ^

That looks rather bad.

[Bug c++/77927] unary right fold fails to compile

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||jason at redhat dot com,
   ||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #4 from Ville Voutilainen  ---
Clang accepts the code.

[Bug c++/77890] class template type deduction fails for lambda functions

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-07
 CC||jason at redhat dot com,
   ||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

[Bug pch/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-05
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #4 from Ville Voutilainen  ---
This bug could use some lovin', projects like
https://github.com/Eelis/geordi
are also running into the problem.

[Bug c++/77852] New: ICE when deducing class template arguments for pair or tuple

[ville.voutilainen at gmail dot com]

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

Bug ID: 77852
   Summary: ICE when deducing class template arguments for pair or
tuple
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

First test:

#include 

int main()
{
std::pair x{42, 666};
}

Second test:

#include 

int main()
{
std::tuple y{1,2,3};
}

ICE for the first:

c-a-d.cpp: In function ‘int main()’:
c-a-d.cpp:5:21: error: direct-list-initialization of ‘auto’ requires exactly
one element [-fpermissive]
  std::pair x{42, 666};
 ^
c-a-d.cpp:5:21: note: for deduction to ‘std::initializer_list’, use
copy-list-initialization (i.e. add ‘=’ before the ‘{’)
c-a-d.cpp:5:21: internal compiler error: same canonical type node for different
types _Tp and pair
0x781f7b comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:1436
0x67fb58 template_args_equal(tree_node*, tree_node*)
../../gcc/cp/pt.c:7918
0x67f83f comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**)
../../gcc/cp/pt.c:7965
0x68f2f6 spec_hasher::equal(spec_entry*, spec_entry*)
../../gcc/cp/pt.c:1652
0x6e2be5 hash_table<spec_hasher, xcallocator>::find_with_hash(spec_entry*
const&, unsigned int)
../../gcc/hash-table.h:840
0x6ba9c2 lookup_template_class_1
../../gcc/cp/pt.c:8355
0x6ba9c2 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:8670
0x6d5f6e listify_autos
../../gcc/cp/pt.c:24023
0x6d88eb do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context)
../../gcc/cp/pt.c:24488
0x66f92f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:6706
0x76aeec cp_parser_init_declarator
../../gcc/cp/parser.c:18987
0x76b594 cp_parser_simple_declaration
../../gcc/cp/parser.c:12566
0x76b935 cp_parser_block_declaration
../../gcc/cp/parser.c:12442
0x76c3e9 cp_parser_declaration_statement
../../gcc/cp/parser.c:12051
0x74ae43 cp_parser_statement
../../gcc/cp/parser.c:10603
0x74bdbd cp_parser_statement_seq_opt
../../gcc/cp/parser.c:10935
0x74be9f cp_parser_compound_statement
../../gcc/cp/parser.c:10889
0x7698a3 cp_parser_function_body
../../gcc/cp/parser.c:20997
0x7698a3 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21033
0x76a2e1 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:25785
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.

ICE for the second:

c-a-d_2.cpp: In function ‘int main()’:
c-a-d_2.cpp:5:20: error: direct-list-initialization of ‘auto’ requires exactly
one element [-fpermissive]
  std::tuple y{1,2,3};
^
c-a-d_2.cpp:5:20: note: for deduction to ‘std::initializer_list’, use
copy-list-initialization (i.e. add ‘=’ before the ‘{’)
c-a-d_2.cpp:5:20: internal compiler error: same canonical type node for
different types _Tp and tuple
0x781f7b comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:1436
0x67fb58 template_args_equal(tree_node*, tree_node*)
../../gcc/cp/pt.c:7918
0x67f83f comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**)
../../gcc/cp/pt.c:7965
0x68f2f6 spec_hasher::equal(spec_entry*, spec_entry*)
../../gcc/cp/pt.c:1652
0x6e2b52 hash_table<spec_hasher, xcallocator>::find_with_hash(spec_entry*
const&, unsigned int)
../../gcc/hash-table.h:827
0x6ba9c2 lookup_template_class_1
../../gcc/cp/pt.c:8355
0x6ba9c2 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:8670
0x6d5f6e listify_autos
../../gcc/cp/pt.c:24023
0x6d88eb do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context)
../../gcc/cp/pt.c:24488
0x66f92f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:6706
0x76aeec cp_parser_init_declarator
../../gcc/cp/parser.c:18987
0x76b594 cp_parser_simple_declaration
../../gcc/cp/parser.c:12566
0x76b935 cp_parser_block_declaration
../../gcc/cp/parser.c:12442
0x76c3e9 cp_parser_declaration_statement
../../gcc/cp/parser.c:12051
0x74ae43 cp_parser_statement
../../gcc/cp/parser.c:10603
0x74bdbd cp_parser_statement_seq_opt
../../gcc/cp/parser.c:10935
0x74be9f cp_parser_compound_statement
../../gcc/cp/parser.c:10889
0x7698a3 cp_parser_function_body
../../gcc/cp/parser.c:20997
0x7698a3 cp_parser_ctor_initializer_opt_and_function

[Bug libstdc++/77802] [7 Regression] Boost Fiber doesn't compile

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Ville Voutilainen  ---
Fixed.

[Bug libstdc++/77802] [7 Regression] Boost Fiber doesn't compile

[ville.voutilainen at gmail dot com]

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

--- Comment #2 from Ville Voutilainen  ---
Mine.

[Bug libstdc++/77802] [7 Regression] Boost Fiber doesn't compile

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-30
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

[Bug c++/77781] [DR 1315] Some valid cases of partial specialization not accepted

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||jason at redhat dot com
Summary|[DR 1315]   |[DR 1315] Some valid cases
   ||of partial specialization
   ||not accepted

--- Comment #1 from Ville Voutilainen  ---
gcc rejects the following, clang accepts it:

template struct S; template struct
S{};

both gcc and clang reject this:

template struct S; template struct S{};

gcc accepts the following, clang rejects it:

template struct S; template struct S{};

[Bug c++/77781] New: [DR 1315]

[ville.voutilainen at gmail dot com]

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

Bug ID: 77781
   Summary: [DR 1315]
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

[Bug libstdc++/77727] Unwrapping std::optional constructor is not working for non-transferable object

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Ville Voutilainen  ---
Fixed.

[Bug libstdc++/77537] [6 Regression] pair constructors do not properly SFINAE

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Ville Voutilainen  ---
Fixed on gcc-6 branch, thus done.

[Bug libstdc++/77717] testsuite/21_strings/basic_string_view/operations/compare/char/1.cc makes undefined memcmp call

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Ville Voutilainen  ---
Fixed.

[Bug libstdc++/77727] Unwrapping std::optional constructor is not working for non-transferable object

[ville.voutilainen at gmail dot com]

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

--- Comment #2 from Ville Voutilainen  ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01777.html

[Bug libstdc++/77727] Unwrapping std::optional constructor is not working for non-transferable object

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-26
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug libstdc++/77717] testsuite/21_strings/basic_string_view/operations/compare/char/1.cc makes undefined memcmp call

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-23
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Ah, Jonathan fixed the problem for std::experimental::string_view in r238609,
we need to apply a similar fix to std::string_view's tests. I'll do that.

[Bug libstdc++/77537] pair constructors do not properly SFINAE

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-09-21
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #6 from Ville Voutilainen  ---
Reopen for tracking the backport.

[Bug libstdc++/77537] pair constructors do not properly SFINAE

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #7 from Ville Voutilainen  ---
And mine, again.

[Bug libstdc++/77537] pair constructors do not properly SFINAE

[ville.voutilainen at gmail dot com]

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

--- Comment #5 from Ville Voutilainen  ---
There's a fairly decent chance, sure. :) I'll cook up a patch.

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville.voutilainen at gmail dot com]

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

--- Comment #10 from Ville Voutilainen  ---
And yes, I plan to port this fix to experimental::optional on trunk and then
backport that.

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville.voutilainen at gmail dot com]

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

--- Comment #9 from Ville Voutilainen  ---
Fixed on trunk so far.

[Bug libstdc++/77537] pair constructors do not properly SFINAE

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Ville Voutilainen  ---
Fixed.

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

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Ville Voutilainen  ---
Fixed.

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

[ville.voutilainen at gmail dot com]

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

--- Comment #2 from Ville Voutilainen  ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01131.html

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

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #1 from Ville Voutilainen  ---
Mine.

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

[ville.voutilainen at gmail dot com]

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

Bug ID: 77616
   Summary: A variadic polymorphic lambda call fails with zero
arguments
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

Test:

int main()
{
[](auto...){}();
}

prog.cc: In function 'int main()':
prog.cc:3:19: error: no match for call to '(main()::<lambda(auto:1, ...)>) ()'
 [](auto...){}();
   ^
prog.cc:3:15: note: candidate: template main()::<lambda(auto:1,
...)>::operator decltype (((const main()::<lambda(auto:1, ...)>*)((const
main()::<lambda(auto:1, ...)>*
const)0u))->operator()(static_cast<auto:1&&>())) (*)(auto:1, ...)()
const 
 [](auto...){}();
   ^
prog.cc:3:15: note:   template argument deduction/substitution failed:
prog.cc:3:19: note:   candidate expects 1 argument, 0 provided
 [](auto...){}();
   ^
prog.cc:3:15: note: candidate: template main()::<lambda(auto:1,
...)>
 [](auto...){}();
   ^
prog.cc:3:15: note:   template argument deduction/substitution failed:
prog.cc:3:19: note:   candidate expects 1 argument, 0 provided
 [](auto...){}();
   ^

[Bug libstdc++/77537] pair constructors do not properly SFINAE

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
See https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01230.html

[Bug libstdc++/77495] optional assignment from {} acts weirdly

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Depends on||77288

--- Comment #1 from Ville Voutilainen  ---
The latest patch for PR 77288 fixes this problem as well.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77288
[Bug 77288] Std::experimental::optional::operator= implementation is broken in
gcc 6.1

[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Ville Voutilainen  ---
Fixed.

[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple

[ville.voutilainen at gmail dot com]

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

--- Comment #6 from Ville Voutilainen  ---
Fixed on trunk, backporting to the gcc-6 branch.

[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen  ---
And now the hopefully final patch at
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01990.html

[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple

[ville.voutilainen at gmail dot com]

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

--- Comment #2 from Ville Voutilainen  ---
Right, patch available at
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01983.html

Currently fixing negative test failures for it...

[Bug libstdc++/77395] [6/7 Regression] std::is_constructible is false for type constructible via implicit conversion operator affecting std::tuple

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-08-29
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville.voutilainen at gmail dot com]

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

--- Comment #7 from Ville Voutilainen  ---
See https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01634.html for what the
aforementioned superior approach looks like.

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville.voutilainen at gmail dot com]

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

--- Comment #6 from Ville Voutilainen  ---
There's a superior fix that retains conversions but doesn't cause this
regression. Stay tuned.

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville.voutilainen at gmail dot com]

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

--- Comment #5 from Ville Voutilainen  ---
Ah. That would indeed mean that every converting assignment introduces
a temporary. Design-wise I'd rather have it so that optional doesn't convert
at all in the assignment. :)

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville.voutilainen at gmail dot com]

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

--- Comment #3 from Ville Voutilainen  ---
>Now behaviour is the same as in gcc 5.1 - operator=(_Up&& __u) is chosen in 2 
>situations:
>1. _Up is NOT optional
>2. _Up is optional AND _Up is same as _Tp modulo cv-qualifiers, references etc.

How do you expect converting assignments to work if that signature
sfinaes away if decay<_Up> is not _Tp? As in, code like

optional os;
os = "meow";

[Bug libstdc++/77288] Std::experimental::optional::operator= implementation is broken in gcc 6.1

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-08-18
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from Ville Voutilainen  ---
Mine.

[Bug libstdc++/77264] [7 Regression] std::string's replace gives wrong results with C++17, works with C++11

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #5 from Ville Voutilainen  ---
Well, it seems that disambiguating with a properly exclusive sfinae constraint
should do the trick.

[Bug libstdc++/71899] An internal BooleanTestable trait should be provided

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
I dislike the #ifdef parts. It seems to me both modes of operation
could be provided without resorting to the preprocessor. I'm also
not a fan of the name boolean_testable - perhaps boolean_like would
be better? The rationale being that there are "boolean testable" types
that work in cases where a contextual conversion to bool is performed,
but those types are otherwise not "boolean-like". Sure, we could
go with boolean_testable and potentially contextually_boolean_testable
or some such. It seems to me that both of those facilities are useful.

I do wonder why we even bother supporting e.g. comparison operators that
don't just return bool, although that's in some ways a separate matter.

[Bug c++/71886] Incorrect error on operator() being an member in template

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
Clang also rejects the template.

[Bug libstdc++/71313] [Filesystem TS] remove_all fails to remove directory contents recursively

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Ville Voutilainen  ---
Fixed on all branches.

[Bug libstdc++/71313] [Filesystem TS] remove_all fails to remove directory contents recursively

[ville.voutilainen at gmail dot com]

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

--- Comment #3 from Ville Voutilainen  ---
Fixed on trunk so far, backporting to gcc-6 and gcc-5 shortly.

[Bug libstdc++/71313] [Filesystem TS] remove_all fails to remove directory contents recursively

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-06
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug libstdc++/71364] [7 regression] recent tuple changes break range-v3 merge.cpp

[ville.voutilainen at gmail dot com]

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

--- Comment #3 from Ville Voutilainen  ---
Which version of range-v3? I cloned https://github.com/ericniebler/range-v3.git
and its tests seem to pass on the current trunk.

[Bug libstdc++/71364] [7 regression] recent tuple changes break range-v3 merge.cpp

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-01
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from Ville Voutilainen  ---
I'll do some bisecting and other analysis.

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville.voutilainen at gmail dot com]

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

--- Comment #13 from Ville Voutilainen  ---
Right, that was fixed in the immediately following revision,
https://gcc.gnu.org/viewcvs/gcc?view=revision=236823

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville.voutilainen at gmail dot com]

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

--- Comment #11 from Ville Voutilainen  ---
I don't see how any of that code or the failure is in any way related to
std::tuple...

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville.voutilainen at gmail dot com]

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

--- Comment #8 from Ville Voutilainen  ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01914.html

[Bug c++/69855] Missing diagnostic for overload that only differs by return type

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #4 from Ville Voutilainen  ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00364.html

[Bug libstdc++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #7 from Ville Voutilainen  ---
If I use my_pair directly, gcc accepts the code. Once the inherited constructor
and my_real_pair are thrown into the mix, gcc starts rejecting the code.

[Bug libstdc++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #6 from Ville Voutilainen  ---
Here's a test snippet without library types. Clang accepts the code, gcc
rejects it.

template 
struct holder
{
T t;
};

template  
struct tuple_holder : holder
{
tuple_holder(Args&&... args) : holder{static_cast<Args&&>(args)}...
{}
tuple_holder(const tuple_holder&) = default;
tuple_holder(tuple_holder&&) = default;
};

template 
struct my_pair
{
template 
my_pair(tuple_holder) {}
my_pair(const my_pair&) = default;
};

template 
struct my_real_pair : my_pair<T, U>
{
using my_pair<T, U>::my_pair;
};

int main()
{
my_real_pair<int, float>(tuple_holder<int&&>(1));
}

prog.cc: In constructor 'my_real_pair<int,
float>::my_real_pair(tuple_holder) [with Args = {int&&}]':
prog.cc:26:26: error: use of deleted function
'tuple_holder::tuple_holder(const tuple_holder&) [with Args =
{int&&}]'
 using my_pair<T, U>::my_pair;
  ^~~
prog.cc:11:5: note: 'tuple_holder::tuple_holder(const
tuple_holder&) [with Args = {int&&}]' is implicitly deleted because the
default definition would be ill-formed:
 tuple_holder(const tuple_holder&) = default;
 ^~~~
prog.cc:11:5: error: use of deleted function 'holder<int&&>::holder(const
holder<int&&>&)'
prog.cc:2:8: note: 'holder<int&&>::holder(const holder<int&&>&)' is implicitly
deleted because the default definition would be ill-formed:
 struct holder
^~
prog.cc:2:8: error: copying non-static data member 'int&& holder<int&&>::t' of
rvalue reference type
prog.cc: In function 'int main()':
prog.cc:31:52: note: synthesized method 'my_real_pair<int,
float>::my_real_pair(tuple_holder) [with Args = {int&&}]' first
required here 
 my_real_pair<int, float>(tuple_holder<int&&>(1));
^

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[ville.voutilainen at gmail dot com]

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

--- Comment #10 from Ville Voutilainen  ---
(In reply to Jonathan Wakely from comment #8)
> I don't know how to implement is_default_constructible without using that
> decltype, or something similar that will cause the same problem.
> 
> If we had a __is_constructible(_Tp, _Args...) builtin we could use that (for
> is_constructible, and then define is_default_constructible in terms of that).

It would be possible to push the use of the decltype into a separate trait,
which sorta-kinda papers over the problem, but then we have an
is_default_constructible that gives different results depending on where you
use it for such a nested type (before or after it's been parsed completely),
which is surely ill-formed NDR, and possibly an ODR violation as well. I can't
fathom how a builtin would change that problem.

[Bug libstdc++/70437] [6 Regression] Instantiation loop with pair and is_constructible

[ville.voutilainen at gmail dot com]

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

--- Comment #2 from Ville Voutilainen  ---
Created attachment 38179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38179=edit
First stab at a patch

Initial patch done, testsuite additions to follow, will submit once
compile-farm testing is done.

[Bug libstdc++/70437] [6 Regression] Instantiation loop with pair and is_constructible

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug c++/70528] [5/6 Regression] bogus error: constructor required before non-static data member

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
A shorter reproducer for the funny part where the error arises:

template 
struct I {
};

struct J {
  struct K {
int First = 0;
  };
  I FunctionMDInfo;
};

[Bug c++/70037] [concepts] comdat group error and an ICE with a conceptified tuple implementation

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
The trace:

error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
"tuple<> is eligible for EBO" );
   ^
_ZNSt5tupleIJS_IJS_IJEEC1Ev/300 (constexpr std::tuple<
 >::tuple() requires
predicate((#‘unary_right_fold_expr’ not supported by expression#) &&
!(#‘unary_right_fold_expr’ not supported by expression#)) [with _Elements =
{std::tuple >}]) @0x7f2d3fd8d8a0
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: forced_by_abi public weak
comdat_group:_ZNSt5tupleIJS_IJS_IJEEC2Ev one_only visibility_specified
  Same comdat group as: _ZNSt5tupleIJS_IJS_IJEEC2Ev/299
  previous sharing asm name: 291
  References: _ZNSt5tupleIJS_IJS_IJEEC2Ev/299 (alias)
  Referring: 
  First run: 0
  Function flags:
  Called by: 
  Calls: 
_ZNSt5tupleIJS_IJS_IJEEC1Ev/291 (constexpr std::tuple<
 >::tuple() requires
predicate((#‘unary_right_fold_expr’ not supported by expression#) &&
(#‘unary_right_fold_expr’ not supported by expression#)) [with _Elements =
{std::tuple >}]) @0x7f2d400c2cf0
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: forced_by_abi public weak
comdat_group:_ZNSt5tupleIJS_IJS_IJEEC2Ev one_only visibility_specified
  Same comdat group as: _ZNSt5tupleIJS_IJS_IJEEC2Ev/290
  next sharing asm name: 300
  References: _ZNSt5tupleIJS_IJS_IJEEC2Ev/290 (alias)
  Referring: 
  First run: 0
  Function flags:
  Called by: 
  Calls: 
/home/ville/gcc-git/gcc/libstdc++-v3/testsuite/20_util/tuple/53648.cc:43:47:
internal compiler error: symtab_node::verify failed
0x941719 symtab_node::verify_symtab_nodes()
../../gcc/symtab.c:1219
0x953c1b symtab_node::checking_verify_symtab_nodes()
../../gcc/cgraph.h:602
0x953c1b symbol_table::compile()
../../gcc/cgraphunit.c:2380
0x9561a2 symbol_table::compile()
../../gcc/cgraphunit.c:2536
0x9561a2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/70037] New: [concepts] comdat group error and an ICE with a conceptified tuple implementation

[ville.voutilainen at gmail dot com]

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

Bug ID: 70037
   Summary: [concepts] comdat group error and an ICE with a
conceptified tuple implementation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

Created attachment 37838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37838=edit
Preprocessed test

Having difficulties reducing this, attaching preprocessed source.

[Bug c++/70036] New: [concepts] ICE with a dependent sizeof in a concept

[ville.voutilainen at gmail dot com]

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

Bug ID: 70036
   Summary: [concepts] ICE with a dependent sizeof in a concept
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

Test:

template  concept bool Large = sizeof(T) > 1;

template 
struct X
{
X() requires Large = default;
X() requires !Large = default;
};

int main()
{
X x;
X y;
}

This gives:

prog.cc: In function 'int main()':
prog.cc:1:47: internal compiler error: in dependent_type_p, at cp/pt.c:22550
 template  concept bool Large = sizeof(T) > 1;
   ^
0x5f5278 dependent_type_p(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:22550
0x6771c7 cxx_sizeof_or_alignof_type(tree_node*, tree_code, bool)
/home/heads/gcc/gcc-source/gcc/cp/typeck.c:1569
0x6039da tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16234
0x603188 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16150
0x5fdb78 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15774
0x6f7baa satisfy_predicate_constraint
/home/heads/gcc/gcc-source/gcc/cp/constraint.cc:1768
0x6f7baa satisfy_constraint_1
/home/heads/gcc/gcc-source/gcc/cp/constraint.cc:1975
0x6f8066 satisfy_constraint
/home/heads/gcc/gcc-source/gcc/cp/constraint.cc:2026
0x6f815a constraints_satisfied_p(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/constraint.cc:2133
0x5c9ecc add_function_candidate
/home/heads/gcc/gcc-source/gcc/cp/call.c:1994
0x5ca8ef add_candidates
/home/heads/gcc/gcc-source/gcc/cp/call.c:5351
0x5cae84 build_new_method_call_1
/home/heads/gcc/gcc-source/gcc/cp/call.c:8282
0x5cae84 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
/home/heads/gcc/gcc-source/gcc/cp/call.c:8478
0x5c4d8c build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/call.c:8012
0x690bc6 expand_default_init
/home/heads/gcc/gcc-source/gcc/cp/init.c:1756
0x690bc6 expand_aggr_init_1
/home/heads/gcc/gcc-source/gcc/cp/init.c:1858
0x691385 build_aggr_init(tree_node*, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/init.c:1606
0x5d739d build_aggr_init_full_exprs
/home/heads/gcc/gcc-source/gcc/cp/decl.c:5964
0x5d739d check_initializer
/home/heads/gcc/gcc-source/gcc/cp/decl.c:6108
0x5ed0e4 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/heads/gcc/gcc-source/gcc/cp/decl.c:6783
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.

[Bug libstdc++/69853] An inheriting constructor of the class that inherited std::tuple isn't called correctly

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED

--- Comment #2 from Ville Voutilainen  ---
The fix for http://cplusplus.github.io/LWG/lwg-active.html#2549 breaks
this code. But that breakage looks sane, because it prevents implicit
base-to-derived conversions that create temporaries. Consider the following
code,
which is valid on 5.x but ill-formed on 6:

#include 
#include 

using std::tuple;

template  struct mytuple : tuple 
{
using tuple::tuple;
}; 

void f(const mytuple& ft) 
{
std::cout << "address of ft: " << (void*)() << std::endl;
} 

int main() 
{
tuple t; 
std::cout << "address of t: " << (void*)() << std::endl;
f(t);
}

I'll add this as additional motivation for LWG 2549. Suspending the bug for
now, until LWG gives guidance.

[Bug libstdc++/69853] An inheriting constructor of the class that inherited std::tuple isn't called correctly

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-17
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
I'll see what I can do.

[Bug c++/69712] Storing and reusing a method pointer as compile time value

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-06
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.9.2, 5.2.0, 6.0

--- Comment #2 from Ville Voutilainen  ---
clang and msvc accept the code.

[Bug c++/69111] Problem with expansion of a parameter pack of templates

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-06
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.9.2, 5.2.0, 6.0

--- Comment #2 from Ville Voutilainen  ---
clang and msvc accept the code.

[Bug c++/60177] Unable to deduce template base of derived class in call to function taking a `simple-template-id`

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Ville Voutilainen  ---
This looks like a duplicate of a much older PR.

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

[Bug c++/42329] Deduction of template template argument via base class fails

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||filip.roseen at gmail dot com

--- Comment #1 from Ville Voutilainen  ---
*** Bug 60177 has been marked as a duplicate of this bug. ***

[Bug libstdc++/69354] std::thread doesn't support move-only callable objects

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #5 from Ville Voutilainen  ---
I'll see what I can do. :)

[Bug c++/69178] [concepts] An invalid expression in a requires-expression is evaluated too eagerly

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Ville Voutilainen  ---
Closing, the testcase isn't well-formed.

[Bug c++/69178] [concepts] An invalid expression in a requires-expression is evaluated too eagerly

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
This check happens in check_bases(), which doesn't take complain flags, so
wherever that check fails, it's always a hard error. I suppose the checking
function call chains that go to that function should accept complain flags
and then decide whether to produce a hard error or not?

[Bug c++/69178] New: [concepts] An invalid expression in a requires-expression is evaluated too eagerly

[ville.voutilainen at gmail dot com]

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

Bug ID: 69178
   Summary: [concepts] An invalid expression in a
requires-expression is evaluated too eagerly
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

Test snippet:

template  struct S : T {};
template  concept bool ConcreteDerivableFrom()
{
return requires()
{
S();
};
}

struct X final {};

template 
void f() {}

template 
void f() {}

int main()
{
f();
}

Fails with

prog.cc: In instantiation of 'struct S':
prog.cc:20:10:   required from here
prog.cc:1:27: error: cannot derive from 'final' base 'X' in derived type 'S'
 template  struct S : T {};
   ^

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville.voutilainen at gmail dot com]

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

--- Comment #7 from Ville Voutilainen  ---
Not so simple, still working on this.

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville.voutilainen at gmail dot com]

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

--- Comment #6 from Ville Voutilainen  ---
Should be a simple matter of doing the _NonNestedTuple checks before other
checks. Patch coming in a couple of days.

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-20
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #5 from Ville Voutilainen  ---
Mine.

[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Ville Voutilainen  ---
Done.

[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)

[ville.voutilainen at gmail dot com]

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

--- Comment #5 from Ville Voutilainen  ---
The enhancement PR is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68989.

[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen  ---
The current approach still needs to catch bad_new_array_length exceptions. That
is intended to be solved by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1992 so once we get
to stage 1 for gcc 7, we can tune this
further. I'll open a new enhancement PR for that and link this one to it.

[Bug libstdc++/68989] New: Core issue 1992 will make catching bad_new_array_length unnecessary in _M_grow_words

[ville.voutilainen at gmail dot com]

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

Bug ID: 68989
   Summary: Core issue 1992 will make catching
bad_new_array_length unnecessary in _M_grow_words
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1992, we can
remove the catch of bad_alloc in _M_grow_words once we get to stage 1 of gcc 7,
improving the solution for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68276.

[Bug libstdc++/68989] Core issue 1992 will make catching bad_new_array_length unnecessary in _M_grow_words

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-18
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
And it's mine. :) I'll keep Jason up to date about the library needs here
once Core makes issue 1992 ready.

[Bug libstdc++/68989] Core issue 1992 will make catching bad_new_array_length unnecessary in _M_grow_words

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
   Severity|normal  |enhancement

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
   Severity|normal  |enhancement

--- Comment #4 from Ville Voutilainen  ---
To elaborate on what Jonathan said: std::uninitialized_copy currently calls
std::copy for the trivial cases. std::copy should require assignability;
std::unitialized_copy wouldn't need to. We need to introduce a new low-level
function that does not perform the check, so that std::uninitialized_copy can
call it directly and std::copy can call it with a check. Furthermore, there
is a similar-ish optimization opportunity for std::uninitialized_fill and
std::uninitialized_fill_n (which currently call std::fill and std::fill_n, 
which should perform extra checks), those functions
would also benefit from yet another new low-level function.

After discussing this with Jonathan, we deemed it unsuitable for Stage 3.
I'll get back on this after we get to Stage 1 for gcc 7, chances are of course
that we can backport when the time comes.

Setting target milestone to 7 and changing importance to enhancement.

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #2 from Ville Voutilainen  ---
Mine.

[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-15
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug libstdc++/66693] [C++17] std::tuple_size fails with const std::array

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #2 from Ville Voutilainen  ---
Mine.

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

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Ville Voutilainen  ---
Done.

[Bug c++/68784] deductible parameter type still requires explicit reference cast, e.g., std::thread

[ville.voutilainen at gmail dot com]

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

--- Comment #5 from Ville Voutilainen  ---
And to add insult to injury, msvc accepts binding lvalue reference to
temporaries, and chances are that their thread constructor does what it does
partly because of that non-conforming core language extension.

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

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #2 from Ville Voutilainen  ---
Mine.

[Bug c++/68138] "operator== is ambiguous" when comparing a tuple containing values with one containing refs

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
The test works if operator== is not a member. There's something fairly fishy
going on here.

[Bug c++/68138] "operator== is ambiguous" when comparing a tuple containing values with one containing refs

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-11
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.2, 5.2.0, 6.0

[Bug c++/67813] [C++14] copy-initialization of object with pointer member fails in constexpr function

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
Shouldn't this be resolved as fixed?

[Bug c++/57443] Captured variable hide the parameter if they have the same name in Lambdas

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug c++/58566] [c++11] ICE with invalid expression in lambda body

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Ville Voutilainen  ---
Fixed on trunk.

[Bug c++/54367] [meta-bug] lambda expressions

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 58566, which changed state.

Bug 58566 Summary: [c++11] ICE with invalid expression in lambda body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/58566] [c++11] ICE with invalid expression in lambda body

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen  ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01075.html

[Bug c++/58566] [c++11] ICE with invalid expression in lambda body

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-11
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #3 from Ville Voutilainen  ---
Looks like this should be fixed by changing from void_type_node to
error_mark_node in lambda_return_type() when it diagnoses an incomplete
type. I'll see whether that causes any regressions.

[Bug c++/58566] [c++11] ICE with invalid expression in lambda body

[ville.voutilainen at gmail dot com]

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

--- Comment #5 from Ville Voutilainen  ---
Ahem, make that https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01076.html

[Bug c++/61362] g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 does not compile lambda with template

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #4 from Ville Voutilainen  ---
None of the examples ICE on the current trunk I have on Linux-X64. Can anyone
else verify whether the ICEs can still be triggered?

[Bug c++/61362] g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 does not compile lambda with template

[ville.voutilainen at gmail dot com]

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

--- Comment #5 from Ville Voutilainen  ---
Oh, some crash with -std=c++1z but not with the current default of -std=c++14.

[Bug c++/67844] [6 Regression] Cannot make tuple of class with template constructor

[ville.voutilainen at gmail dot com]

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

--- Comment #3 from Ville Voutilainen  ---
Patch available https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00358.html

[Bug c++/67844] [6 Regression] Cannot make tuple of class with template constructor

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Ville Voutilainen  ---
Fixed on trunk.

[Bug c++/67844] [6 Regression] Cannot make tuple of class with template constructor

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #2 from Ville Voutilainen  ---
To the extent anything in this area is obvious, yes. :) The check for
non-nested tuple ends up in infinite meta-recursion because A is constructible
from the tuple itself. I think that can be tackled by adding an is_same
check to _TNTC so that the converting templates that take a tuple 
outright reject tuples that are the same as the tuple itself. Fixing...

[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ville.voutilainen at gmail dot 
com
 Resolution|--- |FIXED

--- Comment #9 from Ville Voutilainen  ---
Fixed on trunk.