[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80564 --- Comment #5 from r.hl at gmx dot net --- See also the discussion on Phabricator: https://reviews.llvm.org/D32824 I agree; AFAICS [func.bind.bind] is clear on this: the type of the Func object used to call the member operator() is non-const. On 5/4/2017 9:09 PM, rs2740 at gmail dot com wrote: > 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++/60705] New: alias template member access ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705 Bug ID: 60705 Summary: alias template member access ignored Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: R.HL at gmx dot net GCC simply ignores the fact, that a private member is inaccessible: class A { struct B {}; }; template using C = A::B; // Already the declaration of this alias template is ill-formed int main() { C c1; C c2; } This compiles without any warnings/errors using the GCC-4.9 snapshot from the 2nd march, and is obviously ill-formed (because access control applies to all names in all declarations, ยง11/4). There is AFAICS no exception for alias templates.
[Bug c++/60705] ill-formed member access in alias template ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705 --- Comment #2 from Robert Haberlach --- In this case the nested-name-specifier is not dependent upon any template argument. Thank you for the link, i didn't know that report yet.
[Bug c++/64428] New: aggregate with const member as union member [C++03]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64428 Bug ID: 64428 Summary: aggregate with const member as union member [C++03] Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: R.HL at gmx dot net struct A { const int b; }; union U { A a; }; int main() { U a = {1, 1}; } Fails to compile using -std=c++03, although it should. Consider that no special member function apart from the destructor is implicitly defined, and the trivialty of them is preserved.
[Bug c++/64428] aggregate with const member as union member [C++03]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64428 --- Comment #2 from R.HL at gmx dot net --- That was a typo, I quickly modified the example before submitting it. It should be U u = {1};
[Bug c++/63757] New: nullptr conversion sequence fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63757 Bug ID: 63757 Summary: nullptr conversion sequence fails to compile Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: R.HL at gmx dot net This code #include void bar(void*) {} struct foo { operator std::nullptr_t() { return nullptr; } }; int main() { bar(foo()); } Does not compile with GCC 4.9.1 (neither -std=c++11 nor =c++14). However, it should; There is one user defined conversion sequence inherent, consisting of one standard conversion sequence converting nullptr to nullptr_t (which is a pointer conversion, specifically a null pointer conversion), one user defined conversion through the conversion operator function and a second standard conversion sequence converting nullptr_t to void* (Which is also a pointer conversion).
[Bug c++/63985] New: Accepts invalid range-based for declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63985 Bug ID: 63985 Summary: Accepts invalid range-based for declaration Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: R.HL at gmx dot net int arr[] {1, 2, 3}; for (int i = 5: arr) std::cout << i << ", "; Compiles, while it shouldn't. A warning message suggests that GCC ignores the loop completely. warning: variable 'arr' set but not used Perhaps GCC can't decide what kind of loop this is and decides to ignore it silently?