[Bug c++/95153] Arrays of 'const void *' should not be copyable in C++20
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 &a[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 &a[0] is a void* const*; converting that to void* is not allowed because it casts away constness.
[Bug libstdc++/93983] std::filesystem::path is not concept-friendly
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 libstdc++/95282] New: atomic::load in C++20 calls __atomic_load with a pointer-to-const as the output
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++/95904] New: Improve the diagnostic for conflicting return types in std::visit
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 c++/96078] New: [10/11 Regression] flatten attribute on constructor and destructor causes spurious warning
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++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!
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++/96331] Class template argument deduction (CTAD) with Concepts
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++/97120] circular concept loops in
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 libstdc++/92978] New: std::gcd mishandles mixed-signedness
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 c++/86238] No diagnostic for virtual base class with inaccessible destructor
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 c++/93420] New: Deducing "T C::* const&" from a non-const pointer-to-member-function fails
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 libstdc++/91243] is_invocable mishandles functions returning indestructible types by value
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 libstdc++/91243] is_invocable mishandles functions returning indestructible types by value
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 c++/89024] New: ICE testing convertibility of incomplete enumeration types
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++/89025] New: Wrong point of declaration for enumeration names
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] [7/8/9 Regression] ICE testing convertibility of incomplete enumeration types
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++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return
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 c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return
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 libstdc++/91243] New: is_invocable mishandles functions returning indestructible types by value
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 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
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++/91653] ostream::operator<<(streambuf*) should fail the ostream when write output stream error but not
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 c++/83181] [C++17] Invalid deduction guide accepted
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++/83830] New: has_unique_object_representations_v is missing
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 libstdc++/83833] New: chi_squared_distribution::param() forgot to change the member gamma_distribution
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++/84532] New: [7/8 Regression] std::thread::__make_invoker prematurely unwraps reference_wrappers
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 c++/84689] is_invocable is true even for call operator via ambiguous base
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 struct Same;
template struct Same {};
Same(0)), long> s;
Accepted by clang, rejected by gcc, who thinks that decltype(g(0)) is int.
[Bug libstdc++/85183] New: [8 Regression] std::variant move assignment mishandles move-only types
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++/69515] New: partial specialization of variable templates is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69515
Bug ID: 69515
Summary: partial specialization of variable templates is broken
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Reduced from http://stackoverflow.com/q/35027853/2756719:
struct A { A(int = 0); };
template class meow;
template A foo;
template A foo> = 1;
auto&& a = foo>;
auto&& b = foo>;
Output:
/tmp/ccpeDea7.s: Assembler messages:
/tmp/ccpeDea7.s:24: Error: symbol `foo' is already defined
Additionally, attempting to explicitly instantiate 'foo' using the partial
specialization causes a bogus error:
template A foo; // OK
template A foo>; // Error
prog.cc:11:12: error: 'foo' is not a static data member of a class template
template A foo>;
^~
[Bug c++/69139] [4.9/5/6 Regression] deduction failure with trailing return type in function template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69139
--- Comment #3 from TC ---
Another test case, slightly modified from the original in the linked SO
question:
struct X {
auto get(int) const & -> int { return {}; }
auto get(int) && -> long { return {}; }
};
template auto f(auto (X::*)(int) const & -> R) -> R {}
using I = decltype(f(&X::get));
using I = int;
The fix needs to also handle the cv-qualifier-seq and ref-qualifier in the
function type, if any.
[Bug libstdc++/68515] std::result_of doesn't work when F is abstract (with pure virtual functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68515 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #3 from TC --- FWIW, I don't see a bug here. The note in [temp.deduct]/8 explicitly calls out "Attempting to create a function type in which a parameter type or the return type is an abstract class type" as a cause for deduction failure. What one plans to do with the type is irrelevant; deduction fails as soon as you attempt to form one. In any event, the only reason this is an issue for the original example is because it uses result_of incorrectly. The actual call is 'f(x[i])' - i.e., it is calling a const F lvalue with the result of vector's const operator[], which returns 'typename vector::const_reference' (which is const T& except for vector). The correct result_of invocation is therefore 'typename std::result_of::const_reference)>::type' (which should probably be then decayed since the example creates a vector of it).
[Bug c++/69778] New: Bogus "qualifiers cannot be applied" error with redundant (but legal) 'typename'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69778
Bug ID: 69778
Summary: Bogus "qualifiers cannot be applied" error with
redundant (but legal) 'typename'
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Modified repro from http://stackoverflow.com/q/35352168/2756719:
struct A {
typedef int& reference;
};
void f(const A::reference); // OK
void g(const typename A::reference); // error: 'const' qualifiers cannot be
// applied to 'A::reference {aka int&}'
[Bug c++/69774] Corrupted 'this' passed through lambda.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69774 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #2 from TC --- You have a dangling reference - the lambda in Thread's constructor captures `task` by reference, and in this case `task` is bound to the temporary object created by the lambda expression in A's constructor, which is immediately destroyed at the semicolon.
[Bug c++/67013] Compilation error for well-formed program with empty declaration in the global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #11 from TC --- This was not allowed in C++03, as there was no such thing as an empty-declaration. The production for simple-declaration would seem to accept ';', but it's banned by [dcl.dcl]/3 and /7. This was changed by http://wg21.link/cwg569.
[Bug libstdc++/70101] New: Allocator-extended priority_queue constructors are badly broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70101
Bug ID: 70101
Summary: Allocator-extended priority_queue constructors are
badly broken
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
None of them is implemented correctly, and several won't compile if actually
used.
template>
explicit
priority_queue(const _Alloc& __a)
: c(__a) { }
should be ": c(__a), comp()" (the standard says that it value-initializes
comp).
template>
priority_queue(const _Compare& __x, const _Alloc& __a)
: c(__x, __a) { }
should be ": c(__a), comp(__x)".
template>
priority_queue(const _Compare& __x, const _Sequence& __c,
const _Alloc& __a)
: c(__x, __c, __a) { }
should be ": c(__c, __a), comp(__x)", and per LWG 2537 should also call
std::make_heap.
template>
priority_queue(const _Compare& __x, _Sequence&& __c, const _Alloc& __a)
: c(__x, std::move(__c), __a) { }
should be ": c(std::move(__c), __a), comp(__x)", and per LWG 2537 should also
call std::make_heap.
template>
priority_queue(const priority_queue& __q, const _Alloc& __a)
: c(__q.c, __a) { }
should be ": c(__q.c, __a), comp(__q.comp)".
template>
priority_queue(priority_queue&& __q, const _Alloc& __a)
: c(std::move(__q.c), __a) { }
should be ": c(std::move(__q.c), __a), comp(std::move(__q.comp))".
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #6 from TC --- (In reply to Thomas Braun from comment #4) > (I'm no gcc dev at all) > > In general gcc is much better in doing NRVO/URVO than other compilers > according to my analysis [1]. So maybe the competitors need to get better > first ;) > > [1]: http://www.byte-physics.de/cpp-copy-elision The three cases (L, P, R) where GCC is "better" is actually non-conforming.
[Bug c++/53637] NRVO not applied where there are two different variables involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637 --- Comment #8 from TC --- The standard specifies when copy elision is allowed (http://eel.is/c++draft/class.copy#31). "return param ? a : b;" is not one of them. "param ? a : b" is hardly "the name of a non-volatile automatic object..."
[Bug c++/70383] New: Bogus error when attempting to capture a reference to function by copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70383
Bug ID: 70383
Summary: Bogus error when attempting to capture a reference to
function by copy
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Repro:
void meow() {
void purr();
void (&f)() = purr;
[f]{};
}
Per [expr.prim.lambda]/15, capturing a reference to a function by copy should
result in an unnamed data member that is also a reference to a function. GCC
instead complains:
prog.cc: In function 'void meow()':
prog.cc:4:6: error: field 'meow()' invalidly declared
function type
[f]{};
^
[Bug c++/70585] New: Bogus 'ambiguous template instantiation' error with partial specializations involving a pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70585
Bug ID: 70585
Summary: Bogus 'ambiguous template instantiation' error with
partial specializations involving a pack expansion
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Repro:
template class meow;
template struct purr;
template
struct purr...> {};
template
struct purr...> {};
template struct purr>;
gcc HEAD 6.0.0 20160407 (experimental) on Wandbox prints:
prog.cc:10:17: error: ambiguous template instantiation for 'struct purr >'
template struct purr>;
^~~~
prog.cc:6:8: note: candidates are: template struct
purr...> [with T = int; Ts = {int}]
struct purr...> {};
^~~~
prog.cc:8:8: note: template struct purr...> [with Ts = {int}]
struct purr...> {};
^~
prog.cc:10:17: error: explicit instantiation of 'struct purr >'
before definition of template
template struct purr>;
^~~~
Clang compiles this code.
[Bug c++/70587] New: 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70587
Bug ID: 70587
Summary: 0e1_p+0 should not be parsed as a single pp-number in
C++14 and earlier
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
p/P followed by +/- is not part of the pp-number production in C++ before
C++17, but GCC includes them anyway. This results in the following code being
erroneously rejected in C++11/14 mode:
long double operator""_p(long double) { return {}; }
auto x = 0e1_p+0; // should be parsed as 0e1_p + 0
// but parsed as a single pp-number instead and rejected
[Bug c++/70587] 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70587 TC changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|6.0 |5.3.0 Resolution|--- |FIXED --- Comment #3 from TC --- Bah, wrong version field. This should be against 5 (because I was using Coliru), but I neglected to test 6.
[Bug c++/70642] New: Invalid alias template instantiation not rejected if previously used in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70642
Bug ID: 70642
Summary: Invalid alias template instantiation not rejected if
previously used in SFINAE context
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Reduced from http://stackoverflow.com/q/36578055/2756719.
The following ill-formed code is incorrectly accepted by GCC:
template struct enable_if {};
template struct enable_if { using type = T; };
template
struct foo
{
template
using meow = typename enable_if::type;
template// 1
meow bar () = delete;
int bar ()
{
meow i; // 2
return 0; // 3
}
};
int j = foo().bar();
Attempting to use i (by changing line #3 to 'return i;') causes an ICE:
prog.cc: In instantiation of 'int foo::bar() [with X = long int]':
prog.cc:20:25: required from here
prog.cc:16:16: internal compiler error: in tsubst_copy, at cp/pt.c:14043
return i;
^
0x6019dd tsubst_copy
/home/heads/gcc/gcc-source/gcc/cp/pt.c:14041
0x602021 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16993
0x5fdcd8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15802
0x5fda06 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15114
0x5fd454 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15104
0x5fdb73 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15290
0x5fc36f instantiate_decl(tree_node*, int, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:22014
0x618c8b instantiate_pending_templates(int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:22131
0x636eed c_parse_final_cleanups()
/home/heads/gcc/gcc-source/gcc/cp/decl2.c:4599
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
The problem appears to only arise if the types in Lines #1 and #2 match (i.e.,
when the alias template has been instantiated in a SFINAE context already); if
either (but not both) is changed to, e.g., void, or if the first bar() overload
is removed, then the error is correctly diagnosed.
[Bug libstdc++/70472] is_copy_constructible>>::value is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #5 from TC --- In any event, it would be wrong to SFINAE on std::is_copy_constructible. The requirement is CopyInsertable, not CopyConstructible. The allocator's construct() can mutilate the constructor arguments to its heart's content before passing them on, and I don't see a way to check this.
[Bug c++/60799] access checking within injected friend functions does not happen in the context of the enclosing class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60799
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #4 from TC ---
(In reply to Casey Carter from comment #3)
> > I'm inclined to the second interpretation, which would imply the behavior
> > described in this bug report is what the standard intends.
>
> This is me stumbling over my words attempting to say "I think this is NOT a
> bug."
I don't think that reading makes much sense. Among member-declarations that do
not declare a member are static_assert-declarations and unnamed bit-field
declarations, so that reading disallows
class A {
constexpr static bool value = true;
friend class B;
};
class B {
static_assert(B::value, "");
};
And disallows D in the below example but not E:
class C {
constexpr static int value = 4;
friend class D;
friend class E;
};
class D {
int : C::value;
};
class E {
int i : C::value;
};
[Bug c++/70667] SFINAE error disambiguating using alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70667 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #1 from TC --- The error here (in the definition of `A`) certainly looks like it's outside the immediate context...?
[Bug libstdc++/70472] is_copy_constructible>>::value is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70472
--- Comment #7 from TC ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to TC from comment #5)
> > In any event, it would be wrong to SFINAE on
> > std::is_copy_constructible. The requirement is CopyInsertable,
> > not CopyConstructible. The allocator's construct() can mutilate the
> > constructor arguments to its heart's content before passing them on, and I
> > don't see a way to check this.
>
> has this:
>
> // true if _Alloc::value_type is CopyInsertable into containers using
> _Alloc
> template
> struct __is_copy_insertable
> : __is_copy_insertable_impl<_Alloc>::type
> { };
>
> But using it requires that std::vector::~vector() is defined as defaulted,
> which would not be a simple change.
>
> We used to use that for the unordered containers until r204790.
That also requires the allocator's `construct` be SFINAE-friendly. Most aren't.
[Bug libstdc++/70766] New: stream iterators, shared_lock, and atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70766 Bug ID: 70766 Summary: stream iterators, shared_lock, and atomic should all use addressof and not & Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- 1) istream_iterator and ostream_iterator's constructors and istream_iterator's operator-> should use __addressof (this is LWG issue 2576). 2) shared_lock's constructors should use addressof (LWG issue 2577). unique_lock's constructors already do that. 3) The primary atomic<_Tp> template uses & in many places where it should be using addressof.
[Bug c++/70796] New: [DR 1030] Initialization order with braced-init-lists still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796
Bug ID: 70796
Summary: [DR 1030] Initialization order with braced-init-lists
still broken
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
The following modified test case (replacing postfix ++ with prefix and
adjusting the expected values accordingly) from PR61382 still aborts on Wandbox
(http://melpon.org/wandbox/permlink/IQojTl16DtIxCd2M) and also gives a bogus
-Wsequence-point warning:
struct A
{
int i,j;
A(int i,int j):i(i),j(j){}
};
int main()
{
int i = 0;
A a{++i, ++i};
if (a.i != 1 || a.j != 2)
__builtin_abort();
}
[Bug libstdc++/70101] Allocator-extended priority_queue constructors are badly broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70101
--- Comment #1 from TC ---
Test case for everything except the first:
#include
#include
#include
#include
#include
struct Cmp : std::less {
explicit Cmp(int) {};
};
Cmp comp(1);
std::allocator alloc;
std::vector vec;
using PQ = std::priority_queue, Cmp>;
PQ pq2(comp, alloc);
PQ pq3(comp, vec, alloc);
PQ pq4(comp, std::move(vec), alloc);
PQ pq5(pq2, alloc);
PQ pq6(std::move(pq2), alloc);
[Bug c++/70942] [c++14] Incorrect deduction of generic lambda `auto&&` parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC ---
Reduced:
int main()
{
int x = 0;
[](auto&& xv){
static_cast(xv) = 1;
}(x);
}
OK on GCC 5. Fails with a bogus error on 6 and 7:
main.cpp: In instantiation of 'main():: [with auto:1 = int]':
main.cpp:5:17: required by substitution of 'template
main()operator decltype
(((main()::)0u).operator()(static_cast()))
(*)(auto:1&&)() const [with auto:1 = int]'
main.cpp:7:8: required from here
main.cpp:6:39: error: using xvalue (rvalue reference) as lvalue
static_cast(xv) = 1;
~~^~~
[Bug c++/70943] New: 'conflicting declaration' error with repeated typedefs in function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70943
Bug ID: 70943
Summary: 'conflicting declaration' error with repeated typedefs
in function templates
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
void foo(T t) {
using meow = T;
using meow = int;
}
template void foo(int);
Accepted by clang, rejected by GCC:
main.cpp: In function 'void foo(T)':
main.cpp:4:21: error: conflicting declaration 'using meow = '
using meow = int;
^
main.cpp:3:19: note: previous declaration as 'using meow = T'
using meow = T;
[Bug c++/70942] [6/7 Regression] [c++14] Incorrect deduction of generic lambda `auto&&` parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942 --- Comment #2 from TC --- This only appears to affect captureless generic lambdas with a deduced return type. It might have something to do with the conversion function template to function pointer - I'm guessing that it was somehow instantiated for the wrong template argument during overload resolution, which result in the lambda's body being instantiated with the wrong argument too (to deduce the return type), which triggers the error.
[Bug c++/70972] New: [6/7 Regression] Inheriting constructors taking parameters by value should move them, not copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70972
Bug ID: 70972
Summary: [6/7 Regression] Inheriting constructors taking
parameters by value should move them, not copy
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Keywords: rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
The following code, accepted by GCC 5.3, fails to compile in GCC 6.1 and 7:
struct moveonly {
moveonly(moveonly&&) = default;
moveonly() = default;
};
struct A {
A(moveonly) {}
};
struct B : A {
using A::A;
};
B b(moveonly{});
with a bogus error:
+ g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp
main.cpp: In constructor 'B::B(moveonly)':
main.cpp:10:14: error: use of deleted function 'constexpr
moveonly::moveonly(const moveonly&)'
using A::A;
^
main.cpp:1:8: note: 'constexpr moveonly::moveonly(const moveonly&)' is
implicitly declared as deleted because 'moveonly' declares a move constructor
or move assignment operator
struct moveonly {
^~~~
main.cpp: At global scope:
main.cpp:13:15: note: synthesized method 'B::B(moveonly)' first required here
B b(moveonly{});
Per N4140 [class.inhctor]/8, an implicitly defined inheriting constructor
should cast a passed-by-value parameter to an rvalue before forwarding it to
the base class constructor:
> Each expression in the expression-list [of the mem-initializer for the base
> class] is of the form static_cast(p), where p is the name of the
> corresponding constructor parameter and T is the declared type of p.
(The code above remains valid under the new inheriting constructor semantics in
P0136R1.)
However, GCC 6.1 looks for a copy constructor instead, and would call them
instead of move:
struct abort_on_copy{
abort_on_copy(abort_on_copy&&) = default;
abort_on_copy(const abort_on_copy&) { __builtin_abort(); }
abort_on_copy() = default;
};
struct A {
A(abort_on_copy) {}
};
struct B : A {
using A::A;
};
int main() {
B b(abort_on_copy{}); // aborts
}
[Bug c++/70972] [6/7 Regression] Inheriting constructors taking parameters by value should move them, not copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70972 --- Comment #1 from TC --- Originally from http://stackoverflow.com/q/37064993/2756719
[Bug c++/70972] [6/7 Regression] Inheriting constructors taking parameters by value should move them, not copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70972 --- Comment #2 from TC --- Not exactly that familiar with GCC, but looking at https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/method.c?r1=233719&r2=233718&pathrev=233719 tree type = TREE_TYPE (parm); if (DECL_PACK_P (parm)) type = PACK_EXPANSION_PATTERN (type); exp = build_static_cast (type, exp, tf_warning_or_error); This seems to do the equivalent of `static_cast(p)` (which is a copy) rather than the desired `static_cast(p)`. Consistent with this hypothesis, with -fno-elide-constructors, a copy constructor call is emitted *in addition to* a move constructor call (http://coliru.stacked-crooked.com/a/5dd154da9c26472f), rather than instead of one.
[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796 --- Comment #2 from TC --- It occurred to me that one issue here is whether initialization of the parameter object (of the constructor) is considered a "value computation [or] side effect associated with" an initializer-clause. If not, then the current behavior is correct - the increments are sequenced relative to each other but not to the initialization of the parameter objects (which reads from 'i').
[Bug c++/71099] New: Misleading diagnostic message with 'virtual' used in out-of-line definitions of class template member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71099
Bug ID: 71099
Summary: Misleading diagnostic message with 'virtual' used in
out-of-line definitions of class template member
functions
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
GCC correctly diagnoses the problem with this ill-formed code:
struct foo {
virtual void f();
};
virtual void foo::f() {}
+ g++ -std=c++14 -Wall -pedantic main.cpp
main.cpp:5:1: error: 'virtual' outside class declaration
virtual void foo::f() {}
^~~
But if `foo` is a template, the error message is significantly less helpful:
template
struct foo {
virtual void f();
};
template
virtual void foo::f() {}
+ g++ -std=c++14 -Wall -pedantic main.cpp
main.cpp:7:1: error: templates may not be 'virtual'
virtual void foo::f() {}
^~~
Clang correctly diagnoses the problem in both cases ("main.cpp:7:1: error:
'virtual' can only be specified inside the class definition").
[Bug c++/71332] Passing non-copyable type by reference to variadic generic lambda after a copyable type by value results in a compile-time error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71332 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #1 from TC --- Dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095. The ... is (incorrectly) being parsed as C-style varargs, which then triggers the error.
[Bug libstdc++/81669] trunk/gcc/fibonacci_heap.h:58: possible missing initialisation ?
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 c++/81750] Calling generic lambda with no parameter fails to compile
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 c++/81398] Complaining about 'partial specialization of '...' after instantiation' in c++1z
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++/81911] Constant expression from permitted result of a constant expression is not constexpr
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 libstdc++/81857] istreambuf_iterator not work as input iterator
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 libstdc++/81950] _GLIBCXX17_INLINE macro not used consistently
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 c++/81942] ICE on empty constexpr constructor with C++14
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 c++/57170] No diagnostic for a negative case when switching over unsigned
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++/82125] New: Suboptimal error message for range-based for
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 libstdc++/80564] bind on SFINAE unfriendly generic lambda
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++/80670] Member specialization of alias declaration from different namespace
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++/80737] variant as class member resulting to compile errors
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, void>':
/usr/local/include/c++/7.1.0/variant:911:26: required from 'constexpr const
size_t std::variant::__accepted_index&>'
/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 _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 _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 _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, void>::value':
/usr/local/include/c++/7.1.0/variant:911:26: required from 'constexpr const
size_t std::variant::__accepted_index&>'
/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::dec
[Bug c++/80736] Wrong overload picked with uniform initialization
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 c++/80737] variant as class member resulting to compile errors
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++/80767] Eager instantiation of generic lambda body when not required
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++/80795] Cannot take the address of call operator of a variadic lambda when parameter pack length differs from 1
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++/80908] [c++1z] ICE on instantiating a template deducing the noexcept-ness of a function pointer
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 libstdc++/80939] New: Various helper function templates in incorrectly marked constexpr
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++/80951] New: Deducing noexcept only works when also deducing something else
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 c++/58820] lambda multiple inheritance operator() not ambiguous
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 libstdc++/81076] New: __byte_operand is not SFINAE-friendly
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(std::byte{}));
using t = void;
[Bug libstdc++/81263] Work around CWG issue 1558 (guarantee SFINAE when using `void_t`)
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 c++/78693] New: [6/7 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693
Bug ID: 78693
Summary: [6/7 Regression] Bogus 'inconsistent deduction for
‘auto’' error when having a dependent initializer and
a nondependent one in the same declaration
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
void foo (T t) {
auto i = t, j = 1;
}
prog.cc: In function 'void foo(T)':
prog.cc:3:3: error: inconsistent deduction for 'auto': 'auto' and then 'int'
auto i = t, j = 1;
^~~~
Accepted by GCC 5.3, Clang, MSVC (CL 19 on gcc.beta.godbolt.org, whatever that
corresponds to) and ICC 17 (but with a bogus warning). Rejected by 6.1 and 7
(on Wandbox).
[Bug c++/78928] New: void(*); accepted in block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78928
Bug ID: 78928
Summary: void(*); accepted in block scope
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
From http://stackoverflow.com/q/41326047/2756719.
GCC accepts this plainly invalid code:
void f() {
void(*);
}
It appears that any combination of ptr-operators within the parentheses is
accepted as well.
[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78890 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #3 from TC --- [class.union]/3 in the current WP (/2 in N3337/N4140) says (among other things): If a union contains a non-static data member of reference type the program is ill-formed.
[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78890 --- Comment #5 from TC --- (In reply to Jakub Jelinek from comment #4) > Apparently what changed in C++11 is that it allows static > data members in unions and those clearly can have reference type, so that is > the reason why the restriction has been removed and nothing added the > restriction that non-static data members still may not have reference type. ...I quoted the part of the standard that says this is ill-formed in comment #3?
[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78890 --- Comment #7 from TC --- (In reply to Jakub Jelinek from comment #6) > Sure, I just wanted to understand why the r211318 change has been done and > my comment lists why I think that happened. Ah, my fault for not actually reading the patch. (FWIW, the sentence I quoted was introduced by the same paper that relaxed the static data member restrictions (N2544), so I'm not sure how that description makes sense, but certainly it appears that r211318's author somehow thought so - possibly due to paragraph numbering changes between C++03 and C++11?)
[Bug libstdc++/77528] std::queue default constructor unnecessarily creates temporary of underlying Container
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77528
--- Comment #10 from TC ---
C&P'ing the relevant parts of my email to the lists here for the record:
The new default member initializers use {}, and it's not too hard to find test
cases where {} and value-initialization do different things, including cases
where {} doesn't compile but () does. (So much for "uniform" initialization.)
> Because the default constructor is defined as defaulted it will be
> deleted when the underlying sequence isn't default constructible,
That's not correct. There's no implicit deletion due to the presence of DMIs.
The reason the explicit instantiation works is that constructors explicitly
defaulted at their first declaration are not implicitly defined until ODR-used.
So, unlike the SFINAE-based approach outlined in [comment #1], this patch
causes is_default_constructible> to trigger a
hard error (though the standard's version isn't SFINAE-friendly either).
[Bug libstdc++/77451] Cannot convert lambda [](auto&&...){} to std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77451
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC ---
This is not a libstdc++ bug. It's caused by GCC misparsing the ... in
[](auto&&...) {} (i.e., a dup of bug 64095).
Under the mistaken parse (which is equivalent to [](auto&&, ...) {}),
std::function's constructor correctly refuses to accept the lambda.
[Bug libstdc++/79195] New: make_array should not ask for common_type when the type is explicitly specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79195
Bug ID: 79195
Summary: make_array should not ask for common_type when the
type is explicitly specified
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
This does not compile:
#include
struct A {};
struct B : A {};
struct C : A {};
auto arr = std::experimental::make_array(B{}, C{});
because make_array's return type computes
conditional_t, common_type_t<_Types...>, _Dest>
which instantiates common_type_t and results in a substitution failure.
There shouldn't be a need to instantiate it when the desired element type is
explicitly specified.
[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79195
--- Comment #1 from TC ---
While we are here, the `return {{forward<_Types>(__t)...}};` in the body should
call std::forward qualified.
[Bug c++/70844] spurious -Wuseless-cast warning with inherited constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70844
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC ---
The attached test case doesn't reproduce in 6.2.0, presumably due to the fix
for 70972. The following (slightly modified) test case still produces a
-Wuseless-cast warning on trunk and 6.3.0:
struct base {
base (int const &);
};
struct derived : public base {
using base::base;
};
derived d(0);
What appears to be happening is that the inheriting constructor calls
forward_parm to perfectly forward the arguments, which in turn calls
build_static_cast to construct the equivalent of static_cast(p)
where p is of type const int &, which emits a -Wuseless-cast warning.
Consistent with this hypothesis, 6.1 emits a warning for the original test case
because it was emitting the equivalent of static_cast(p) where `p`'s type
is `int`; GCC >= 6.2, which has the 70972 fix, emits the equivalent of
static_cast(p), which doesn't trigger the warning. GCC < 6 doesn't have
forward_parm and doesn't unconditionally build a static_cast, so doesn't hit
this warning either.
[Bug c++/79549] New: ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79549
Bug ID: 79549
Summary: ICE in tsubst, at cp/pt.c:13474 with partial
specialization of auto... template parameter pack
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
struct meow;
template
struct meow { };
template struct meow<1>;
prog.cc: In substitution of 'template struct meow [with auto C =
1]':
prog.cc:7:17: required from here
prog.cc:7:17: internal compiler error: in tsubst, at cp/pt.c:13474
template struct meow<1>;
^~~
0x5d6a8c tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13474
0x5df37c tsubst_template_args
../../source/gcc/cp/pt.c:11638
0x5d5d5b tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13695
0x5d49f7 get_partial_spec_bindings
../../source/gcc/cp/pt.c:21511
0x5d4cbd most_specialized_partial_spec
../../source/gcc/cp/pt.c:21741
0x5ef83b instantiate_class_template_1
../../source/gcc/cp/pt.c:10183
0x5ef83b instantiate_class_template(tree_node*)
../../source/gcc/cp/pt.c:10751
0x652235 complete_type(tree_node*)
../../source/gcc/cp/typeck.c:133
0x5ead7b do_type_instantiation(tree_node*, tree_node*, int)
../../source/gcc/cp/pt.c:22011
0x64661f cp_parser_explicit_instantiation
../../source/gcc/cp/parser.c:16210
0x627581 cp_parser_declaration
../../source/gcc/cp/parser.c:12467
0x64d05b cp_parser_declaration_seq_opt
../../source/gcc/cp/parser.c:12391
0x64d342 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4366
0x64d342 c_parse_file()
../../source/gcc/cp/parser.c:38425
0x71b2a3 c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/79550] New: ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79550
Bug ID: 79550
Summary: ICE in tsubst, at cp/pt.c:13474 with partial
specialization of auto... template parameter pack
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
struct meow;
template
struct meow { };
template struct meow<1>;
prog.cc: In substitution of 'template struct meow [with auto C =
1]':
prog.cc:7:17: required from here
prog.cc:7:17: internal compiler error: in tsubst, at cp/pt.c:13474
template struct meow<1>;
^~~
0x5d6a8c tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13474
0x5df37c tsubst_template_args
../../source/gcc/cp/pt.c:11638
0x5d5d5b tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13695
0x5d49f7 get_partial_spec_bindings
../../source/gcc/cp/pt.c:21511
0x5d4cbd most_specialized_partial_spec
../../source/gcc/cp/pt.c:21741
0x5ef83b instantiate_class_template_1
../../source/gcc/cp/pt.c:10183
0x5ef83b instantiate_class_template(tree_node*)
../../source/gcc/cp/pt.c:10751
0x652235 complete_type(tree_node*)
../../source/gcc/cp/typeck.c:133
0x5ead7b do_type_instantiation(tree_node*, tree_node*, int)
../../source/gcc/cp/pt.c:22011
0x64661f cp_parser_explicit_instantiation
../../source/gcc/cp/parser.c:16210
0x627581 cp_parser_declaration
../../source/gcc/cp/parser.c:12467
0x64d05b cp_parser_declaration_seq_opt
../../source/gcc/cp/parser.c:12391
0x64d342 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4366
0x64d342 c_parse_file()
../../source/gcc/cp/parser.c:38425
0x71b2a3 c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/79549] ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79549 --- Comment #3 from TC --- -std=c++1z, of course. http://melpon.org/wandbox/permlink/kxNlvdtfvjCW5fNN
[Bug c++/78308] Hiding of member function templates introduced by using-decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78308
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC ---
A rejects-valid case:
struct C {
template void f();
};
struct D : C {
template void f();
using C::f;
};
int main(){
D().f<0>();
}
GCC rejects as ambiguous, Clang accepts as it only considers the template
one.
[Bug c++/66477] [constexpr] accepts-invalid with constexpr member call on non-constant reference
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 &r) {
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
}
[Bug c++/80273] New: cv-qualified auto with trailing return type incorrectly accepted
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++/80384] New: ICE when deducing noexcept in class template partial specialization
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 {
static const bool value = true;
};
static_assert(!foo::value);
prog.cc: In instantiation of 'struct foo':
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++/80427] New: DR1658 is implemented in C++03 and C++14 mode, but not C++11
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 libstdc++/83306] New: filesystem_error is not nothrow copyable
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 libstdc++/77528] std::queue default constructor unnecessarily creates temporary of underlying Container
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77528 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #2 from TC --- This makes the default constructor implicit, though that's probably how it should be anyway.
[Bug c++/77575] New: Bogus error when alias template yielding a reference type used as template template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77575
Bug ID: 77575
Summary: Bogus error when alias template yielding a reference
type used as template template argument
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Reduced from http://stackoverflow.com/q/39460120/2756719:
template class> struct meow {};
template using kitty = T&;
meow u;
results in the following bogus error:
prog.cc: In instantiation of 'struct meow':
prog.cc:4:13: required from here
prog.cc:1:46: error: type/value mismatch at argument 1 in template parameter
list for 'template class > struct meow'
template class> struct meow {};
^
prog.cc:1:46: note: expected a class template, got 'kitty'
prog.cc:1:46: error: type/value mismatch at argument 1 in template parameter
list for 'meow< >::meow'
prog.cc:1:46: note: expected a class template, got 'kitty'
It compiles fine if 'kitty' is instead defined as T or T*.
