[Bug c++/110186] -Weffc++ does not recognize user defined constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110186 --- Comment #3 from Amir Ansari --- Sorry, it is warning about C::C() = default rather than B::B() = default;
[Bug c++/110186] -Weffc++ does not recognize user defined constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110186 --- Comment #2 from Amir Ansari --- The compiler is warning about B::B() = default. That is C++ 11. How can you say it has not been updated for C++11? Meyer's updated book has a slightly different name: Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14 https://www.amazon.com/Effective-Modern-Specific-Ways-Improve/dp/1491903996/ref=sxin_11_mbs_w_global_sims?content-id=amzn1.sym.f6adc278-60fd-4516-8b02-0dbae28f44f1%3Aamzn1.sym.f6adc278-60fd-4516-8b02-0dbae28f44f1&crid=2O08PJEXO1KA3&cv_ct_cx=effective+c%2B%2B&keywords=effective+c%2B%2B&pd_rd_i=1491903996&pd_rd_r=2a95b35c-be52-4f57-9146-6e8f627019b9&pd_rd_w=gW5r8&pd_rd_wg=664iO&pf_rd_p=f6adc278-60fd-4516-8b02-0dbae28f44f1&pf_rd_r=AC6GTZ4RY51196JFRGDX&qid=1686292780&sprefix=effective+c%2B%2Caps%2C318&sr=1-1-9e7645f9-2d19-4bff-863e-f6cdbe50f990
[Bug c++/110187] New: The compiler fails to warn about deleted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110187 Bug ID: 110187 Summary: The compiler fails to warn about deleted constructor Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amir.ahmed.ansari at outlook dot com Target Milestone: --- Created attachment 55293 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55293&action=edit Code to replicate the problem Compile the attached code with the following flags: -std=c++17 -Wall -pedantic -Wextra -Weffc++ -O3 -flto The program compiles successfully. Now attempt to create an object of type B as auto b = B{}; Now the compiler spits errors (see below). This is very confusing for an ordinary user. It becomes worse if B has a second constructor that initializes a and this second constructor is used everywhere. This can lurk in the codebase undetected until somebody finally instantiates B with the default constructor. And it gets even worse when B is passed as a template argument and the error is generated deep within the template instantiation. : In function 'int main()': :17:16: error: use of deleted function 'B::B()' 17 | auto b = B{}; |^ :9:5: note: 'B::B()' is implicitly deleted because the default definition would be ill-formed: 9 | B() = default; | ^ :9:5: error: no matching function for call to 'A::A()' :3:5: note: candidate: 'A::A(int)' 3 | A(int) {} | ^ :3:5: note: candidate expects 1 argument, 0 provided :1:7: note: candidate: 'constexpr A::A(const A&)' 1 | class A | ^ :1:7: note: candidate expects 1 argument, 0 provided :1:7: note: candidate: 'constexpr A::A(A&&)' :1:7: note: candidate expects 1 argument, 0 provided
[Bug c++/110186] New: -Weffc++ does not recognize user defined constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110186 Bug ID: 110186 Summary: -Weffc++ does not recognize user defined constructor. Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amir.ahmed.ansari at outlook dot com Target Milestone: --- Created attachment 55292 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55292&action=edit Code to replicate the problem Compile the attached code with the following flags: -std=c++17 -Wall -pedantic -Wextra -Weffc++ -O3 -flto The following output is generated: : In constructor 'C::C()': :23:1: warning: 'C::a' should be initialized in the member initialization list [-Weffc++] 23 | C::C() = default; | ^ : In constructor 'D::D()': :28:5: warning: 'D::a' should be initialized in the member initialization list [-Weffc++] 28 | D() {} | ^ The compiler fails to consider B() = default; as a user defined default constructor and does not generate the warning to initialize a in the member initialization list.
[Bug c++/106351] New: ICE in fold expression involving templatized lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106351 Bug ID: 106351 Summary: ICE in fold expression involving templatized lambda Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amir.ahmed.ansari at outlook dot com Target Milestone: --- The following code: template struct C { void f() { ( [&, this]() { }.operator()(), ... ); } }; int main() { C{}.f(); return 0; } produces: : In instantiation of 'void C::f() [with Args = {int}]': :17:15: required from here :9:30: internal compiler error: in lookup_template_class_1, at cp/pt.cc:10114 7 | [&, this]() | ~ 8 | { | ~ 9 | }.operator()(), | ~^ 0x1ba65f9 internal_error(char const*, ...) ???:0 0x6fad32 fancy_abort(char const*, int, char const*) ???:0 0x87f6fd lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ???:0 0x875d31 tsubst(tree_node*, tree_node*, int, tree_node*) ???:0 0x881224 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*) ???:0 0x878889 instantiate_decl(tree_node*, bool, bool) ???:0 0x8936ab instantiate_pending_templates(int) ???:0 0x79c46d 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. ASM generation compiler returned: 1
[Bug c++/97055] New: Copy and move constructors shadowed by templatized constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97055 Bug ID: 97055 Summary: Copy and move constructors shadowed by templatized constructor Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amir.ahmed.ansari at outlook dot com Target Milestone: --- Created attachment 49219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49219&action=edit Failing program The attached simple program fails to compile on GCC 10.2. It compiles on both clang 10.0.1 and MSVC 19.24. The error produced on godbolt.org with no compilation options given: : In function 'int main()': :20:43: error: use of deleted function 'C::C(const U&) [with U = std::vector]' 20 | auto v2 = std::vector{std::move(v1)}; | ^ :14:5: note: declared here 14 | C(const U&) = delete; | ^ :21:32: error: use of deleted function 'C::C(const U&) [with U = std::vector]' 21 | auto v3 = std::vector{v1}; |^ :14:5: note: declared here 14 | C(const U&) = delete; | ^ Compiler returned: 1
[Bug c++/94132] Valid usage of flexible array member failing to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94132 --- Comment #2 from Amir Ansari --- (In reply to Andrew Pinski from comment #1) > >Can we make this check more robust so valid usage isn't rejected? > > Why do you think it is valid? Because I know the flexible array member data isn't dangling. I have allocated space immediately following the member that I would like to use. It has been working perfectly in previous versions. I understand there could be alignment concerns and if that is the case I am happy to declare it packed. Finally, the workaround gives the same outcome by typing some more code.
[Bug c++/94132] New: Valid usage of flexible array member failing to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94132 Bug ID: 94132 Summary: Valid usage of flexible array member failing to compile Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amir.ahmed.ansari at outlook dot com Target Milestone: --- Until gcc 9.2.0, the following usage was correct: struct S { int size; int data[]; }; struct { S s; int data[16]; } var; >From 9.2.1 onwards, this no longer compiles because the checking has gotten stricter: :3:9: error: flexible array member 'S::data' not at end of 'struct' 3 | int data[]; | ^~~~ :8:9: note: next member 'int ::data [16]' declared here 8 | int data[16]; Funnily, the following workaround circumvents the check: struct { union { struct { S s; int data[16]; }; }; } var; Can we make this check more robust so valid usage isn't rejected? I will leave it up to the experts to find the solution, but it would be easy for me to use an attribute such as [[space_follows]] to tell the compiler that valid space follows this member.