[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=2O08PJEXO1KA3_ct_cx=effective+c%2B%2B=effective+c%2B%2B_rd_i=1491903996_rd_r=2a95b35c-be52-4f57-9146-6e8f627019b9_rd_w=gW5r8_rd_wg=664iO_rd_p=f6adc278-60fd-4516-8b02-0dbae28f44f1_rd_r=AC6GTZ4RY51196JFRGDX=1686292780=effective+c%2B%2Caps%2C318=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=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=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=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.
