[Bug c++/94038] New: Compiling with -Wall causes function template to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038
Bug ID: 94038
Summary: Compiling with -Wall causes function template to get
needlessly instantiated
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
With GCC trunk:
$ cat sa.cc
template
constexpr int
foo()
{
static_assert(T(1) == 0);
return 0;
}
constexpr int
bar(int a)
{
return a;
}
static_assert(decltype(bar(foo())){} == 0);
$ g++ -fsyntax-only -O sa.cc
$ g++ -fsyntax-only -O -Wall sa.cc
sa.cc: In instantiation of ‘constexpr int foo() [with T = int]’:
sa.cc:15:36: required from here
sa.cc:5:22: error: static assertion failed
5 | static_assert(T(1) == 0);
| ~^~~~
This seems to be a regression from GCC 9.
[Bug libstdc++/93978] A snippet using views::join fails to compile with -O1, but succeeds with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93978 Patrick Palka changed: What|Removed |Added Depends on||94038 --- Comment #1 from Patrick Palka --- I think the underlying cause of this issue is PR c++/94038 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038 [Bug 94038] Compiling with -Wall causes function template body to get needlessly instantiated
[Bug c++/94038] Compiling with -Wall causes function template body to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038 --- Comment #2 from Patrick Palka --- (In reply to Marek Polacek from comment #1) > > This seems to be a regression from GCC 9. > > Are you sure? I see the same thing with GCC 6. Oops, you're right, it's not a regression.
[Bug c++/93729] [concepts] binding bit-field to lvalue reference in requires expression should be SFINAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93729 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-05 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Patrick Palka --- Confirmed. The fix seems to be straightforward.
[Bug c++/93729] [concepts] binding bit-field to lvalue reference in requires expression should be SFINAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93729 Patrick Palka changed: What|Removed |Added Target Milestone|--- |10.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Patrick Palka --- Fixed for GCC 10 by 198366fe6ec4debda71281f4570666b3cf8cd8a0.
[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #4 from Patrick Palka ---
We also ICE elsewhere with the following modified testcase:
$ cat 94066.C
union U;
constexpr long foo(U *up);
union U {
long a = foo(this);
int y;
};
constexpr long foo(U *up) {
up->y = 11;
return 42;
}
extern constexpr U u = {};
$ g++ -std=c++17 94066.C
94066.C:15:26: internal compiler error: in output_constructor_regular_field, at
varasm.c:5230
15 | extern constexpr U u = {};
| ^
0x82f159 output_constructor_regular_field
/home/patrick/code/gcc/gcc/varasm.c:5230
0x82f159 output_constructor
/home/patrick/code/gcc/gcc/varasm.c:5536
0x1375894 output_constant
/home/patrick/code/gcc/gcc/varasm.c:4908
0x1375894 assemble_variable_contents
/home/patrick/code/gcc/gcc/varasm.c:2148
0x137e152 assemble_variable(tree_node*, int, int, int)
/home/patrick/code/gcc/gcc/varasm.c:2327
0x1380c79 varpool_node::assemble_decl()
/home/patrick/code/gcc/gcc/varpool.c:587
0xc209ec output_in_order
/home/patrick/code/gcc/gcc/cgraphunit.c:2564
0xc209ec symbol_table::compile()
/home/patrick/code/gcc/gcc/cgraphunit.c:2801
0xc22eec symbol_table::compile()
/home/patrick/code/gcc/gcc/cgraphunit.c:2717
0xc22eec symbol_table::finalize_compilation_unit()
/home/patrick/code/gcc/gcc/cgraphunit.c:2984
[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066
--- Comment #5 from Patrick Palka ---
Also if we add an explicitly defaulted constructor "U() = default;" to U in the
original test case, then
using GCC 9 /w -std=c++17 we get:
94066.C:16:25: in ‘constexpr’ expansion of ‘foo((&*this))’
94066.C:12:9: error: change of the active member of a union from ‘U::a’ to
‘U::y’
12 | up->y = 11;
| ~~^~~~
94066.C:16: confused by earlier errors, bailing out
using GCC 9 /w -std=c++2a compiles successfully, and we think U::y is the
active member, but static_assert(u.y == 11) fails with "error: ‘(((int)A{42})
== 11)’ is not a constant expression"
using GCC trunk /w -std=c++17 we get an active-member diagnostic as in GCC 9,
and the same ICE as in #c1
using GCC trunk /w -std=c++2a we get same behavior as in GCC 9 /w -std=c++2a
[Bug c++/94107] New: Infinite loop with malformed requires-expression inside a static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94107
Bug ID: 94107
Summary: Infinite loop with malformed requires-expression
inside a static_assert
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat loop.C
static_assert(requires { );
$ g++ -std=c++2a loop.C
loop.C:1:26: error: expected primary-expression before ‘)’ token
1 | static_assert(requires { );
| ^
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
| ^
loop.C:1:28: error: expected ‘;’ at end of input
1 | static_assert(requires { );
| ~^
|;
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
| ^
loop.C:1:28: error: expected ‘;’ at end of input
1 | static_assert(requires { );
| ~^
|;
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
| ^
loop.C:1:28: error: expected ‘;’ at end of input
1 | static_assert(requires { );
| ~^
|;
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
| ^
loop.C:1:28: error: expected ‘;’ at end of input
1 | static_assert(requires { );
| ~^
|;
loop.C:1:27: error: expected primary-expression at end of input
1 | static_assert(requires { );
| ^
...
[Bug c++/94126] New: [concepts] suboptimal diagnostic when type after substitution is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94126
Bug ID: 94126
Summary: [concepts] suboptimal diagnostic when type after
substitution is ill-formed
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat disj.cc
template
using blah = T::type;
template
concept C = requires (T t) { t + 0; };
template
concept D = C || C;
template
concept E = D>;
static_assert(E);
$ g++ -std=c++2a disj.cc
disj.cc:13:15: error: static assertion failed
13 | static_assert(E);
| ^~
disj.cc:13:15: note: constraints not satisfied
disj.cc:8:11: required for the satisfaction of ‘D’
disj.cc:8:20: note: neither operand of the disjunction is satisfied
8 | concept D = C || C;
| ~^
What the diagnostic should really say is that blah is ill-formed. Maybe
something like:
disj.cc:13:15: error: static assertion failed
13 | static_assert(E);
| ^~
disj.cc:13:15: note: constraints not satisfied
disj.cc:5:11: required for the satisfaction of ‘C’
disj.cc:8:11: required for the satisfaction of ‘D’
disj.cc:13:15: error: ‘int’ is not a class, struct, or union type
[Bug c++/93805] [8/9/10 Regression] A suspicious -Werror=noexcept warning since r8-2461-g9fb82e652cee118b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93805 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Looking into it.
[Bug c++/93805] [8/9/10 Regression] A suspicious -Werror=noexcept warning since r8-2461-g9fb82e652cee118b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93805
--- Comment #3 from Patrick Palka ---
Reduced test case:
$ cat 93805.C
struct B
{
B() {}
};
struct C
{
B b = B();
};
C c;
$ g++ -Wnoexcept 93805.C
93805.C:11:3: warning: noexcept-expression evaluates to ‘false’ because of a
call to ‘B::B()’ [-Wnoexcept]
11 | C c;
| ^
93805.C:3:3: note: but ‘B::B()’ does not throw; perhaps it should be declared
‘noexcept’
3 | B() {}
| ^
The commit in question adds a complain parameter to get_defaulted_eh_spec and
passes it down to synthesized_method_walk, and we eventually call
expr_noexcept_p in walk_field_subops with complain=tf_warning_or_error instead
of with complain=tf_none originally, which is the immediate cause of the
warning.
We're calling expr_noexcept_p from there to determine whether the NSDMI of C::b
is noexcept (so that we can determine the exception specification of C's
synthesized default constructor), and we're warning because the NSDMI of C::b
is not noexcept, but it could be if the non-throwing ctor B::B were marked
noexcept.
ISTM we can either disable the -Wnoexcept warning here, or we can keep the
warning but improve the warning message in this case.
[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Looking into it.
[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #5 from Patrick Palka ---
The ICE seems to be revealing a latent issue: In the following example (which
GCC accepts), according to the static_assert labelled (1), the type of t is
const int*, but according to the static_assert labelled (2), the type of t is
int *const.
template
void foo(const T t)
{
static_assert(__is_same(decltype(t), const int*)); // (1)
}
static_assert(__is_same(decltype(foo), void(int *))); // (2)
int
main()
{
foo(nullptr);
}
[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #6 from Patrick Palka ---
(In reply to Patrick Palka from comment #5)
> The ICE seems to be revealing a latent issue: In the following example
> (which GCC accepts), according to the static_assert labelled (1), the type
> of t is const int*, but according to the static_assert labelled (2), the
> type of t is int *const.
>
>
>
> template
> void foo(const T t)
> {
> static_assert(__is_same(decltype(t), const int*)); // (1)
> }
>
> static_assert(__is_same(decltype(foo), void(int *))); // (2)
>
> int
> main()
> {
> foo(nullptr);
> }
So the question becomes, what should the type of t be here? According to
https://eel.is/c++draft/temp#deduct-3:
"A top-level qualifier in a function parameter declaration does not affect the
function type but still affects the type of the function parameter variable
within the function."
The above suggests that the type of foo should be the same regardless of
where the parameter t is const-qualified. Going by this then, it appears that
the static_assert (2) is right and (1) is wrong. Can anyone confirm?
(On the other hand, Clang thinks (1) is right and (2) is wrong.)
[Bug c++/67960] [8/9 Regression] Prefixing a function with [[deprecated]] produces multiple warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960 Patrick Palka changed: What|Removed |Added Status|REOPENED|ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Known to fail|10.0| Summary|[8/9/10 Regression] |[8/9 Regression] Prefixing |Prefixing a function with |a function with |[[deprecated]] produces |[[deprecated]] produces |multiple warnings |multiple warnings --- Comment #7 from Patrick Palka --- I have a patch. --- Comment #8 from Patrick Palka --- Fixed on trunk by r10-7159.
[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #7 from Patrick Palka ---
(In reply to Patrick Palka from comment #6)
> (In reply to Patrick Palka from comment #5)
> > The ICE seems to be revealing a latent issue: In the following example
> > (which GCC accepts), according to the static_assert labelled (1), the type
> > of t is const int*, but according to the static_assert labelled (2), the
> > type of t is int *const.
> >
> >
> >
> > template
> > void foo(const T t)
> > {
> > static_assert(__is_same(decltype(t), const int*)); // (1)
> > }
> >
> > static_assert(__is_same(decltype(foo), void(int *))); // (2)
> >
> > int
> > main()
> > {
> > foo(nullptr);
> > }
>
> So the question becomes, what should the type of t be here? According to
> https://eel.is/c++draft/temp#deduct-3:
>
> "A top-level qualifier in a function parameter declaration does not affect
> the function type but still affects the type of the function parameter
> variable within the function."
>
> The above suggests that the type of foo should be the same regardless
> of where the parameter t is const-qualified. Going by this then, it appears
> that the static_assert (2) is right and (1) is wrong. Can anyone confirm?
>
> (On the other hand, Clang thinks (1) is right and (2) is wrong.)
So I think the quoted wording from [temp.deduct]/3 applies to function
parameter types _after_ substitution. So this doesn't definitively tell us
anything about the type of t.
I think the answer lies in [basic.type.qualifier]/3, which says:
"Cv-qualifiers applied to an array type attach to the underlying element type,
so the notation “cv T”, where T is an array type, refers to an array whose
elements are so-qualified ([dcl.array]"
So the type const T after substituting T=int[] is precisely const int[], which
as a parameter type then decays to const int* according to [dcl.fct]/5. So it
seems that the static_assert (1) is right, and (2) is wrong.
[Bug c++/94205] New: ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94205
Bug ID: 94205
Summary: ICE in cxx_eval_constant_expression with
'this'-capturing lambda inside an NSDMI
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat ice.C
struct S
{
int a = [this] { this->a = 5; return 6; } ();
};
constexpr S s = {};
$ g++ -std=c++2a ice.C
ice.C:7:18: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:6176
7 | constexpr S s = {};
| ^
0x5fe2d0 cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:6176
0x941f5f cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:5700
0x9413d6 cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:5965
0x94eacf cxx_eval_bare_aggregate
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:3836
0x941f0f cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:5930
0x943e5b cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:5552
0x941f5f cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:5700
0x94f4f3 cxx_bind_parameters_in_call
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:1525
0x93eb25 cxx_eval_call_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:2294
0x94177d cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:5472
0x94eacf cxx_eval_bare_aggregate
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:3836
0x941f0f cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:5930
0x944b74 cxx_eval_outermost_constant_expr
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:6486
[Bug c++/94219] New: ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94219
Bug ID: 94219
Summary: ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat 94066-struct.C
struct A { long x; };
struct U;
constexpr A foo(U *up);
struct U { // struct instead of union
A a = foo(this); int y;
};
constexpr A foo(U *up) {
up->y = 11;
return {42};
}
extern constexpr U u = {};
static_assert(u.y == 11, "");
static_assert(u.a.x == 42, "");
$ g++ -std=c++14 94066-struct.C
94066-modified.C:15:25: internal compiler error: in cxx_eval_bare_aggregate, at
cp/constexpr.c:3790
18 | extern constexpr U u = {};
| ^
0x602956 cxx_eval_bare_aggregate
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:3790
0x941caf cxx_eval_constant_expression
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:5895
0x944914 cxx_eval_outermost_constant_expr
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:6451
0x9498c4 maybe_constant_init_1
/home/patrick/code/gcc-master/gcc/cp/constexpr.c:6908
0xb1919c store_init_value(tree_node*, tree_node*, vec**, int)
/home/patrick/code/gcc-master/gcc/cp/typeck2.c:889
0x9acc22 check_initializer
/home/patrick/code/gcc-master/gcc/cp/decl.c:6838
0x9ae917 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/patrick/code/gcc-master/gcc/cp/decl.c:7764
0xa57a9d cp_parser_init_declarator
/home/patrick/code/gcc-master/gcc/cp/parser.c:20837
0xa378f3 cp_parser_simple_declaration
/home/patrick/code/gcc-master/gcc/cp/parser.c:13689
0xa5fd97 cp_parser_declaration
/home/patrick/code/gcc-master/gcc/cp/parser.c:13388
0xa60517 cp_parser_translation_unit
/home/patrick/code/gcc-master/gcc/cp/parser.c:4731
0xa60517 c_parse_file()
/home/patrick/code/gcc-master/gcc/cp/parser.c:43758
0xb70dcb c_common_parse_file()
/home/patrick/code/gcc-master/gcc/c-family/c-opts.c:1186
This is closely related to PR c++/94066, but unlike that PR, this one is not a
regression AFAICT.
[Bug c++/69694] type incomplete depending if constructing function is templated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69694 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #5 from Patrick Palka --- This is fixed since 7.1, it seems.
[Bug c++/90880] compile error instead of SFINAE with non-public member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/90711] [9/10 Regression] Failing SFINAE from unrelated struct since r9-6794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90711 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |9.4 Known to work||8.3.0 Summary|Failing SFINAE from |[9/10 Regression] Failing |unrelated struct|SFINAE from unrelated ||struct since r9-6794 Known to fail||10.0, 9.3.0 Last reconfirmed||2020-03-23 CC||jason at redhat dot com, ||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Confirmed. We started to reject the testcase in #c2 with r9-6794.
[Bug c++/93805] [8/9 Regression] A suspicious -Werror=noexcept warning since r8-2461-g9fb82e652cee118b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93805 Patrick Palka changed: What|Removed |Added Summary|[8/9/10 Regression] A |[8/9 Regression] A |suspicious -Werror=noexcept |suspicious -Werror=noexcept |warning since |warning since |r8-2461-g9fb82e652cee118b |r8-2461-g9fb82e652cee118b --- Comment #5 from Patrick Palka --- Fixed on trunk.
[Bug c++/67960] [8/9 Regression] Prefixing a function with [[deprecated]] produces multiple warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960 --- Comment #11 from Patrick Palka --- (In reply to Eric Gallager from comment #10) > (In reply to Patrick Palka from comment #8) > > Fixed on trunk by r10-7159. > > so... keeping open for backports, I take it? Probably yes.
[Bug c++/94066] [8/9 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066 Patrick Palka changed: What|Removed |Added Summary|[8/9/10 Regression] ICE |[8/9 Regression] ICE |(starting/ending union |(starting/ending union |member lifetime) in |member lifetime) in |cxx_eval_bare_aggregate, at |cxx_eval_bare_aggregate, at |cp/constexpr.c:3790 since |cp/constexpr.c:3790 since |r6-7592 |r6-7592 --- Comment #9 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/94265] wrong warning "duplicated 'if' condition"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94265 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Patrick Palka --- Taking a look.
[Bug c++/94252] Can't use a lambda in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94252 Patrick Palka changed: What|Removed |Added Target Milestone|--- |10.0 Known to fail||10.0 Last reconfirmed||2020-03-24 Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Patrick Palka --- Confirmed.
[Bug c++/94252] Can't use a lambda in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94252 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94265] wrong warning "duplicated 'if' condition"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94265 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #4 from Patrick Palka --- Thanks for the bug report, this is now fixed for GCC 10.
[Bug c++/94332] New: [concepts] requires-expression that contains a requires-expression incorrectly evaluates to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94332
Bug ID: 94332
Summary: [concepts] requires-expression that contains a
requires-expression incorrectly evaluates to false
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat requires-requires.C
template
requires B
struct X { };
template
concept C = requires { X{}; };
static_assert(C); // should succeed
$ g++ -std=c++2a requires-requires.C
requires-requires.C:8:15: error: static assertion failed
8 | static_assert(C); // should succeed
| ^~
requires-requires.C:8:15: note: constraints not satisfied
requires-requires.C:6:11: required by the constraints of ‘template
concept C’
requires-requires.C:6:15: in requirements
requires-requires.C:6:26: note: the required expression ‘X{}’
is invalid
6 | concept C = requires { X{}; };
| ^~~
If we let the compiler elaborate further, we get:
requires-requires.C:6:26: note: the required expression ‘X{}’
is invalid, because
6 | concept C = requires { X{}; };
| ^~~
requires-requires.C:6:26: error: invalid use of incomplete type ‘struct
X’
requires-requires.C:3:10: note: declaration of ‘struct X’
3 | struct X { };
[Bug c++/94306] Improve diagnostic when "requires" used instead of "requires requires" and add fix-it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94306 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |10.0 Last reconfirmed||2020-03-25 --- Comment #1 from Patrick Palka --- Confirmed. Looking into it.
[Bug c++/94252] Can't use a lambda in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94252 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/94306] Improve diagnostic when "requires" used instead of "requires requires" and add fix-it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94306 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed.
[Bug c++/94126] [concepts] suboptimal diagnostic when type after substitution is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94126 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- With current trunk and -fconcepts-diagnostics-depth=2, we now get: disj.cc:13:15: error: static assertion failed 13 | static_assert(E); | ^~ disj.cc:13:15: note: constraints not satisfied disj.cc:8:11: required for the satisfaction of ‘D’ [with T = int] disj.cc:8:20: note: no operand of the disjunction is satisfied 8 | concept D = C || C; | ~^ disj.cc:8:15: note: the operand ‘C’ is unsatisfied because 8 | concept D = C || C; | ^~ disj.cc:5:11: required for the satisfaction of ‘C’ [with T = typename T::type] disj.cc:8:11: required for the satisfaction of ‘D’ [with T = int] disj.cc:13:15: error: ‘int’ is not a class, struct, or union type 13 | static_assert(E); | ^~ disj.cc:8:23: note: the operand ‘C’ is unsatisfied because 8 | concept D = C || C; | ^~ disj.cc:5:11: required for the satisfaction of ‘C’ [with T = typename T::type] disj.cc:8:11: required for the satisfaction of ‘D’ [with T = int] disj.cc:13:15: error: ‘int’ is not a class, struct, or union type 13 | static_assert(E); | ^~ So I'm considering this fixed.
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Paolo, would you happen to be working on this PR still?
[Bug c++/94414] only `--` gives constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94414 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- It looks the memoization that's performed in filter_view::begin() is interfering with optimization in the first testcase.
[Bug c++/94219] ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94219 Patrick Palka changed: What|Removed |Added Last reconfirmed||2020-04-01 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94470] New: Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94470
Bug ID: 94470
Summary: Constexpr variable initialization with self-modifying
constructor incorrectly rejected since r7-6728
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
struct X
{
int b = 0;
int c = ((this->b=1), 1);
};
constexpr X o = { };
static_assert(o.b == 1);
$ g++ -std=c++17 testcase.C
testcase.C:7:19: error: modification of ‘o’ is not a constant expression
constexpr X o = { };
^
testcase.C:9:19: error: non-constant condition for static assertion
static_assert(o.b == 1);
^~~~
[Bug c++/94470] [8/9/10 Regression] Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94470 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail||10.0, 7.5.0, 8.4.0, 9.3.0 Ever confirmed|0 |1 Last reconfirmed||2020-04-03 Known to work||6.5.0 CC||jason at gcc dot gnu.org Keywords||ice-on-valid-code Target Milestone|--- |10.0 Summary|Constexpr variable |[8/9/10 Regression] |initialization with |Constexpr variable |self-modifying constructor |initialization with |incorrectly rejected since |self-modifying constructor |r7-6728 |incorrectly rejected since ||r7-6728
[Bug c++/93211] equivalence of dependent function calls doesn't check if the call is eligible for ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93211 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90711 Target Milestone|--- |9.4 --- Comment #2 from Patrick Palka --- Fixed is 9.4 and 10 by the fix for PR90711.
[Bug c++/94205] [8/9/10 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94205 Bug 94205 depends on bug 94219, which changed state. Bug 94219 Summary: ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94219 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/94219] ICE in cxx_eval_bare_aggregate, at cp/constexpr.c:3790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94219 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/94205] [8/9 Regression] ICE in cxx_eval_constant_expression with 'this'-capturing lambda inside an NSDMI since r8-1251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94205 Patrick Palka changed: What|Removed |Added Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |cxx_eval_constant_expressio |cxx_eval_constant_expressio |n with 'this'-capturing |n with 'this'-capturing |lambda inside an NSDMI |lambda inside an NSDMI |since r8-1251 |since r8-1251 --- Comment #7 from Patrick Palka --- Fixed for GCC 10 so far.
[Bug c++/94499] New: [concepts] bogus "local variable may not appear in this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94499
Bug ID: 94499
Summary: [concepts] bogus "local variable may not appear in
this context" error
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
template
constexpr bool
bar(bool b = requires (T t) { *t; })
{
return b;
}
$ g++ -std=c++2a testcase.C
testcase.C:3:32: error: local variable ‘t’ may not appear in this context
3 | bar(bool b = requires (T t) { *t; })
|^
[Bug c++/94501] New: bogus "no matches converting function ... to type ..." error with variadic function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94501
Bug ID: 94501
Summary: bogus "no matches converting function ... to type ..."
error with variadic function template
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
template
void foo(Ts...);
int main()
{
void (*f)(int*) = foo;
}
$ g++ -std=c++11 testcase.C
testcase.C: In function ‘int main()’:
testcase.C:6:21: error: no matches converting function ‘foo’ to type ‘void
(*)(int*)’
6 | void (*f)(int*) = foo;
| ^~
testcase.C:2:6: note: candidate is: ‘template void foo(Ts ...)’
2 | void foo(Ts...);
| ^~~
But if we replace the template parameter pack Ts with an ordinary template
parameter T then the testcase compiles successfully. The fact that we perform
array-to-pointer decaying of "int[]" after substituting into the function
parameter pack seems to be relevant here.
[Bug c++/90996] [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:13495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90996 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/90996] [8/9 Regression] ICE in gimplify_expr, at gimplify.c:13495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90996 Patrick Palka changed: What|Removed |Added Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |gimplify_expr, at |gimplify_expr, at |gimplify.c:13495|gimplify.c:13495 --- Comment #5 from Patrick Palka --- Fixed for GCC 10 so far.
[Bug c++/94521] New: Infinite loop with decltype of function parameter of type decltype([]{})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94521
Bug ID: 94521
Summary: Infinite loop with decltype of function parameter of
type decltype([]{})
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
template
void spam(decltype([]{}) *s)
{
static_assert(__is_same(int, decltype(s)));
}
void foo()
{
spam(nullptr);
}
$ g++ -std=c++2a testcase.C
^C
[Bug c++/94480] [10 Regression] ICE in cp_parser_abort_tentative_parse, at cp/parser.c:31858
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94480 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94480] [10 Regression] ICE in cp_parser_abort_tentative_parse, at cp/parser.c:31858
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94480
Patrick Palka changed:
What|Removed |Added
Assignee|ppalka at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED|NEW
--- Comment #2 from Patrick Palka ---
Reduced rejects-valid testcase:
decltype(requires { 1; }) b;
This is probably caused by commit 3ec8ee2e0f0b0508ca9dcc7b99f8e79015efd600 on
the concepts branch:
commit 3ec8ee2e0f0b0508ca9dcc7b99f8e79015efd600
Date: Fri Jul 12 17:04:02 2019 -0400
* parser.c (cp_parser_requires_expression): Commit to the tentative
parse.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 9e6cad6ce91..ea24fe1da6b 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -27203,6 +27203,9 @@ cp_parser_requires_expression (cp_parser *parser)
return error_mark_node;
}
+ /* This is definitely a requires-expression. */
+ cp_parser_commit_to_tentative_parse (parser);
+
tree parms, reqs;
{
/* Local parameters are delared as variables within the scope
Or at least, removing this call fixes the ICE, and doesn't seem to introduce
any testsuite regressions. I wonder what we need this call to
cp_parser_commit_to_tentative_parse for? I ran a bunch of frontend/library
testsuite tests with the above call replaced with a
gcc_assert (!cp_parser_uncommitted_to_tentative_parse_p (parser));
and I couldn't get the assert to fail in any of the existing testsuite tests I
tried. The assert of course fails for the testcase in this PR though.
Unassigning myself since I don't think I understand the tentative parsing stuff
here enough to resolve this.
[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010 Patrick Palka changed: What|Removed |Added Summary|[8/9/10 Regression] gcc |[8/9 Regression] gcc |internal error since 8x on |internal error since 8x on |warning write-strings |warning write-strings --- Comment #9 from Patrick Palka --- Fixed on GCC 10 so far. The thread https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542487.html which continues at https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543094.html discusses this PR and the ultimate fix.
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
--- Comment #5 from Patrick Palka ---
Here is a rejects-valid testcase caused by the same underlying issue:
$ cat testcase.C
struct A { A *p = this; int n; };
constexpr A
foo()
{
return {};
}
constexpr A
bar()
{
A a = foo();
a.p->n = 5;
return a;
}
static_assert(bar().n == 5);
$ g++ -std=c++2a testcase.C
testcase.C:17:23: error: non-constant condition for static assertion
17 | static_assert(bar().n == 5);
| ^~~~
testcase.C:17:19: in ‘constexpr’ expansion of ‘bar()’
testcase.C:17:23: error: modification of ‘‘result_decl’ not supported by
dump_expr’ is not a constant expression
[Bug c++/94537] New: Possibly wrong code with mandatory copy elision and 'this' pointer arithmetic inside an NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94537
Bug ID: 94537
Summary: Possibly wrong code with mandatory copy elision and
'this' pointer arithmetic inside an NSDMI
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
struct A { A *p = this-1; int n = p->n; };
constexpr A
foo()
{
return {};
}
A a[2] = { {nullptr, 5}, foo() };
int
main()
{
if (a[1].n != 5)
__builtin_abort ();
}
$ g++ testcase.C
$ ./a.out
zsh: abort ./a.out
[Bug c++/94537] Possibly wrong code with mandatory copy elision and 'this' pointer arithmetic inside an NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94537
--- Comment #1 from Patrick Palka ---
We also reject a constexpr version of the testcase:
$ cat testcase.C
struct A { A *p = this-1; int n = p->n; };
constexpr A
foo()
{
return {};
}
constexpr A a[2] = { {nullptr, 5}, foo() };
static_assert(a[1].n == 5);
$ g++ testcase.C
testcase.C:9:40: in ‘constexpr’ expansion of ‘foo()’
testcase.C:9:42: error: ‘*(&*this)->A::p’ is not a constant expression
9 | constexpr A a[2] = { {nullptr, 5}, foo() };
| ^
testcase.C:10:22: error: non-constant condition for static assertion
10 | static_assert(a[1].n == 5);
| ~~~^~~~
[Bug c++/94537] Possibly wrong code with mandatory copy elision and 'this' pointer arithmetic inside an NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94537
--- Comment #2 from Patrick Palka ---
Simpler runtime testcase:
$ cat testcase.C
struct A { A *p = this; int m = 1; };
A
foo()
{
return {};
}
int
main()
{
A a = foo();
a.p->m++;
if (a.m != 2)
__builtin_abort ();
}
$ g++ -std=c++17 testcase.C
$ ./a.out
zsh: abort ./a.out
[Bug middle-end/94539] New: gcc.dg/alias-14.c fails on gcc 10, succeeds on gcc 9, when turned into an execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94539 Bug ID: 94539 Summary: gcc.dg/alias-14.c fails on gcc 10, succeeds on gcc 9, when turned into an execution test Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ppalka at gcc dot gnu.org Target Milestone: --- The test gcc/testsuite/gcc.dg/alias-14.c fails when compiled and executed with gcc 10, and succeeds when compiled and executed with gcc 9. It was added in r6-1220 as a compile-only test, but seems like it should be an execution test? Apologies in advance if this test is bogus as an execution test.
[Bug middle-end/94539] [10 Regression] gcc.dg/alias-14.c fails on gcc 10, succeeds on gcc 9, when turned into an execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94539 --- Comment #3 from Patrick Palka --- Bisection seems to be pointing to r10-779
[Bug c++/94521] Infinite loop with decltype of function parameter of type decltype([]{})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94521 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94470] [8/9/10 Regression] Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94470 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/85278] [concepts] Garbled diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/94521] Infinite loop with decltype of function parameter of type decltype([]{})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94521 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/94470] [8/9 Regression] Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94470 Patrick Palka changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] Constexpr |Constexpr variable |variable initialization |initialization with |with self-modifying |self-modifying constructor |constructor incorrectly |incorrectly rejected since |rejected since r7-6728 |r7-6728 | --- Comment #2 from Patrick Palka --- Fixed for GCC 10 so far.
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 85278, which changed state. Bug 85278 Summary: [concepts] Garbled diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/85278] [concepts] Garbled diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85278 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.0 Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 93207, which changed state. Bug 93207 Summary: [concepts] Variadic concepts refuse to compile when function definition is not inline https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/93207] [concepts] Variadic concepts refuse to compile when function definition is not inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93207 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #4 from Patrick Palka --- This seems to be already fixed for GCC 10.
[Bug c++/94475] [9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94475 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94475] [9 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94475 Patrick Palka changed: What|Removed |Added Summary|[9/10 Regression] ICE: tree |[9 Regression] ICE: tree |check: expected class |check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |element_mode, at|element_mode, at |tree.c:13813|tree.c:13813 --- Comment #4 from Patrick Palka --- Fixed for GCC 10 so far.
[Bug c++/94483] [9/10 Regression] ICE: tree check: expected type_pack_expansion, have error_mark in add_capture, at cp/lambda.c:607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94483 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94610] 'invalid use of incomplete type' error which show an alias, but without the real type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94610 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-16 CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Good point, confirmed.
[Bug c++/94483] [9/10 Regression] ICE: tree check: expected type_pack_expansion, have error_mark in add_capture, at cp/lambda.c:607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94483 Patrick Palka changed: What|Removed |Added Keywords|error-recovery, |ice-on-valid-code |ice-on-invalid-code | --- Comment #2 from Patrick Palka --- Is the testcase really invalid? I don't see why it would be.
[Bug c++/88754] [8/9/10 Regression] Constructor call wrongly assumed to be a variable declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88754 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/92187] [concepts] An abbreviated function template ignores type constraint in some circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92187 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-04-17 Target Milestone|--- |10.0 CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed, taking a look.
[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94632 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #1 from Patrick Palka --- Looking into it.
[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94632
--- Comment #2 from Patrick Palka ---
Smaller testcase that exhibits the ICE:
template struct b;
template class c {
template static void d(f e, b x);
public:
static const bool h = false;
};
bool y = c::h;
[Bug c++/94483] [9 Regression] ICE: tree check: expected type_pack_expansion, have error_mark in add_capture, at cp/lambda.c:607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94483 Patrick Palka changed: What|Removed |Added Summary|[9/10 Regression] ICE: tree |[9 Regression] ICE: tree |check: expected |check: expected |type_pack_expansion, have |type_pack_expansion, have |error_mark in add_capture, |error_mark in add_capture, |at cp/lambda.c:607 |at cp/lambda.c:607 --- Comment #4 from Patrick Palka --- Fixed for GCC 10 so far.
[Bug c++/88754] [8/9 Regression] Constructor call wrongly assumed to be a variable declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88754 Patrick Palka changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] |Constructor call wrongly|Constructor call wrongly |assumed to be a variable|assumed to be a variable |declaration |declaration --- Comment #6 from Patrick Palka --- Fixed for GCC 10 so far.
[Bug c++/92187] [concepts] An abbreviated function template ignores type constraint in some circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92187 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94632 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed.
[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
Reduced rejects-valid testcase:
int f(int, int);
int f(int);
template
auto select(Args... args) -> decltype(f(args...))
{
if constexpr(sizeof...(Args)>1)
return select(7);
else
return 0;
}
int a = select(0, 1);
Replace 'args...' with 'decltype(args){}' to make it ICE-on-valid.
[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
--- Comment #4 from Patrick Palka ---
(In reply to Patrick Palka from comment #3)
> Reduced rejects-valid testcase:
>
> int f(int, int);
> int f(int);
>
> template
> auto select(Args... args) -> decltype(f(args...))
> {
> if constexpr(sizeof...(Args)>1)
> return select(7);
> else
> return 0;
> }
>
> int a = select(0, 1);
>
>
>
> Replace 'args...' with 'decltype(args){}' to make it ICE-on-valid.
Oops, that should say 'decltype(args){}...'
[Bug c++/91849] Misleading diagnostic message when binding reference to unrelated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91849 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- g++ 4.9.4 gives a seemingly better diagnostic: q.C: In function 'void g()': q.C:5:12: error: invalid initialization of reference of type 'int&' from expression of type 'float' int &r = f; ^ q.C: In function 'void g2()': q.C:11:12: error: invalid initialization of non-const reference of type 'int&' from an rvalue of type 'float' int &r = 1.f; ^ So should this be classified as a regression?
[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/94549] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org
[Bug c++/94628] [8/9 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|NEW Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |invalid_nonstatic_memfn_p |invalid_nonstatic_memfn_p |at cp/typeck.c:1979 since |at cp/typeck.c:1979 since |r9-640-g1268ecc26fc1289b|r9-640-g1268ecc26fc1289b --- Comment #14 from Patrick Palka --- Fixed for GCC 10 so far.
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|ppalka at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #6 from Patrick Palka --- Oops, accidentally assigned myself this bug; unassigning.
[Bug c++/94597] [10 Regression] ICE while using a concept checking for user defined conversion operator since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94597 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug c++/94597] [10 Regression] ICE while using a concept checking for user defined conversion operator since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94597 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Fixed. I think the reduced testcase in #c1 is invalid as-is -- the requirement "e.operator c;" should be "e.operator c();", because according to [expr.ref]: [The expression E1.E2 where E2 refers to a non-static member function] can be used only as the left-hand operand of a member function call. I committed the reduced testcase with that change.
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 --- Comment #7 from Patrick Palka --- As in PR94597, I think the testcases here in #c0 and #c2 might be invalid as-is -- the requirement "t.cend;" should probably be "t.cend();", and we reject the former since r10-7554. With that minor change we successfully compile the reduced testcase, but we still get the same ICE with the original testcase.
[Bug c++/94549] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed.
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645
--- Comment #9 from Patrick Palka ---
Thanks for the reduced testcases.
The problem in #c8 seems to start in grokfndecl() when processing the
operator() of the lambda. During grokfndecl on the operator(),
processing_template_decl is 1 but template_class_depth is 0 (seems it should be
1 here?). So the condition for 'memtmpl' in
tree ctx = friendp ? current_class_type : ctype;
bool memtmpl = (processing_template_decl > template_class_depth (ctx));
is true for this non-templated lambda, but IIUC 'memtmpl' should be true only
if the declaration in question has its own set of template parameters, which is
not the case here.
Since memtmpl is true, we then attach the innermost constraints (belonging to
struct l) to this non-templated operator() via:
if (memtmpl)
tmpl_reqs = TEMPLATE_PARMS_CONSTRAINTS (current_template_parms);
tree ci = build_constraints (tmpl_reqs, decl_reqs);
...
set_constraints (decl, ci);
and thing goes downhill from there.
I tried fixing template_class_depth to return 1 in this case via
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -390,7 +390,12 @@ template_class_depth (tree type)
++depth;
if (DECL_P (type))
- type = CP_DECL_CONTEXT (type);
+ {
+ if (tree fctx = DECL_FRIEND_CONTEXT (type))
+ type = fctx;
+ else
+ type = CP_DECL_CONTEXT (type);
+ }
else if (LAMBDA_TYPE_P (type) && LAMBDA_TYPE_EXTRA_SCOPE (type))
type = LAMBDA_TYPE_EXTRA_SCOPE (type);
else
but this change causes a bunch of ICEs in the cmcstl2 testsuite.
It seems that the condition for 'memtmpl' needs adjusting, but I'm not sure
how.
[Bug c++/94719] New: ICE with constrained inherited constructor template from class template since r10-7859
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94719
Bug ID: 94719
Summary: ICE with constrained inherited constructor template
from class template since r10-7859
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
template
struct bar
{
template
requires (N == 5)
bar() { }
};
template
struct foo : bar
{
using foo::bar::bar;
};
void baz()
{
foo{};
}
$ g++ -std=c++2a -fconcepts
testcase.C: In instantiation of ‘foo::foo() [with int N = 5][inherited
from bar]’:
testcase.C:17:12: required from here
testcase.C:5:17: internal compiler error: unexpected expression ‘N’ of kind
template_parm_index
5 | requires (N == 5)
| ~~~^
This is caused by the fix for PR94549.
[Bug c++/94719] ICE with constrained inherited constructor template from class template since r10-7859
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94719 --- Comment #1 from Patrick Palka --- I am testing a fix.
[Bug c++/94719] ICE with constrained inherited constructor template from class template since r10-7859
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94719 Patrick Palka changed: What|Removed |Added Last reconfirmed||2020-4-22 Target Milestone|--- |10.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed.
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 --- Comment #10 from Patrick Palka --- Oops, it turns out the ICEs I was seeing in the cmcstl2 testsuite with the change in #c9 were actually due to PR94719, which has since been fixed. The cmcstl2 testsuite now compiles fine with or without the change in #c9 FWIW.
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Patrick Palka --- Fixed.
[Bug c++/91706] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91706
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #5 from Patrick Palka ---
Slightly more reduced testcase:
template struct A;
struct C {
template static int c ();
};
template struct D : C {
using c = decltype (c);
using E = A;
};
D g;
