[Bug libstdc++/112569] libstdc++-v3/include/ranges:1456: missing check for self-assignment

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is exactly as it should be. There's no guarantee that self-move-assignment
on the associated range is a no-op, so the cache must be invalidated.

[Bug c++/111854] new (align_val_t) should be ill-formed

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #7 from TC  ---
Per https://eel.is/c++draft/basic.stc.dynamic.deallocation#3.sentence-4, `void
operator delete(void*, std::size_t, std::align_val_t);` is a usual deallocation
function just like `void operator delete(void*, std::size_t);` and therefore
this should be rejected for the same reason that the example in comment #3 is
rejected.

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

[rs2740 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from TC  ---
Confirmed with my reporter that this fixes their actual code too.

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

[rs2740 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from TC  ---
The crash is gone if lib2.o is compiled with bits/hashtable_policy.h patched
like so:

--- a/path/to/gcc-13/include/c++/13.2.0/bits/hashtable_policy.h
+++ b/hashtable_policy.h
@@ -327,18 +327,22 @@ namespace __detail

   __gnu_cxx::__aligned_buffer<_Value> _M_storage;

+  [[__gnu__::__always_inline__]]
   _Value*
   _M_valptr() noexcept
   { return _M_storage._M_ptr(); }

+  [[__gnu__::__always_inline__]]
   const _Value*
   _M_valptr() const noexcept
   { return _M_storage._M_ptr(); }

+  [[__gnu__::__always_inline__]]
   _Value&
   _M_v() noexcept
   { return *_M_valptr(); }

+  [[__gnu__::__always_inline__]]
   const _Value&
   _M_v() const noexcept
   { return *_M_valptr(); }

I'm following up with my reporter to see if this also fixes the problem with
their actual code.

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

[rs2740 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from TC  ---
Minimal example:

$ cat lib1.cpp
#include 
#include 

static std::unordered_set set;

void del(const std::string& s) {
set.erase(s);
}

$ cat lib2.cpp
#include 
#include 

static std::unordered_set set;

void add(const std::string& s) {
set.emplace(s);
}

const std::string& get(const std::string& s) {
return *set.find(s);
}

$ cat main.cpp

#include 

void add(const std::string&);
void del(const std::string&);
const std::string& get(const std::string&);

int main() {
add("foo");
del("bar");
(void) get("foo").size();
}

$ g++-10 -std=c++17 lib1.cpp -c -o lib1.o
$ g++-13 -std=c++17 lib2.cpp -c -o lib2.o
$ g++-13 -std=c++17 main.cpp lib1.o lib2.o -o test
$ ./test
Segmentation fault (core dumped)

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

[rs2740 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from TC  ---
The impacted members we observed are `_Hash_node_value_base::_M_valptr` and
`_Hash_node_value_base::_M_v`. I think the layout of `_Hash_node` didn't
change.

And I'm not seeing why fixing this will require breaking ABI again. For
example, if the affected functions are marked always_inline (or renamed, or
have their mangling otherwise changed), I would expect the resulting code to be
linkable with either the GCC10 version or the current version of the code,
unless I'm missing something?

[Bug libstdc++/111050] New: [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 111050
   Summary: [11/12/13/14 Regression] ABI break in
_Hash_node_value_base since GCC 11
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d
changed _Hash_node_value_base to no longer derive from _Hash_node_base, which
means that its member functions expect _M_storage to be at a different offset.
So explosions result if an out-of-line definition is emitted for any of the
member functions (say, in a non-optimized build) and the resulting object file
is then linked with code built using older version of GCC/libstdc++.

[Bug c++/110164] New: Improve diagnostic for incomplete standard library types due to missing include

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 110164
   Summary: Improve diagnostic for incomplete standard library
types due to missing include
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

If I forget to include a header before using a sufficiently well-known standard
library type, GCC helpfully reminds me of the header:

$ echo 'std::array x;' | g++ -x c++ -

:1:6: error: ‘array’ in namespace ‘std’ does not name a template type
:1:1: note: ‘std::array’ is defined in header ‘’; did you forget
to ‘#include ’?

But if I happen to have a different standard library header included that
happens to bring in a forward declaration of the type, the error message is
less helpful:

$ echo -e '#include \nstd::array x;' | g++ -x c++ -

:2:21: error: aggregate ‘std::array x’ has incomplete type and
cannot be defined

It would be nice if the latter case also has a hint about the potential missing
include.

[Bug c++/109803] New: [12 Regression] ICE with type defined in lambda inside generic lambda inside function template

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 109803
   Summary: [12 Regression] ICE with type defined in lambda inside
generic lambda inside function template
   Product: gcc
   Version: 12.3.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
void foo(T) {
[](auto){
[] {
struct X {};
};
};
}

template void foo(int);

: In instantiation of 'void foo(T) [with T = int]':
:10:22:   required from here
:4:9: internal compiler error: Segmentation fault
4 | [] {
  | ^
0x1bbabfe internal_error(char const*, ...)
???:0
0x10b0223 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10b0516 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10b0223 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x870a79 check_for_bare_parameter_packs(tree_node*, unsigned int)
???:0
0x8a7dfb finish_expr_stmt(tree_node*)
???:0
0x891a08 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x87e337 instantiate_decl(tree_node*, bool, bool)
???:0
0x899e8b instantiate_pending_templates(int)
???:0
0x7a5298 c_parse_final_cleanups()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

https://gcc.godbolt.org/z/sb5crbxf6

This is a regression in 12.3.0. 12.2.0 and 13.1.0 both compile this fine.

[Bug c++/109688] SPDLOG build fails with C++20 and -DSPDLOG_USE_STD_FORMAT=1

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #6 from TC  ---
https://cplusplus.github.io/LWG/issue3636 clarifies that formatter::format
must be const, which is not the case in that example.

[Bug c++/109655] New: Prior friend declaration causes "confused by earlier errors, bailing out" with missing constraint on out-of-class class template member definition

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 109655
   Summary: Prior friend declaration causes "confused by earlier
errors, bailing out" with missing constraint on
out-of-class class template member definition
   Product: gcc
   Version: 13.1.0
   URL: https://gcc.godbolt.org/z/dvTbz8vcj
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

class C
{
template 
requires true
friend class D;
};

template 
requires true
class D {
void f();
};

template  // missing "requires true"
void D::f()
{
}

With gcc 13.1, g++ -std=c++20 (or c++2b) produces

'
:15: confused by earlier errors, bailing out

Removing the in-class friend declaration produces a proper error message:

:12:14: error: redeclaration of 'template  requires  true class
D' with different constraints
   12 | void D::f()
  |

[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
The missing remove_cv_t is real, but this example is invalid. As the linked
cppreference page notes, you cannot pass a PMD to transform.

[Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 109232
   Summary: Using deduced return type in an unevaluated context
leads to codegen
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

auto begin(auto&& r) {
return r.begin();
}

namespace {
struct R {
int* begin();
};
}

static_assert(__is_same(decltype(begin(R())), int*));
int main() {}

Even though ::begin is only used in an unevaluated context, GCC at -O0
generates code for begin, leading to a warning and a failure to link
(https://gcc.godbolt.org/z/cdajoP7f3):

:10:14: warning: 'int* {anonymous}::R::begin()' used but never defined
   10 | int* begin();
  |  ^
/opt/compiler-explorer/gcc-trunk-20230320/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc7gqEhh.o: in function `auto begin<(anonymous namespace)::R&>((anonymous
namespace)::R&)':
:2: undefined reference to `(anonymous namespace)::R::begin()'
collect2: error: ld returned 1 exit status
Execution build compiler returned: 1

[Bug middle-end/109224] New: Wmismatched-new-delete false positive with corotuines

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 109224
   Summary: Wmismatched-new-delete false positive with corotuines
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

#include 

struct Task {
struct promise_type {
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() { throw; }
Task get_return_object() { return {}; }
void return_void() {}

template
void* operator new(std::size_t sz, I);

void operator delete(void* ptr, std::size_t);
};
};

Task f(int) {
co_return;
}

int main() {
f(42);
}

g++ -std=c++20 -Wall produces (https://gcc.godbolt.org/z/vjvrPr6dc):

: In function 'Task f(int)':
:20:1: warning: 'static void Task::promise_type::operator delete(void*,
std::size_t)' called on pointer returned from a mismatched allocation function
[-Wmismatched-new-delete]
   20 | }
  | ^
:20:1: note: returned from 'static void* Task::promise_type::operator
new(std::size_t, I) [with I = int]'
   20 | }
  | ^


This is basically how coroutine frame allocation works (the promise type's
operator new can optionally view the coroutine's parameters, while operator
delete doesn't). Notably C++23 std::generator does something like this and the
reference implementation triggers the same warning.

Oddly enough, if operator new is not a template, i.e., operator new(size_t,
int), there's no warning.

[Bug libstdc++/109165] New: std::hash>::operator() should be const

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 109165
   Summary: std::hash>::operator() should be
const
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Cpp17Hash requires const-callability.

[Bug libstdc++/109111] New: Definition of repeat_view::_Iterator has wrong template-head

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 109111
   Summary: Definition of repeat_view::_Iterator has wrong
template-head
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

In :


  template
requires (is_object_v<_Tp> && same_as<_Tp, remove_cv_t<_Tp>>
  && (__detail::__is_integer_like<_Bound> || same_as<_Bound,
unreachable_sentinel_t>))
  class repeat_view : /* ... */


  template
requires __detail::__is_integer_like<_Bound> || same_as<_Bound,
unreachable_sentinel_t>
  class repeat_view<_Tp, _Bound>::_Iterator

The requires-clause should match.

Clang trunk diagnoses this (but not GCC, so there's probably a compiler bug
here too).

[Bug libstdc++/108952] Regression in uses_allocator_construction_args for pair of rvalue references

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
https://cplusplus.github.io/LWG/issue3527

[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #8 from TC  ---
https://cplusplus.github.io/LWG/issue3057?

[Bug libstdc++/103013] Underconstrained constructor span(_Range&&)

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
I don't think this needs an extra constraint, just reordering the existing ones
to check not-a-span (14.3, "remove_­cvref_­t is not a specialization of
span") first.

But this is very much undefined anyway.

[Bug c++/102802] Selection of inherited operator contrary to `using` clause in C++ when using lambda type

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
No, this is valid. B's operator() is not visible, but its conversion to
function pointer is, and that introduces a surrogate call function during the
overload resolution for the function call expression (and it's selected because
it is the only viable candidate).

[Bug libstdc++/102863] New: Optional monadic ops should not be constrained

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 102863
   Summary: Optional monadic ops should not be constrained
   Product: gcc
   Version: 12.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's important that these are not constrained with invocable; that constraint
can trigger hard errors during overload resolution. For instance:

void f(int&);

int main() {
std::optional x;
x.transform([](auto& y) { f(y); return 42; });
}

: In instantiation of 'main():: [with auto:3 = const
int]':
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:2565:26:
  required by substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
main()::; _Args = {const int&}]'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:2576:55:
  required from 'struct std::__result_of_impl, const int&>'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:3038:12:
  recursively required by substitution of 'template
struct std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result = std::__invoke_result,
const int&>; _Ret = void]'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:3038:12:
  required from 'struct std::is_invocable, const
int&>'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/type_traits:3286:71:
  required from 'constexpr const bool
std::is_invocable_v, const int&>'
/opt/compiler-explorer/gcc-trunk-20211020/include/c++/12.0.0/concepts:336:25:  
required by substitution of 'template  requires  invocable<_Fn,
const _Tp&> constexpr auto std::optional::transform(_Fn&&) const & [with
_Fn = int]'
:7:16:   required from here
:7:32: error: binding reference of type 'int&' to 'const int' discards
qualifiers
7 | x.transform([](auto& y) { f(y); return 42; });
  |   ~^~~
:3:8: note:   initializing argument 1 of 'void f(int&)'
3 | void f(int&);
  |^~~~

[Bug libstdc++/101263] non-propagating-cache::emplace-deref missing constexpr

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #7 from TC  ---
(In reply to Barry Revzin from comment #6)
> The "real" answer is allowing constexpr placement new, but that obviously
> doesn't help you right now.
> 
> But I think the helpful answer is that you can add a constructor to your
> storage like storage(init_from_invoke_t, Args&&... args) that initializes
> the underlying value from invoke((Args&&)args...), and then
> construct_at(, init_from_invoke, [&]() -> decltype(auto) { return
> *i; }).
> 
> Something like that?

Yes. Something at that level of generality will be needed for the new
optional::transform, so it seems the better approach.

In my proof-of-concept implementation (which didn't have that concern), I used
something tailored to this specific case, along the lines of 

struct __deref_tag {};

template
struct __cache_wrapper {
template
constexpr __cache_wrapper(__deref_tag, const _Iter& __i)
: __t(*__i) {}
_Tp __t;
};

and then stored a __non_propagating_cache<__cache_wrapper>>
__cache, so that emplace-deref(i) is __cache.emplace(__deref_tag{}, i);

[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression

[rs2740 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from TC  ---
(In reply to Jonathan Wakely from comment #6)
> I have looked in detail (I have the 3rd, 4th and 5th editions here) but my
> brain started oozing out of my ears.
> 
> 15.10.2.15 NonemptyClassRanges and 15.10.2.16 NonemptyClassRangesNoDash are
> the relevant sections of the 1999 3rd edition. The former defines:
> 
>   The internal helper function CharacterRange takes two CharSet parameters
>   A and B and performs the following:
>   1. If A does not contain exactly one character or B does not contain
> exactly
>   one character then throw a SyntaxError exception.
> 
> And the latter has this note:
> 
>   Informative comments: ClassRanges can expand into single ClassAtoms and/or
>   ranges of two ClassAtoms separated by dashes. In the latter case the
>   ClassRanges includes all characters between the first ClassAtom and the
>   second ClassAtom, inclusive; an error occurs if either ClassAtom does not
>   represent a single character (for example, if one is \w) or if the first
>   ClassAtom's code point value is greater than the second ClassAtom's code
>   point value.
> 
> 
> 
> The ClassAtom \w does not contain exactly one character, so I think it's a
> syntax error.
> 
> The 3rd edition doesn't mention any legacy features of RegExp, but it does
> seem to require the strict behaviour.

I've looked at the 1999 spec now, and agree with your reading.

[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #5 from TC  ---
Hmm, but C++'s normative reference is to a 1999 version of ECMAScript...which
might well have the "legacy" behavior? (I haven't looked at it in detail.)

[Bug c++/102247] Overload resolution with brace-init is ambiguous when it shouldn't be

[rs2740 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from TC  ---
See also PR 60027 and its duplicates.

[Bug c++/102247] Overload resolution with brace-init is ambiguous when it shouldn't be

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
struct X { explicit X() {} };
struct Y { Y() {} };

void f(X);
void f(Y);

void g() {
f({}); // GCC rejects, clang accepts
}

GCC is correct. For copy-list-initialization, explicitness of constructor is
not considered in forming implicit conversion sequences; rather, if a explicit
constructor is chosen, the program is ill-formed. See core issue 1228 and 
[over.match.list].

[Bug c++/101107] Misleading error message in aggregate initialization in CRTP base class

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Since `*this` can't initialize an `A`, it's assuming brace elision. Not sure
how the diagnostic can be made clearer though...perhaps it can report that
assumption?

[Bug c++/101113] g++ thinks constructor suppressed by a requires clause is actually a bad copy constructor

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
https://eel.is/c++draft/class.copy.ctor#5

I don't think this code is valid. The constraint (which isn't checked until
overload resolution time anyway) can't suppress the outright ill-formedness of
the declaration.

[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args

[rs2740 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from TC  ---
(In reply to Patrick Palka from comment #6)
> 
> For the other adaptors, we still unconditionally disable perfect forwarding
> call wrapper semantics.  I'm not sure if the performance/diagnostic tradeoff
> is worth it to enable perfect forwarding semantics when the function object
> is non-trivial.

Personally, I'd happily pay some diagnostic complexity when I get things wrong
if that means I get better performance when I get things right. Good
diagnostics only matter when my code is broken, while performance matters when
my code is working. The former should (hopefully) be a transient condition.

[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
(In reply to Patrick Palka from comment #3)
> Good point, confirmed.  Though I'm not sure if perfect forwarding here is
> strictly necessary to fix this testcase.  Perhaps the
> _S_has_simple_extra_args versions of _Partial should be forwarding the bound
> arguments as prvalues instead of as const lvalues?

It's pretty easy to come up with counterexamples that don't work (for example,
the type might be move-only).

It may be better to limit the "simple" case for take/drop to when the argument
type is integer-like; that's like 99% of uses anyway. Contrived examples gets
the perfect forwarding fun but that's fine.

Similarly, it might be a good idea to restrict the "simple" case for the other
adaptors a bit - perhaps to the case where the predicate is trivially copyable,
which should still give good diagnostic for a lot of uses, but avoids a
performance hit if the function object at issue is like...std::function.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #21 from TC  ---
(In reply to David Friberg from comment #19)
> 
> P0398R0 [1] describes the final resolution to CWG 1518, after which the
> following example is arguably well-formed:
> 

It's not. Explicitness of a constructor is not considered when forming implicit
conversion sequences from a braced-init-list, and therefore the assignment is
ambiguous because {} can convert to either S or tag_t, even though the latter
is ill-formed if actually used.

[Bug c++/100825] function signature constraints are not a part of mangled name

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #7 from TC  ---
I think the code is valid; it's just that the ABI doesn't have a mangling for
constraints yet: https://github.com/itanium-cxx-abi/cxx-abi/issues/24

[Bug libstdc++/100823] New: Special member functions of common_iterator should be conditionally trivial

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 100823
   Summary: Special member functions of common_iterator should be
conditionally trivial
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

At least as a QoI matter, the special member functions of common_iterator
should be trivial when the corresponding special member function of variant is. Given that the standard depicts a variant exposition-only member
with implicitly declared special member functions, it is arguable that this is
actually required.

There appears to be a couple other conformance issues too:

- the move special members are missing
- the copy assignment calls the converting assignment operator, but unlike the
latter, there's no !valueless_by_exception() precondition on the (implicitly
declared) copy assignment.

[Bug libstdc++/100768] New: Range iterator operations should be function objects

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 100768
   Summary: Range iterator operations should be function objects
   Product: gcc
   Version: 12.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 implemented as plain function templates, which don't meet
the requirements in http://eel.is/c++draft/range.iter.ops.general#2

[Bug c++/100708] New: dynamic_cast can convert xvalue to lvalue

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 100708
   Summary: dynamic_cast can convert xvalue to lvalue
   Product: gcc
   Version: 12.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

struct A { virtual ~A() {}; };
struct B : A {} b;

void g ()
{
dynamic_cast(static_cast(b));
}

[expr.dynamic.cast]/2 says that for dynamic_cast(v):

If T is an lvalue reference type, v shall be an lvalue of a complete class
type, and the result is an lvalue of the type referred to by T.

[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
(In reply to 康桓瑋 from comment #1)
> Another issue is that in elements_view::_Sentinel in ranges#L3677:
> 
> 
>   templatetypename _Base2 = __detail::__maybe_const_t<_Const2, _Vp>>
> requires sized_sentinel_for, iterator_t<_Base2>>
> friend constexpr range_difference_t<_Base2>
> operator-(const _Iterator<_Const2>& __x, const _Sentinel& __y)
> { return __x._M_current - __y._M_end; }
> 
> 
> the return type of the function is range_difference_t<_Base2>, but in
> [range.elements#sentinel], it is defined as range_difference_t:
> 
> 
>   template
> requires sized_­sentinel_­for, iterator_t   const>>
>   friend constexpr range_difference_t
> operator-(const iterator& x, const sentinel& y);
> 
> 
> Perhaps range_difference_t and range_difference_t<_Base2> are
> equivalent in this case, but I am not sure.

This one is a problem with the WP.

[Bug c++/100592] New: Bogus "qualifiers cannot be applied" error with reference type produced by dependent alias template

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 100592
   Summary: Bogus "qualifiers cannot be applied" error with
reference type produced by dependent alias template
   Product: gcc
   Version: 12.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
struct meta {
template
using if_c = T;
};

template<>
struct meta {
template
using if_c = U;
};

template 
using if_c = typename meta::template if_c;

template
inline constexpr bool b = false;

template 
using foo = if_c, int, T>;

template
struct type {};

template 
using test = type const&>;

template
test f();

void g() {
f();
}

GCC rejects:

: In function 'void g()':
:32:12: error: no matching function for call to 'f()'
   32 | f();
  | ~~~^~
:29:9: note: candidate: 'template test f()'
   29 | test f();
  | ^
:29:9: note:   template argument deduction/substitution failed:
: In substitution of 'template using test = type >::if_c&> [with T = int&]':
:29:9:   required by substitution of 'template test f()
[with T = int&]'
:32:12:   required from here
:26:7: error: 'const' qualifiers cannot be applied to
'meta::if_c' {aka 'int&'}
   26 | using test = type const&>;
  |   ^~~~

[Bug c++/100579] New: [coroutines] Poor codegen using an optional-like type with co_await

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 100579
   Summary: [coroutines] Poor codegen using an optional-like type
with co_await
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

#ifdef __clang__
#include 
namespace stdx = std::experimental;
#else
#include 
namespace stdx = std;
#endif
struct O {
 ~O() {}
 struct promise_type {
 O get_return_object() { return O{this};}
 stdx::suspend_never initial_suspend() { return {}; }
 stdx::suspend_never final_suspend() noexcept { return {}; }
 void return_void(){ value->b = true; }
 void unhandled_exception(){ throw; }

 auto await_transform(O o) {
 struct A {
 bool await_ready() {
 return o_.b;
 }
 void await_resume() {}
 void await_suspend(stdx::coroutine_handle<> h){
 h.destroy();
 }
 O o_;
 };
 return A{o};
 }
 O* value;
 };

 explicit O(promise_type* p){ p->value = this; }
 explicit O(bool b) : b(b) {}

 bool b = false;
};

O g();

O f() { co_await g();  co_return; }

This is basically a reduced version of
https://github.com/facebook/folly/blob/99f856ae2009a80b157b5121e44b1f70f61bd7c9/folly/Optional.h#L613-L678

GCC does not appear to be able to optimize away the coroutine frame allocation,
while Clang does: https://gcc.godbolt.org/z/7981o81ne

[Bug libstdc++/100479] New: range adaptors handle cached iterators incorrectly

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 100479
   Summary: range adaptors handle cached iterators incorrectly
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

template
  struct _CachedPosition<_Range>
  {
  private:
iterator_t<_Range> _M_iter{};

  public:
constexpr bool
_M_has_value() const
{ return _M_iter != iterator_t<_Range>{}; }

constexpr iterator_t<_Range>
_M_get(const _Range&) const
{
  __glibcxx_assert(_M_has_value());
  return _M_iter;
}

constexpr void
_M_set(const _Range&, const iterator_t<_Range>& __it)
{
  __glibcxx_assert(!_M_has_value());
  _M_iter = __it;
}
  };

- The domain of == for forward iterators is limited to iterators over the same
underlying sequence. While value-initialized forward iterators of the same type
may be compared against each other, comparing them against iterators into other
ranges is not required to be well-defined, so it cannot be used as a sentinel
value.
- The cache cannot be allowed to propagate when the view containing it is
copied/moved, and has to be invalidated when the view containing it is moved.
Any cached iterator points to the original underlying view, and not the new
one; also, moving from a view can change its value (if it is well-defined to
use the moved-from view), so the cache is no longer valid. (Handling this case
correctly was actually the original use case for non-propagating-cache in
range-v3.)

[Bug c++/100374] New: Type-constraints of member function templates should not be substituted into during implicit instantiation

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 100374
   Summary: Type-constraints of member function templates should
not be substituted into during implicit instantiation
   Product: gcc
   Version: 12.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
concept C = true;

template 
struct Foo
{
  template  U>
  void bar()
  {
  }
};

Foo f;

GCC trunk with -std=c++20 produces:

: In instantiation of 'struct Foo':
:13:12:   required from here
:8:8: error: 'float' is not a class, struct, or union type
8 |   void bar()
  |^~~

[temp.inst]/17 says that type-constraints like C should
not be substituted into during the implicit instantiation of the declaration of
Foo::bar:

The type-constraints and requires-clause of a template specialization or member
function are not instantiated along with the specialization or function itself,
even for a member function of a local class; substitution into the atomic
constraints formed from them is instead performed as specified in
[temp.constr.decl] and [temp.constr.atomic] when determining whether the
constraints are satisfied or as specified in [temp.constr.decl] when comparing
declarations.

[Bug c++/100368] New: Missing guaranteed elision in constexpr evaluation

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 100368
   Summary: Missing guaranteed elision in constexpr evaluation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

struct S {
  S() = default;
  S(const S&) = delete;
};

struct array {
  S s[2];
};

struct PS {
  constexpr array operator*() const { return {}; }
};

struct W {
  constexpr W(const PS& p)   // 1
: t(*p) {}
  array t;
};

W w(PS{});

This issues a spurious complaint on trunk and then ICEs:

source>: In constructor 'constexpr W::W(const PS&)':
:17:14: error: use of deleted function 'array::array(array&&)'
   17 | : t(*p) {}
  |  ^
:7:8: note: 'array::array(array&&)' is implicitly deleted because the
default definition would be ill-formed:
7 | struct array {
  |^
:7:8: error: use of deleted function 'S::S(S&&)'
:4:3: note: declared here
4 |   S(S&&) = delete;
  |   ^
:17:14: internal compiler error: tree check: expected target_expr, have
error_mark in bot_manip, at cp/tree.c:3095
   17 | : t(*p) {}
  |  ^
0x1d002c9 internal_error(char const*, ...)
???:0
0x67b4e3 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0x13967e3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x9ad0ae break_out_target_exprs(tree_node*, bool)
???:0
0x72aa0a maybe_save_constexpr_fundef(tree_node*)
???:0
0x7b0711 finish_function(bool)
???:0
0x8e2c4d c_parse_file()
???:0
0xa63232 c_common_parse_file()
???:0
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.

Removing the constexpr on the line marked #1 makes it compile. Both clang and
MSVC accept the original code.

[Bug libstdc++/100290] New: join_view::_Iterator::operator++ copies _M_parent->_M_inner when _S_ref_is_glvalue is false

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 100290
   Summary: join_view::_Iterator::operator++ copies
_M_parent->_M_inner when _S_ref_is_glvalue is false
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

auto&& __inner_range = [this] () -> decltype(auto) {
  if constexpr (_S_ref_is_glvalue)
return *_M_outer;
  else
return _M_parent->_M_inner;
}();

This is a copy in the else case due to decltype(auto) producing the declared
type of _M_inner. The lambda should return auto&&.

[Bug c++/99273] New: List initialization prefers initializer_list a little too strongly

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 99273
   Summary: List initialization prefers initializer_list a little
too strongly
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

This is basically bug 64665 but closed back in 2015 - I think incorrectly.
Reduced test case:

#include 

struct S { S(int); };
void f(std::initializer_list);
int f(int);

using T = decltype(f({1}));
using T = int;

GCC rejects (picking the initializer_list overload); Clang accepts.

{1} to initializer_list is a user-defined conversion
(https://eel.is/c++draft/over.ics.list#5); {1} to int is a standard conversion
- in particular, the identity conversion
(https://eel.is/c++draft/over.ics.list#10.1). Since the conversion sequences
are not of the same basic form, https://eel.is/c++draft/over.ics.rank#2
controls and says that the latter is better.

DR 1467 modified what is now https://eel.is/c++draft/over.ics.rank#3.1 to say
that a list initialization sequence that converts to initializer_list is better
than any other list-initialization sequence "even if one of the other rules in
this paragraph would otherwise apply", but paragraph 3 only applies when the
two conversion sequences have the same basic form. In the above example, they
don't.

[Bug c++/99081] New: Misleading -Wmissing-field-initializers warning on out-of-order designated initializers

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 99081
   Summary: Misleading -Wmissing-field-initializers warning on
out-of-order designated initializers
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

struct A {
int a; int b;
};

A a { .b = 1, .a = 2};

with g++ -std=c++2a -O3 -Wall -Wextra produces

:5:21: warning: missing initializer for member 'A::a'
[-Wmissing-field-initializers]
5 | A a { .b = 1, .a = 2};
  | ^
:5:21: error: designator order for field 'A::a' does not match
declaration order in 'A'

The real problem is the error, of course, but the warning is just noise and
also incorrect - there is an initializer for a in the code, after all.

[Bug libstdc++/97935] New: Missing subsumption in iterator category detection

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 97935
   Summary: Missing subsumption in iterator category detection
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

In :

  template
requires (!requires { typename _Iter::iterator_category; }
  && __detail::__cpp17_randacc_iterator<_Iter>)
struct __cat<_Iter>
{ using type = random_access_iterator_tag; };

  template
requires (!requires { typename _Iter::iterator_category; }
  && __detail::__cpp17_bidi_iterator<_Iter>)
struct __cat<_Iter>
{ using type = bidirectional_iterator_tag; };

  template
requires (!requires { typename _Iter::iterator_category; }
  && __detail::__cpp17_fwd_iterator<_Iter>)
struct __cat<_Iter>
{ using type = forward_iterator_tag; };

The !requires part of the constraints do not subsume each other, so any
iterator that is a __cpp17_bidi_iterator or stronger causes an ambiguity. It
needs to be extracted into a concept.

[Bug libstdc++/97869] New: defines __cpp_lib_span even when doesn't provide an implementation

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 97869
   Summary:  defines __cpp_lib_span even when 
doesn't provide an implementation
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

 defines __cpp_lib_span if __cplusplus > 201703L and _GLIBCXX_HOSTED,
but  only provides a definition of std::span when __cpp_lib_concepts is
defined.

[Bug libstdc++/97120] circular concept loops in

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Concept evaluation is lazy, not eager. See [temp.inst]/18.

[Bug c++/96331] Class template argument deduction (CTAD) with Concepts

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Nicole from comment #0)
> > template
> 
> This is not valid. fixed_string is a class template, not a type and not a
> concept. So you can't use it as a template parameter.
> 
> I don't think this is a bug.

It is a placeholder for a deduced class type, which is allowed by
[temp.param]/6.3.

The example can be reduced drastically:

template
struct S { };

template
concept C = true;

static_assert(C{}>); // OK

template
void f() requires C { // error
}

:11:19: error: class template argument deduction failed:

   11 | void f() requires C {

  |   ^~~~

:11:19: error: no matching function for call to 'S(S<...auto...>)'

:2:8: note: candidate: 'template S()-> S'

2 | struct S {

  |^

:2:8: note:   template argument deduction/substitution failed:

:11:19: note:   candidate expects 0 arguments, 1 provided

   11 | void f() requires C {

  |   ^~~~

:2:8: note: candidate: 'template S(S)-> S'

2 | struct S {

  |^

:2:8: note:   template argument deduction/substitution failed:

:11:19: note:   mismatched types 'S' and 'S<...auto...>'

   11 | void f() requires C {

  |   ^~~~

Compiler returned: 1

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
Note that https://wg21.link/iterator.concept.winc#10 requires numeric_limits
specializations for integer-class types.

[Bug c++/96078] New: [10/11 Regression] flatten attribute on constructor and destructor causes spurious warning

[rs2740 at gmail dot com]

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

Bug ID: 96078
   Summary: [10/11 Regression] flatten attribute on constructor
and destructor causes spurious warning
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

struct A {
[[gnu::flatten]] A() {}
[[gnu::flatten]] ~A() {}
};

A a;

Produces no warnings with GCC 9 but on GCC 10 and trunk warns:

:3:22: warning: 'flatten' attribute is ignored on aliases
[-Wattributes]

3 | [[gnu::flatten]] ~A() {}

  |  ^

:2:22: warning: 'flatten' attribute is ignored on aliases
[-Wattributes]

2 | [[gnu::flatten]] A() {}

  |  ^

The warning appears to be introduced by the fix to PR92372.

Marking `A` as `final` eliminates the warnings, as does giving it an virtual
base class. Presumably the issue is that in the problematic case one of the
complete/base object c/dtors was treated as an alias for the other?

[Bug libstdc++/95904] New: Improve the diagnostic for conflicting return types in std::visit

[rs2740 at gmail dot com]

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

Bug ID: 95904
   Summary: Improve the diagnostic for conflicting return types in
std::visit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

std::variant x;
std::visit([] (auto i) { return i; }, x);

produces a less than ideal error with libstdc++:

In file included from :1:

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant: In
instantiation of 'static constexpr auto
std::__detail::__variant::__gen_vtable_impl, std::integer_sequence >::_S_apply() [with _Result_type =
std::__detail::__variant::__deduce_visit_result; _Visitor =
main()::&&; _Variants = {std::variant&}; long
unsigned int ...__indices = {1}]':

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:962:56:  
required from 'static constexpr void
std::__detail::__variant::__gen_vtable_impl, std::integer_sequence >::_S_apply_single_alt(_Tp&, _Tp*) [with bool
__do_cookie = false; long unsigned int __index = 1; _Tp =
std::__detail::__variant::_Multi_array
(*)(main()::&&, std::variant&)>; _Result_type =
std::__detail::__variant::__deduce_visit_result; _Visitor =
main()::&&; long unsigned int ...__dimensions = {2}; _Variants
= {std::variant&}; long unsigned int ...__indices = {}]'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:941:48:  
required from 'constexpr const _Array_type
std::__detail::__variant::__gen_vtable,
main()::&&, std::variant&>::_S_vtable'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:1685:45:  
required from 'constexpr decltype(auto) std::__do_visit(_Visitor&&, _Variants&&
...) [with _Result_type = std::__detail::__variant::__deduce_visit_result;
_Visitor = main()::; _Variants = {std::variant&}]'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:1704:35:  
required from 'constexpr decltype(auto) std::visit(_Visitor&&, _Variants&& ...)
[with _Visitor = main()::; _Variants = {std::variant&}]'

:5:43:   required from here

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:1028:67:  
in 'constexpr' expansion of
'std::__detail::__variant::__gen_vtable_impl
(*)(main()::&&, std::variant&), 2>,
std::integer_sequence >::_S_apply()'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:926:19:  
in 'constexpr' expansion of
'std::__detail::__variant::__gen_vtable_impl
(*)(main()::&&, std::variant&), 2>,
std::integer_sequence >::_S_apply_all_alts<0, 1>(__vtable,
(std::make_index_sequence<2>(), std::make_index_sequence<2>()))'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:1017:43:
error: invalid conversion from 'std::__success_type::type
(*)(main()::&&, std::variant&)' {aka 'long int
(*)(main()::&&, std::variant&)'} to
'std::__detail::__variant::_Multi_array
(*)(main()::&&, std::variant&)>::__untag_result
(*)(main()::&&, std::variant&)>::element_type'
{aka 'int (*)(main()::&&, std::variant&)'}
[-fpermissive]

 1017 |   { return _Array_type{&__visit_invoke}; }

  |   ^

  |   |

  |   std::__success_type::type (*)(main()::&&, std::variant&) {aka
long int (*)(main()::&&, std::variant&)}

Not only is the error about type mismatch in some function pointer conversion
deep in the guts of the library, but it even offers a "helpful" option to
suppress it with -fpermissive...

Both MSVC and libc++ handle this case with a nice static_assert.

[Bug libstdc++/95282] New: atomic::load in C++20 calls __atomic_load with a pointer-to-const as the output

[rs2740 at gmail dot com]

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

Bug ID: 95282
   Summary: atomic::load in C++20 calls
__atomic_load with a pointer-to-const as the output
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

We have

  _Fp
  load(memory_order __m = memory_order_seq_cst) const noexcept
  { return __atomic_impl::load(&_M_fp, __m); }

which calls

template
  _GLIBCXX_ALWAYS_INLINE _Tp
  load(_Tp* __ptr, memory_order __m) noexcept
  {
alignas(_Tp) unsigned char __buf[sizeof(_Tp)];
_Tp* __dest = reinterpret_cast<_Tp*>(__buf);
__atomic_load(__ptr, __dest, int(__m));
return *__dest;
  }

Here &_M_fp is a const _Fp*, so _Tp is const-qualified. GCC's __atomic_load
appears to happily tolerate a pointer-to-const dest (which seems rather
dubious), but Clang's doesn't.

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

[rs2740 at gmail dot com]

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

--- Comment #8 from TC  ---
(really from Tim)

This is https://cplusplus.github.io/LWG/issue3420

[Bug c++/95153] Arrays of 'const void *' should not be copyable in C++20

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
This is behaving as specified.

const void* const a[10];
const void* const b[10](a);

is valid code in C++20; it initializes b[0] with [0] converted to a const
void*, and the rest of b with null pointers.

The void* case is

void* const a[10];
void* const b[10](a);

which is invalid because [0] is a void* const*; converting that to void* is
not allowed because it casts away constness.

[Bug libstdc++/91243] is_invocable mishandles functions returning indestructible types by value

[rs2740 at gmail dot com]

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

--- Comment #5 from TC  ---
I don't think we should use decltype's special rule in this context :)

Also, std::is_nothrow_invocable_v hard-errors in libstdc++, because the
noexcept operator doesn't have that rule...

[Bug libstdc++/91243] is_invocable mishandles functions returning indestructible types by value

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
Well, this is a library bug report, not a compiler one...

[Bug c++/93420] New: Deducing "T C::* const&" from a non-const pointer-to-member-function fails

[rs2740 at gmail dot com]

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

Bug ID: 93420
   Summary: Deducing "T C::* const&" from a non-const
pointer-to-member-function fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

struct S {};

template
void check(T C::* const&);

int (S::*f)();

using t = decltype(check(f));

Rejected by GCC:

:8:27: error: no matching function for call to 'check(int (S::*&)())'

8 | using t = decltype(check(f));

  |   ^

:4:6: note: candidate: 'template void check(T C::*
const&)'

4 | void check(T C::* const&);

  |  ^

:4:6: note:   template argument deduction/substitution failed:

:8:27: note:   types 'T C::* const' and 'int (S::*)()' have
incompatible cv-qualifiers

8 | using t = decltype(check(f));

  |   ^

This appears to be the cause of PR69243, which was worked around in the
library.

[Bug c++/86238] No diagnostic for virtual base class with inaccessible destructor

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
Dup of bug 55120?

[Bug libstdc++/92978] New: std::gcd mishandles mixed-signedness

[rs2740 at gmail dot com]

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

Bug ID: 92978
   Summary: std::gcd mishandles mixed-signedness
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

From https://stackoverflow.com/q/59379703/2756719; the current gcd
implementation is essentially

  template
constexpr common_type_t<_Mn, _Nn>
__gcd(_Mn __m, _Nn __n)
{
  return __m == 0 ? __detail::__abs_integral(__n)
: __n == 0 ? __detail::__abs_integral(__m)
: __detail::__gcd(__n, __m % __n);
}

__m % __n generally does the wrong thing if one of the operands is negative and
signed and the other operand is unsigned. E.g., -120 % 10u is 6u, rather than
zero.

[Bug libstdc++/91653] ostream::operator<<(streambuf*) should fail the ostream when write output stream error but not

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
Looks NAD to me.

http://eel.is/c++draft/ostream.inserters#8.2 doesn't say that we set any bit in
that case. Contrast with http://eel.is/c++draft/ostream.unformatted#3 and
http://eel.is/c++draft/ostream.unformatted#5.2

[Bug libstdc++/91488] New: [9/10 Regression] char_traits::length causes "inlining failed in call to always_inline" error with -fgnu-tm -O2 -std=c++17

[rs2740 at gmail dot com]

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

Bug ID: 91488
   Summary: [9/10 Regression] char_traits::length causes "inlining
failed in call to always_inline" error with -fgnu-tm
-O2 -std=c++17
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro (https://gcc.godbolt.org/z/RO-2Ec):

#include 

int main() {
auto z = std::char_traits::length("");
}

$ g++ -fgnu-tm -O2 -std=c++17

In file included from
/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/string:40,

 from :1:

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:
In static member function 'static constexpr std::size_t
std::char_traits::length(const char_type*)':

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:231:5:
error: inlining failed in call to 'always_inline' 'constexpr bool
std::__constant_string_p(const _CharT*) [with _CharT = char]': 

  231 | __constant_string_p(const _CharT* __s)

  | ^~~

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:332:25:
note: called from here

  332 |  if (__constant_string_p(__s))

  |  ~~~^

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:231:5:
error: inlining failed in call to 'always_inline' 'constexpr bool
std::__constant_string_p(const _CharT*) [with _CharT = char]': 

  231 | __constant_string_p(const _CharT* __s)

  | ^~~

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:332:25:
note: called from here

  332 |  if (__constant_string_p(__s))

  |  ~~~^

[Bug libstdc++/91243] New: is_invocable mishandles functions returning indestructible types by value

[rs2740 at gmail dot com]

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

Bug ID: 91243
   Summary: is_invocable mishandles functions returning
indestructible types by value
   Product: gcc
   Version: 10.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 

struct S { friend struct F; protected: ~S(); };
struct F { S operator()() { return {}; } };

static_assert(!std::is_invocable_v); // fires

The condition for is_invocable is

> The expression INVOKE(declval(), declval()...) is well-formed
> when treated as an unevaluated operand

This expression is not well-formed when treated as a normal unevaluated
operand. It's only well-formed when it's the operand of decltype, due to the
special rule in [dcl.type.decltype]p2.

libc++ hard errors for this case. MSVC accepts the snippet above.

[Bug c++/89024] [7/8/9 Regression] ICE testing convertibility of incomplete enumeration types

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
Bah, must have copy-pasta'd the semicolon somewhere when reducing the original
and didn't notice :(

[Bug c++/89025] New: Wrong point of declaration for enumeration names

[rs2740 at gmail dot com]

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

Bug ID: 89025
   Summary: Wrong point of declaration for enumeration names
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Per [basic.scope.pdecl]/3,

> The point of declaration for an enumeration is immediately after 
> the identifier (if any) in either its enum-specifier ([dcl.enum])
> or its first opaque-enum-declaration ([dcl.enum]), whichever comes first.

GCC appears to treat the enumeration as undeclared until after the enum-base:

template using int_ = int;

enum E : int_ {}; // should be OK, but error

using E1 = long;

namespace {
enum E1 : E1 {}; // should be error, but accepted
}

[Bug c++/89024] New: ICE testing convertibility of incomplete enumeration types

[rs2740 at gmail dot com]

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

Bug ID: 89024
   Summary: ICE testing convertibility of incomplete enumeration
types
   Product: gcc
   Version: 9.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:

template T&& declval();

template
void __test_aux(_To1);

template(declval<_From1>()))>
char __test(int);

template
int __test(...);

enum E {
x = decltype(__test(0))(0);
};

prog.cc: In substitution of 'template char
__test(int) [with _From1 = E; _To1 = int;  =
]':
prog.cc:14:34:   required from here
prog.cc:7:45: internal compiler error: Segmentation fault
7 | typename = decltype(__test_aux<_To1>(declval<_From1>()))>
  | ^~~
0xb80c8f crash_signal
../../source/gcc/toplev.c:326
0x61d43e type_promotes_to(tree_node*)
../../source/gcc/cp/cvt.c:1916
0x5df449 standard_conversion
../../source/gcc/cp/call.c:1418
0x5e541b implicit_conversion
../../source/gcc/cp/call.c:1865
0x5e664a add_function_candidate
../../source/gcc/cp/call.c:2255
0x5e7045 add_template_candidate_real
../../source/gcc/cp/call.c:3284
0x5e7574 add_template_candidate
../../source/gcc/cp/call.c:3325
0x5e7574 add_candidates
../../source/gcc/cp/call.c:5618
0x5e7933 add_candidates
../../source/gcc/cp/call.c:4284
0x5e7933 perform_overload_resolution
../../source/gcc/cp/call.c:4292
0x5eb045 build_new_function_call(tree_node*, vec**, int)
../../source/gcc/cp/call.c:4366
0x6fd760 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../source/gcc/cp/semantics.c:2568
0x6d43ed tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:18874
0x6dbd8c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:14991
0x6dbd8c tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:14991
0x6e8ff2 type_unification_real
../../source/gcc/cp/pt.c:20874
0x6e9b80 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../source/gcc/cp/pt.c:20066
0x5e6e20 add_template_candidate_real
../../source/gcc/cp/call.c:3240
0x5e7574 add_template_candidate
../../source/gcc/cp/call.c:3325
0x5e7574 add_candidates
../../source/gcc/cp/call.c:5618
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++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

[rs2740 at gmail dot com]

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

--- Comment #4 from TC  ---
[dcl.enum]p4:

The underlying type can be explicitly specified using an enum-base. For a
scoped enumeration type, the underlying type is int if it is not explicitly
specified. In both of these cases, the underlying type is said to be fixed.

p8:

For an enumeration whose underlying type is fixed, the values of the
enumeration are the values of the underlying type.

[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
A variable of scoped enumeration type can hold any value of its underlying type
(int in this case) and is not limited to the value of the enumerators. 

The warning seems reasonable.

[Bug libstdc++/85183] New: [8 Regression] std::variant move assignment mishandles move-only types

[rs2740 at gmail dot com]

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

Bug ID: 85183
   Summary: [8 Regression] std::variant move assignment mishandles
move-only types
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro:
#include 

struct moveonly {
moveonly() noexcept { }
moveonly(moveonly&&) noexcept { }
moveonly& operator=(moveonly&&) noexcept { return *this; } 
~moveonly() { }
};


void test() {
std::variant m1, m2;
m1 = std::move(m2);
}

Compiles with 7. Breaks with 8:

In file included from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/8.0.1/variant: In instantiation of 'void
std::__detail::__variant::__erased_assign(void*, void*) [with _Lhs = moveonly&;
_Rhs = const moveonly&]':
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:607:27:   required from
'std::__detail::__variant::_Move_assign_base<, _Types>&
std::__detail::__variant::_Move_assign_base<,
_Types>::operator=(std::__detail::__variant::_Move_assign_base<,
_Types>&&) [with bool  = false; _Types = {moveonly}]'
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:648:12:   required from here
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:258:42: error: use of deleted
function 'constexpr moveonly& moveonly::operator=(const moveonly&)'
   __variant::__ref_cast<_Lhs>(__lhs) = __variant::__ref_cast<_Rhs>(__rhs);
   ~~~^~~~
prog.cc:3:8: note: 'constexpr moveonly& moveonly::operator=(const moveonly&)'
is implicitly declared as deleted because 'moveonly' declares a move
constructor or move assignment operator
 struct moveonly {
^~~~
In file included from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/8.0.1/variant: In instantiation of 'void
std::__detail::__variant::__erased_ctor(void*, void*) [with _Lhs = moveonly&;
_Rhs = const moveonly&]':
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:468:30:   required from
'std::__detail::__variant::_Copy_ctor_base<,
_Types>::_Copy_ctor_base(const
std::__detail::__variant::_Copy_ctor_base<, _Types>&) [with bool
 = false; _Types = {moveonly}]'
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:509:7:   required from
'std::__detail::__variant::_Move_assign_base<, _Types>&
std::__detail::__variant::_Move_assign_base<,
_Types>::operator=(std::__detail::__variant::_Move_assign_base<,
_Types>&&) [with bool  = false; _Types = {moveonly}]'
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:648:12:   required from here
/opt/wandbox/gcc-head/include/c++/8.0.1/variant:246:7: error: use of deleted
function 'constexpr moveonly::moveonly(const moveonly&)'
   ::new (__lhs) _Type(__variant::__ref_cast<_Rhs>(__rhs));
   ^~~
prog.cc:3:8: note: 'constexpr moveonly::moveonly(const moveonly&)' is
implicitly declared as deleted because 'moveonly' declares a move constructor
or move assignment operator
 struct moveonly {


There are two bugs in the move assignment operator of _Move_assign_base primary
template, presumably caused by copy-paste:
* in the matching index case, it uses __erased_assign<_Types&, const _Types&>
when it should be using __erased_assign<_Types&, _Types&&>.
* in the mismatched index case, it copies __rhs to create __tmp
(`_Move_assign_base __tmp(__rhs);`) when it should have moved from it.

[Bug c++/84689] is_invocable is true even for call operator via ambiguous base

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
With library dependency removed:

struct base {
void operator()(int ) { }
};

struct a : base { };
struct b : base { };

struct f: a, b {
using a::operator();
using b::operator();
};

template auto g(int) -> decltype(T()(0), 0);
template auto g(...) -> long;

template<class, class> struct Same;
template struct Same<T, T> {};

Same<decltype(g(0)), long> s;

Accepted by clang, rejected by gcc, who thinks that decltype(g(0)) is int.

[Bug libstdc++/84532] New: [7/8 Regression] std::thread::__make_invoker prematurely unwraps reference_wrappers

[rs2740 at gmail dot com]

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

Bug ID: 84532
   Summary: [7/8 Regression] std::thread::__make_invoker
prematurely unwraps reference_wrappers
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

std::thread::__make_invoker uses make_tuple, which unwraps reference_wrappers,
so instead of passing a DECAY_COPY'd reference_wrapper rvalue to __invoke,
it (incorrectly) passes a T lvalue instead.

This means that we accept invalid code like

int i = 0;
std::thread t([](auto&){}, std::ref(i));

It's not too hard to come up with code that changes meaning and valid code that
gets rejected either.

This is a 7/8 regression: previously the now-removed __bind_simple was used,
which correctly just does a simple decay.

[Bug libstdc++/83833] New: chi_squared_distribution::param() forgot to change the member gamma_distribution

[rs2740 at gmail dot com]

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

Bug ID: 83833
   Summary: chi_squared_distribution::param() forgot to change the
member gamma_distribution
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

From https://stackoverflow.com/q/48248565/2756719.

The constructor initializes _M_gd with (__n / 2), but param(const param_type&)
forgot to change it:

  void
  param(const param_type& __param)
  { _M_param = __param; }

[Bug libstdc++/83830] New: has_unique_object_representations_v is missing

[rs2740 at gmail dot com]

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

Bug ID: 83830
   Summary: has_unique_object_representations_v is missing
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

libstdc++ has the trait but not the _v form, which was added by the editor per
NB comment US-9 on the C++17 CD, see
https://github.com/cplusplus/draft/commit/97058f9cc925cd9a9e818545cad4e1c198d714cb.

[Bug c++/83181] [C++17] Invalid deduction guide accepted

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
What's happening here is that a deduction failure occurs with the deduction
guide (substitution yields a template non-type parameter of type void whose
argument also can't be deduced) and so it is eliminated from the overload set,
but there's still an implicit guide generated from the constructor and the
deduction is done from that.

[temp.param]/15 proscribes deduction guide templates with a template parameter
that neither is deducible nor has a default argument, so this should be
diagnosed.

[Bug libstdc++/83306] New: filesystem_error is not nothrow copyable

[rs2740 at gmail dot com]

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

Bug ID: 83306
   Summary: filesystem_error is not nothrow copyable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Since it stores two paths and a string directly as members. 

This violates [exception]/2:

Each standard library class T that derives from class exception shall have a
publicly accessible copy constructor and a publicly accessible copy assignment
operator that do not exit with an exception.

[Bug c++/82125] New: Suboptimal error message for range-based for

[rs2740 at gmail dot com]

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

Bug ID: 82125
   Summary: Suboptimal error message for range-based for
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

void meow() {
   int a[3][4];
   for(const auto r : a)
for(auto e : r) {}
}

This emits

prog.cc: In function 'void meow()':
prog.cc:4:22: error: 'begin' was not declared in this scope
 for(auto e : r) {}
  ^
prog.cc:4:22: error: 'end' was not declared in this scope

which, while not inaccurate, isn't helpful either. There is literally no scope
in which begin/end can be looked up, because int* has no associated namespace
whatsoever.

Moreover, if some begin/end is around - say, via #include  - then we
get a list of "suggested alternatives". But that seems even less helpful since
the form of the call is hard-coded in the language and isn't something the
programmer has any control over.

[Bug c++/57170] No diagnostic for a negative case when switching over unsigned

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
As comment #0 alluded to - perhaps a bit opaquely - this code is ill-formed in
C++11 and later. [stmt.switch] requires the case expression to be "a converted
constant expression ([expr.const]) of the promoted type of the switch
condition", and a narrowing conversion cannot be used in a converted constant
expression. The standard requires a diagnostic, which GCC fails to provide even
with -pedantic.

(Meanwhile, using unsigned char or unsigned short there is actually well-formed
if they get promoted to int as they usually do.)

So, unless you are saying that GCC's full conformance mode requires
-Wsign-conversion, I don't see how this bug is invalid.

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Why is this tagged ice-on-invalid? The test case is valid C++14.

[Bug libstdc++/81950] _GLIBCXX17_INLINE macro not used consistently

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
Unless I'm mistaken, the practice is to use _GLIBCXX17_INLINE on things in C++
<= 14 that are newly made inline in C++17. in_place is new in C++17.

[Bug libstdc++/81857] istreambuf_iterator not work as input iterator

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
istreambuf_iterator is specified to call sbumpc() only on increment, not upon
construction; the implementation is as specified.

The copy_n aspect is https://cplusplus.github.io/LWG/issue2471.

[Bug c++/81911] Constant expression from permitted result of a constant expression is not constexpr

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
The full-expression of the initialization of c0 includes the lvalue-to-rvalue
conversion on someVar[0], which is not allowed in a core constant expression;
see [expr.const]/2.7. Note that [expr.const]/2.7.1 only applies to complete
objects, which someVar[0] is not (it's a subobject).

[Bug c++/81398] Complaining about 'partial specialization of '...' after instantiation' in c++1z

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is the result of DR 150/P0522R0.

[Bug c++/81750] Calling generic lambda with no parameter fails to compile

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is bug 64095.

[Bug libstdc++/81669] trunk/gcc/fibonacci_heap.h:58: possible missing initialisation ?

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is not libstdc++.

[Bug libstdc++/81263] Work around CWG issue 1558 (guarantee SFINAE when using `void_t`)

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
This is not DR1558; the issue here is declaration matching rather than SFINAE.
Just having the two func definitions is sufficient to trigger the error:

template using void_t = void;

template * = nullptr>
void func() {}
template * = nullptr>
void func() {}

This is actually CWG 1980.

[Bug libstdc++/81076] New: __byte_operand is not SFINAE-friendly

[rs2740 at gmail dot com]

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

Bug ID: 81076
   Summary: __byte_operand is not SFINAE-friendly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Because the primary template is left undefined, the cv specializations of
__byte_operand causes a hard error for nonintegral types:

#include 

template void to_integer(...);

using t = decltype(to_integer<void* const>(std::byte{}));
using t = void;

[Bug c++/58820] lambda multiple inheritance operator() not ambiguous

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
This should be closed as invalid. The lookup for `operator()` is indeed
ambiguous, (see [class.member.lookup]/6 - the merge produces an invalid set),
and GCC correctly reports it as such.

In the absence of using-declarations, names from different base classes don't
overload.

[Bug c++/80951] New: Deducing noexcept only works when also deducing something else

[rs2740 at gmail dot com]

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

Bug ID: 80951
   Summary: Deducing noexcept only works when also deducing
something else
   Product: gcc
   Version: 7.1.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: ---

Another issue (compare bug 80384 and bug 80908) with the extension making
noexcept(E) to be a deduced context
(https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00665.html).

The following works:

void f() noexcept;

template
void g(R (*)() noexcept(E));

using t1 = decltype(g(f)); // OK

But not when the only thing being deduced is E:

template
void h(void (*)() noexcept(E));

using t2 = decltype(h(f)); // error

:12:24: error: no matching function for call to 'h(void (&)()
noexcept)'
 using t2 = decltype(h(f)); // error
^
:10:6: note: candidate: 'template void h(void (*)() noexcept
(E))'
 void h(void (*)() noexcept(E));
  ^
:10:6: note:   template argument deduction/substitution failed:
:12:24: note:   couldn't deduce template parameter 'E'
 using t2 = decltype(h(f)); // error
^
:12:24: error: no matching function for call to 'h(void (&)()
noexcept)'
:10:6: note: candidate: 'template void h(void (*)() noexcept
(E))'
 void h(void (*)() noexcept(E));
  ^
:10:6: note:   template argument deduction/substitution failed:
:12:24: note:   couldn't deduce template parameter 'E'
 using t2 = decltype(h(f)); // error
^

[Bug libstdc++/80939] New: Various helper function templates in incorrectly marked constexpr

[rs2740 at gmail dot com]

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

Bug ID: 80939
   Summary: Various helper function templates in 
incorrectly marked constexpr
   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: ---

No specialization of the following helper function templates can meet the
constexpr function requirements, and therefore they should not be marked
constexpr:

__erased_ctor (contains a new-expression)
__erased_dtor (evaluates either a pseudodestructor call or an actual destructor
call, which is a call to a non-constexpr function)

The following are technically valid - because __ref_cast is subject to ADL -
but in reality can never be constexpr anyway and so probably shouldn't be
marked constexpr:

__erased_assign
__erased_swap
__erased_hash

[Bug c++/80908] [c++1z] ICE on instantiating a template deducing the noexcept-ness of a function pointer

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
Also bug 80384. This is apparently an extension intended to be supported.

[Bug c++/80795] Cannot take the address of call operator of a variadic lambda when parameter pack length differs from 1

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Yet another dup of bug 64095.

[Bug c++/80767] Eager instantiation of generic lambda body when not required

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is another manifestation of bug 71117.

[Bug c++/80737] variant as class member resulting to compile errors

[rs2740 at gmail dot com]

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

--- Comment #5 from TC  ---
(In reply to Tim Shen from comment #3)
> (In reply to TC from comment #1)
> > Looks like the constraint on the convert-everything constructor needs to
> > check for is_same, variant> first and short circuit if that's
> > true.
> 
> I'm not quite sure whether we need that short circuit - it's in a SFINAE
> environment, so if anything goes wrong, there shouldn't be a hard error.
> Therefore even if I agree that we should check is_same,
> variant> first, that shouldn't affect the correctness.

I'm not sure I agree. As http://stackoverflow.com/a/43963065/2756719 points
out, when you attempt to copy a variant, as part of overload resolution
the code attempts to check if you can convert a variant to any; that in
turn queries whether variant is copy constructible, and we are very close
to turtling all the way down.

It does seem like there might be a frontend problem here, though.

[Bug c++/80736] Wrong overload picked with uniform initialization

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is correct behavior after DR 2137 backed out the relevant portions of DR
1467.

[Bug libstdc++/80737] variant as class member resulting to compile errors

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
#include 
#include 

std::variant a, b(a);

In file included from main.cpp:1:0:
/usr/local/include/c++/7.1.0/variant: In instantiation of 'struct
std::__detail::__variant::__accepted_index<std::variant&,
std::variant, void>':
/usr/local/include/c++/7.1.0/variant:911:26:   required from 'constexpr const
size_t std::variant::__accepted_index<std::variant&>'
/usr/local/include/c++/7.1.0/variant:940:6:   required by substitution of
'template constexpr std::variant::variant(_Tp&&)
[with _Tp = std::variant&;  = ]'
main.cpp:4:30:   required from here
/usr/local/include/c++/7.1.0/variant:559:49: error: no matching function for
call to
'std::__detail::__variant::__overload_set::_S_fun(std::variant&)'
   decltype(__overload_set<_Types...>::_S_fun(std::declval<_Tp>()),
~^
/usr/local/include/c++/7.1.0/variant:541:58: note: candidate: static
std::integral_constant
std::__detail::__variant::__overload_set<_First, _Rest ...>::_S_fun(_First)
[with _First = std::any; _Rest = {}]
   static integral_constant<size_t, sizeof...(_Rest)> _S_fun(_First);
  ^~
/usr/local/include/c++/7.1.0/variant:541:58: note:   no known conversion for
argument 1 from 'std::variant' to 'std::any'
/usr/local/include/c++/7.1.0/variant:535:19: note: candidate: static void
std::__detail::__variant::__overload_set<_Types>::_S_fun() [with _Types = {}]
 { static void _S_fun(); };
   ^~
/usr/local/include/c++/7.1.0/variant:535:19: note:   candidate expects 0
arguments, 1 provided
/usr/local/include/c++/7.1.0/variant:559:49: error: no matching function for
call to
'std::__detail::__variant::__overload_set::_S_fun(std::variant&)'
   decltype(__overload_set<_Types...>::_S_fun(std::declval<_Tp>()),
~^
/usr/local/include/c++/7.1.0/variant:541:58: note: candidate: static
std::integral_constant
std::__detail::__variant::__overload_set<_First, _Rest ...>::_S_fun(_First)
[with _First = std::any; _Rest = {}]
   static integral_constant<size_t, sizeof...(_Rest)> _S_fun(_First);
  ^~
/usr/local/include/c++/7.1.0/variant:541:58: note:   no known conversion for
argument 1 from 'std::variant' to 'std::any'
/usr/local/include/c++/7.1.0/variant:535:19: note: candidate: static void
std::__detail::__variant::__overload_set<_Types>::_S_fun() [with _Types = {}]
 { static void _S_fun(); };
   ^~
/usr/local/include/c++/7.1.0/variant:535:19: note:   candidate expects 0
arguments, 1 provided
/usr/local/include/c++/7.1.0/variant:559:49: error: no matching function for
call to
'std::__detail::__variant::__overload_set::_S_fun(std::variant&)'
   decltype(__overload_set<_Types...>::_S_fun(std::declval<_Tp>()),
~^
/usr/local/include/c++/7.1.0/variant:541:58: note: candidate: static
std::integral_constant
std::__detail::__variant::__overload_set<_First, _Rest ...>::_S_fun(_First)
[with _First = std::any; _Rest = {}]
   static integral_constant<size_t, sizeof...(_Rest)> _S_fun(_First);
  ^~
/usr/local/include/c++/7.1.0/variant:541:58: note:   no known conversion for
argument 1 from 'std::variant' to 'std::any'
/usr/local/include/c++/7.1.0/variant:535:19: note: candidate: static void
std::__detail::__variant::__overload_set<_Types>::_S_fun() [with _Types = {}]
 { static void _S_fun(); };
   ^~
/usr/local/include/c++/7.1.0/variant:535:19: note:   candidate expects 0
arguments, 1 provided
/usr/local/include/c++/7.1.0/variant: In instantiation of 'constexpr const
size_t std::__detail::__variant::__accepted_index<std::variant&,
std::variant, void>::value':
/usr/local/include/c++/7.1.0/variant:911:26:   required from 'constexpr const
size_t std::variant::__accepted_index<std::variant&>'
/usr/local/include/c++/7.1.0/variant:940:6:   required by substitution of
'template constexpr std::variant::variant(_Tp&&)
[with _Tp = std::variant&;  = ]'
main.cpp:4:30:   required from here
/usr/local/include/c++/7.1.0/variant:564:12: error: no matching function for
call to
'std::__detail::__variant::__overload_set::_S_fun(std::variant&)'
  - decltype(__overload_set<_Types...>::
 ~~~
  _S_fun(std::declval<_Tp>()))::value

[Bug c++/80670] Member specialization of alias declaration from different namespace

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
namespace A {
template class X { struct P; };
}

namespace B {
using Y = A::X;
}

namespace A {
template<> struct B::Y::P {};
}

main.cpp:10:29: error: declaration of 'struct A::X::P' in namespace 'A'
which does not enclose 'using Y = class A::X'
 template<> struct B::Y::P {};

[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
(In reply to Eric Fiselier from comment #3)
> Here is an example of why `_Bind::operator()(...) const` must be considered
> during overload resolution even if the call wrapper itself is not const.
> 
> --
> #include 
> 
> struct Func {
>   template 
>   void operator()(Args&&...) = delete;
> 
>   template 
>   void operator()(Args&&...) const {}
> };
> 
> int main() {
> Func f;
> std::bind(f)();
> }
> -

Interesting, libstdc++ rejects this as an attempt to call a deleted function.
That seems more correct than libc++'s approach which calls the const overload.

[Bug c++/80427] New: DR1658 is implemented in C++03 and C++14 mode, but not C++11

[rs2740 at gmail dot com]

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

Bug ID: 80427
   Summary: DR1658 is implemented in C++03 and C++14 mode, but not
C++11
   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: ---

Trunk GCC accepts this code given -std=c++03 or -std=c++14:

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

struct B : public virtual A {
virtual void foo() = 0;
};

struct C : public B {
C() : A(1) {}
virtual void foo()  {}
};

int main() {
C c;
return 0;
}

but rejects it with -std=c++11. 

This doesn't make much sense.

[Bug c++/80384] New: ICE when deducing noexcept in class template partial specialization

[rs2740 at gmail dot com]

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

Bug ID: 80384
   Summary: ICE when deducing noexcept in class template partial
specialization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00665.html "allow[ed]
noexcept(E) to be a deduced context in order to avoid another factor
of two expansion in the partial specializations of is_function."

The following causes an ICE with Wandbox's GCC 7
(https://wandbox.org/permlink/LacBOL6M17og9ZF9):

template struct foo;
template
struct foo<int() noexcept(B)> {
static const bool value = true; 
};

static_assert(!foo<int()>::value);

prog.cc: In instantiation of 'struct foo<int()>':
prog.cc:7:26:   required from here
prog.cc:4:23: internal compiler error: in finish_member_declaration, at
cp/semantics.c:2963
 static const bool value = true;
   ^
0x681eb2 finish_member_declaration(tree_node*)
../../source/gcc/cp/semantics.c:2963
0x5f1f3a instantiate_class_template_1
../../source/gcc/cp/pt.c:10581
0x5f1f3a instantiate_class_template(tree_node*)
../../source/gcc/cp/pt.c:10798
0x654435 complete_type(tree_node*)
../../source/gcc/cp/typeck.c:133
0x63c032 cp_parser_nested_name_specifier_opt
../../source/gcc/cp/parser.c:6153
0x63ee02 cp_parser_simple_type_specifier
../../source/gcc/cp/parser.c:16826
0x635d78 cp_parser_postfix_expression
../../source/gcc/cp/parser.c:6699
0x63694d cp_parser_unary_expression
../../source/gcc/cp/parser.c:8103
0x637703 cp_parser_cast_expression
../../source/gcc/cp/parser.c:8781
0x6369b5 cp_parser_unary_expression
../../source/gcc/cp/parser.c:8021
0x637703 cp_parser_cast_expression
../../source/gcc/cp/parser.c:8781
0x637e77 cp_parser_binary_expression
../../source/gcc/cp/parser.c:8882
0x638524 cp_parser_assignment_expression
../../source/gcc/cp/parser.c:9169
0x638907 cp_parser_constant_expression
../../source/gcc/cp/parser.c:9439
0x638a38 cp_parser_static_assert
../../source/gcc/cp/parser.c:13589
0x64afae cp_parser_block_declaration
../../source/gcc/cp/parser.c:12599
0x629504 cp_parser_declaration
../../source/gcc/cp/parser.c:12500
0x64f25b cp_parser_declaration_seq_opt
../../source/gcc/cp/parser.c:12376
0x64f542 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4366
0x64f542 c_parse_file()
../../source/gcc/cp/parser.c:38427
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++/80273] New: cv-qualified auto with trailing return type incorrectly accepted

[rs2740 at gmail dot com]

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

Bug ID: 80273
   Summary: cv-qualified auto with trailing return type
incorrectly accepted
   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: ---

GCC incorrectly accepts

auto const meow() -> int;

[dcl.fct]/2 says only plain 'auto' is allowed.

Possibly related to bug 67012.

[Bug c++/66477] [constexpr] accepts-invalid with constexpr member call on non-constant reference

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
Seems to have something to do with reference-type parameters.

  struct a { constexpr int size() const { return 3; } };
  constexpr bool g(a&) { return true;}
  void f(a ) { 
static_assert(r.size() == 3, "error"); // accepted
static_assert(g(r), "");   // likewise
a& rr = r;
static_assert(g(rr), "");  // rejected
static_assert(rr.size()==3, "");   // likewise
  }