[Bug c++/87208] dependent name resolution selects a function it should have NEVER considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87208 Language Lawyer changed: What|Removed |Added CC||language.lawyer at gmail dot com --- Comment #4 from Language Lawyer --- Dup of Bug 70099?
[Bug c++/96321] New: GCC accepts conversion-function-id after the keyword template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96321
Bug ID: 96321
Summary: GCC accepts conversion-function-id after the keyword
template
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: language.lawyer at gmail dot com
Target Milestone: ---
struct S
{
template
operator T() { return T(); }
};
int i = S().template operator int();
The code is accepted by GCC, when it shouldn't be.
C++11 [temp.names]/5: A name prefixed by the keyword `template` shall be a
template-id or the name shall refer to a class template.
template-id:
simple-template-id
operator-function-id < template-argument-list[opt] >
literal-operator-id < template-argument-list[opt] >
So, conversion-function-id is not a template-id.
Code is also probably invalid in C++98/03. C++03 [temp.names]/5 says: If a name
prefixed by the keyword `template` is not the name of a member template, the
program is ill-formed.
[Bug c++/96593] New: No "declaration changes meaning" diagnostic for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96593
Bug ID: 96593
Summary: No "declaration changes meaning" diagnostic for alias
templates
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: language.lawyer at gmail dot com
Target Milestone: ---
"A name N used in a class S shall refer to the same declaration in its context
and when re-evaluated in the completed scope of S. No diagnostic is required
for a violation of this rule."
The diagnostic for the rule is not required, but since GCC diagnoses some of
the cases, there is a bugreport about missing diagnostic cases (bug 46983), and
the check might become mandatory (will it?), I'd like file this bug.
GCC accepts the code with alias templates:
struct S {};
template
struct T {};
struct U
{
template
using S = S;
template
using T = T;
};
but produces the "declaration changes meaning" error for type aliases.
GCC also diagnoses the case if the "outer" declaration is used before the
corresponding alias template:
struct S {};
struct U
{
S s;
template
using S = S; // error: declaration of ... changes meaning of 'S'
};
(From https://stackoverflow.com/q/63369264/)
[Bug c++/91618] template-id required to friend a function template, even for a qualified-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618 Language Lawyer changed: What|Removed |Added CC||language.lawyer at gmail dot com --- Comment #5 from Language Lawyer --- Dup of bug 88725
[Bug c++/93314] New: Invalid use of non-static data member causes ICE in gimplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93314
Bug ID: 93314
Summary: Invalid use of non-static data member causes ICE in
gimplify_expr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: language.lawyer at gmail dot com
Target Milestone: ---
int main()
{
struct S { int m; };
return sizeof(char[S::m]);
}
$ g++ prog.cc
prog.cc: In function 'int main()':
prog.cc:4:27: internal compiler error: in gimplify_expr, at gimplify.c:14581
4 | return sizeof(char[S::m]);
|~~~^
0x5c6160 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:14581
0x9a7434 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:13885
0x9a7de0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:13702
0x9aa19f gimplify_compound_lval
../../source/gcc/gimplify.c:3064
0x9a6c00 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:13533
0x9a7434 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:13885
0x9a7129 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:14348
0x9abfb0 internal_get_tmp_var
../../source/gcc/gimplify.c:619
0x9ac749 get_initialized_tmp_var(tree_node*, gimple**, gimple**, bool)
../../source/gcc/gimplify.c:674
0x9ac749 gimplify_save_expr
../../source/gcc/gimplify.c:6072
0x9a7621 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:13881
0x9a7434 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:13885
0x9a7129 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:14348
0x9a7434 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:13885
0x9b1ecb gimplify_modify_expr
../../source/gcc/gimplify.c:5765
0x9a73a2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:13581
0x9acc8e gimplify_stmt(tree_node**, gimple**)
../../source/gcc/gimplify.c:6822
0x9acc8e gimplify_and_add(tree_node*, gimple**)
../../source/gcc/gimplify.c:486
0x9acc8e gimplify_return_expr
../../source/gcc/gimplify.c:1667
0x9a8303 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../source/gcc/gimplify.c:13842
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.
(https://wandbox.org/permlink/GNNTjXAK2pQ5clUt)
I've selectively checked about some of g++ versions, from 4.4.7 to HEAD, on
wandbox.org. They're all crashing, just segfaulting before 5.1.0 and ICEing in
gimplify_expr starting from 5.1.0.
[Bug c++/93314] Invalid use of non-static data member causes ICE in gimplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93314 --- Comment #1 from Language Lawyer --- GCC thinks that `char[S::m]` is VLA (because the lvalue-to-rvalue conversion on `S::m` lvalue doesn't look like a constant expression) and tries to move the evaluation of `sizeof(char[S::m])` to run time. $ g++ prog.cc -pedantic prog.cc: In function 'int main()': prog.cc:4:28: warning: ISO C++ forbids variable length array [-Wvla] 4 | return sizeof(char[S::m]); |^ prog.cc:4:27: internal compiler error: in gimplify_expr, at gimplify.c:14581 4 | return sizeof(char[S::m]); | ...
[Bug rtl-optimization/90319] New: [C++17] aggregate initialization of base: ICE in assign_temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90319
Bug ID: 90319
Summary: [C++17] aggregate initialization of base: ICE in
assign_temp
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: language.lawyer at gmail dot com
Target Milestone: ---
This bug is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254, but
here the base is movable.
The following code:
struct B
{
B() = default;
B(B&&) { /* user-provided */ };
};
struct D : B {};
B f() { return {}; }
D a { f() };
triggers ICE in GCC HEAD 10.0.0 2019.04.30 (also reproducible in 8.x.y, 7.z.w):
$ g++ prog.cc -Wall -Wextra -std=c++17 prog.cc
during RTL pass: expand
prog.cc: In function 'void __static_initialization_and_destruction_0(int,
int)':
prog.cc:10:11: internal compiler error: in assign_temp, at function.c:982
10 | D a { f() };
| ^
0x596de0 assign_temp(tree_node*, int, int)
../../source/gcc/function.c:982
0x7b185f expand_call(tree_node*, rtx_def*, int)
../../source/gcc/calls.c:3459
0x8b0236 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../source/gcc/expr.c:11033
0x8bdc73 expand_normal
../../source/gcc/expr.h:285
0x8bdc73 store_field
../../source/gcc/expr.c:7022
0x8bb2d3 expand_assignment(tree_node*, tree_node*, bool)
../../source/gcc/expr.c:5296
0x7bd3d0 expand_call_stmt
../../source/gcc/cfgexpand.c:2722
0x7bd3d0 expand_gimple_stmt_1
../../source/gcc/cfgexpand.c:3691
0x7bd3d0 expand_gimple_stmt
../../source/gcc/cfgexpand.c:3850
0x7c20f7 expand_gimple_basic_block
../../source/gcc/cfgexpand.c:5886
0x7c448e execute
../../source/gcc/cfgexpand.c:6509
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.
(https://wandbox.org/permlink/f8QAVgCtSajxfG3L)
! There is no ICE if a positive optimization level (-O1/2/3) is specified !
[Bug c++/90321] New: [C++17] GCC allows structured binding (decomposition) of an object of type derived from a closure type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90321
Bug ID: 90321
Summary: [C++17] GCC allows structured binding (decomposition)
of an object of type derived from a closure type
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: language.lawyer at gmail dot com
Target Milestone: ---
The bug 78896 was fixed in r244909, so it is no longer possible to decompose a
closure itself, but deriving from a closure type makes it possible to access
closure members through an object of the derived type:
template struct hack : F { };
template hack(F) -> hack;
int main()
{
auto f = [x = 1, y = 2]() { };
// auto [a, b] = f; // error: cannot decompose lambda closure type
'main()::'
auto [a, b] = hack { f };
return b; // returns 2
}
https://wandbox.org/permlink/1ucU0A9vFyAI9yYh
[Bug c++/90780] New: GCC looses ref-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90780
Bug ID: 90780
Summary: GCC looses ref-qualifiers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: language.lawyer at gmail dot com
Target Milestone: ---
The following code (inspired by http://wg21.link/p0172)
using abominable = void() const volatile &&;
struct s {
abominable f;
};
abominable s::* ptr = &s::f;
is not accepted by GCC
$ g++ prog.cc -std=c++11
prog.cc:5:27: error: cannot convert 'void (s::*)() const volatile &&' to 'void
(s::*)() const volatile' in initialization
5 | abominable s::* ptr = &s::f;
|
(https://wandbox.org/permlink/gAjhGoSan6b38dlZ)
[Bug c++/51757] friend defined inside class and declared inside main linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51757 Language Lawyer changed: What|Removed |Added CC||language.lawyer at gmail dot com --- Comment #6 from Language Lawyer --- No linker error in GCC 11.0.0 20210117 (experimental) https://wandbox.org/permlink/EXabQxhTzbDzvbvr
[Bug c++/69701] "v.operator T()" incorrectly parsed if "v.T()" present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
Language Lawyer changed:
What|Removed |Added
CC||language.lawyer at gmail dot
com
--- Comment #7 from Language Lawyer ---
Another example related to CWG2396:
struct B
{
struct S {};
operator S();
};
auto v = B{}.operator struct S(); // error: 'struct B' has no member named
'operator S'
It can be checked that GCC injects unrelated `struct S` into the global
namespace and then tries to find `operator struct ::S` in B.
However, according to P1787R6 [basic.lookup.unqual]/5: An unqualified name that
is a component name of a type-specifier or ptr-operator of a conversion-type-id
is looked up in the same fashion as the conversion-function-id in which it
appears.
In an elaborated-type-specifier of the form "class-key identifier", such as
`struct S`, identifier is a component name ([dcl.type.elab]/1), so S shall be
searched in B first.
[Bug c++/111113] Cannot define friend function of a local class in namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13 Language Lawyer changed: What|Removed |Added CC||language.lawyer at gmail dot com --- Comment #5 from Language Lawyer --- (In reply to Andrew Pinski from comment #3) > I think this is a dup of bug 101356. Looks dup to me too. Looks like GCC does not match friend function declaration with its namespace declaration.
[Bug c++/120385] New: Incorrectly accepts array prvalues with certain operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385
Bug ID: 120385
Summary: Incorrectly accepts array prvalues with certain
operators
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: language.lawyer at gmail dot com
Target Milestone: ---
GCC 14 started accepting array prvalue operands where they are not allowed
(https://godbolt.org/z/6hj5YbTx7)
int main()
{
using IA = int[];
void(+IA{ 1, 2, 3 });
void(*IA{ 1, 2, 3 });
void(IA{ 1, 2, 3 } + 0);
void(IA{ 1, 2, 3 } - 0);
void(0 + IA{ 1, 2, 3 });
void(IA{ 1, 2, 3 } - IA{ 1, 2, 3 });
}
All of the void(...) lines shall make the program ill-formed
[Bug c++/120385] [14/15/16 Regression] GCC 14 incorrectly accepts array prvalues with certain operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385
--- Comment #2 from Language Lawyer ---
(In reply to Andrew Pinski from comment #1)
> Is this still valid?
> ```
> int main()
> {
> using IA = int[];
> using IP = int*;
> void(+IP{IA{ 1, 2, 3 }});
> }
> ```
Prolly, the wording is (was) a bit unclear to reason about
> Which makes this kinda of inconsistent after all.
Explicit casts changing the meaning of code mean inconsistency?
