[Bug c++/112842] Constrained parameter pack with trailing param gives no matching function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112842 --- Comment #1 from John Eivind Helset --- hopefully not a duplicate, couldn't find any matching ones, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623 was the closest i could find.
[Bug c++/112842] New: Constrained parameter pack with trailing param gives no matching function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112842
Bug ID: 112842
Summary: Constrained parameter pack with trailing param gives
no matching function.
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jehelset at gmail dot com
Target Milestone: ---
Created attachment 56785
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56785=edit
Minimal reproducer, compile with --std=c++20
Program below doesn't compile:
template
concept U = true;
template
struct V{
static constexpr void f(U auto ...,int){
}
};
int main(){
V::f(0,1); //no matching function for call to ‘V::f(int, int)’
//template argument deduction/substitution failed:
//candidate expects 1 argument, 2 provided
}
If there's no trailing parameter it works ok. clang-trunk seemed to handle it
fine. gcc-trunk also failed this.
[Bug c++/102493] non-type template specialization for member pointer to field and function reports leads to unexpected conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102493
--- Comment #1 from John Eivind Helset ---
ran into this today as well with:
```cpp
struct X{
void f(char){}
};
template
struct Y{};
template
struct Y{};
template
struct Y{};
Y<::f> y;
```
using gcc 13.1.1, clang trunk accepted same code.
[Bug c++/110025] [C++23] ICE with default-argument for template-param with decltype and auto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110025 --- Comment #7 from John Eivind Helset --- (In reply to Andrew Pinski from comment #2) > Created attachment 55200 [details] > testcase 1 > > Please next time attach the testcases rather than just links to godbolt. Will do! Thanks.
[Bug c++/110025] ICE with default-argument for template-param with decltype and auto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110025 --- Comment #1 from John Eivind Helset --- Some other weirdness related to use of `auto(expr)` in template-arguments: https://godbolt.org/z/jf64xExTW Might be a separate bug.
[Bug c++/110025] New: ICE with default-argument for template-param with decltype and auto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110025 Bug ID: 110025 Summary: ICE with default-argument for template-param with decltype and auto. Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jehelset at gmail dot com Target Milestone: --- Compiler ICE when using decltype(auto(variable-template)) as default-argument of a template-param: https://godbolt.org/z/M9qrvTj8P
[Bug c++/100673] [coroutines] Non-template, UDT await_suspend return-type results in ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100673 John Eivind Helset changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from John Eivind Helset --- Looks good now!
[Bug c++/104548] parser rejects alias template id of lambda in unevaluated-context and accepts when no alias is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104548 John Eivind Helset changed: What|Removed |Added CC||jehelset at gmail dot com --- Comment #2 from John Eivind Helset --- here is another variant of this i think: https://godbolt.org/z/nfsWPn6x8
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 --- Comment #5 from John Eivind Helset --- Created attachment 52729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52729=edit Patch with testcase. Tried adding a testcase to the g++.dg/coroutines testsuite. Used dg-ice, but it seems to complain about excess errors anyways: FAIL: g++.dg/coroutines/pr105104.C (test for excess errors) Excess errors: during GIMPLE pass: coro-early-expand-ifns
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 --- Comment #4 from John Eivind Helset --- It seems a non-void return-type from await-resume of a final awaitable, combined with at least -O1 causes a segfault: https://godbolt.org/z/rzq8dM7Pr Not sure if it's the same as the one I initially encountered yet.
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 --- Comment #2 from John Eivind Helset --- I'll try to create an MRE eventually...
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 --- Comment #1 from John Eivind Helset --- Indices of `bb` and `case_bb` in `convert_single_case_switch` are: (gdb) p bb->index $18 = 154 (gdb) p case_bb->index $19 = 157 If that helps.
[Bug c++/105104] New: [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104 Bug ID: 105104 Summary: [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jehelset at gmail dot com Target Milestone: --- Created attachment 52716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52716=edit Output from "-fdump-tree-coro-early-expand-ifns=stdout" Compiler segfaults on `if (EDGE_COUNT (pred->succs) <= EDGE_COUNT (succ->preds))`, as `succ` is null. Backtrace: #0 0x0107a2ae in find_edge (pred=0x7fffc626f068, succ=0x0) at ../../gcc/cfganal.cc:523 #1 0x01864cc7 in convert_single_case_switch (swtch=0x7fffc625d2d0, gsi=...) at ../../gcc/tree-cfgcleanup.cc:118 #2 0x01864d9e in cleanup_control_expr_graph (bb=0x7fffc626f068, gsi=...) at ../../gcc/tree-cfgcleanup.cc:145 #3 0x018652be in cleanup_control_flow_bb (bb=0x7fffc626f068) at ../../gcc/tree-cfgcleanup.cc:274 #4 0x0186712f in cleanup_control_flow_pre () at ../../gcc/tree-cfgcleanup.cc:908 #5 0x018678f2 in cleanup_tree_cfg_noloop (ssa_update_flags=0) at ../../gcc/tree-cfgcleanup.cc:1073 #6 0x01867bbb in cleanup_tree_cfg (ssa_update_flags=0) at ../../gcc/tree-cfgcleanup.cc:1183 #7 0x016893c6 in execute_function_todo (fn=0x7fffcf0580b8, data=0x60) at ../../gcc/passes.cc:2051 #8 0x016881d9 in do_per_function (callback=0x1689361 , data=0x60) at ../../gcc/passes.cc:1688 #9 0x0168972e in execute_todo (flags=96) at ../../gcc/passes.cc:2139 #10 0x0168a838 in execute_one_pass (pass=0x408fb20) at ../../gcc/passes.cc:2675 #11 0x0168aa9b in execute_pass_list_1 (pass=0x408fb20) at ../../gcc/passes.cc:2738 #12 0x0168ab25 in execute_pass_list (fn=0x7fffcf0580b8, pass=0x408f6a0) at ../../gcc/passes.cc:2749 #13 0x010f6cbf in cgraph_node::analyze (this=0x7fffcf07d880) at ../../gcc/cgraphunit.cc:685 #14 0x010f8daa in analyze_functions (first_time=true) at ../../gcc/cgraphunit.cc:1240 #15 0x010fc094 in symbol_table::finalize_compilation_unit (this=0x770c6000) at ../../gcc/cgraphunit.cc:2500 #16 0x017eb979 in compile_file () at ../../gcc/toplev.cc:479 #17 0x017eea61 in do_compile (no_backend=false) at ../../gcc/toplev.cc:2168 #18 0x017eee49 in toplev::main (this=0x7fffdf62, argc=33, argv=0x7fffe098) at ../../gcc/toplev.cc:2320 #19 0x02fd18b1 in main (argc=33, argv=0x7fffe098) at ../../gcc/main.cc:39 Dump from tree-coro-early-expand-ifns put in attachment, because of template-spew. Compiled with e3d2b0d040e9baf6c0548b865ed5244dec464cc1.
[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611 John Eivind Helset changed: What|Removed |Added CC||jehelset at gmail dot com --- Comment #2 from John Eivind Helset --- Maybe related: https://godbolt.org/z/vsc8MYTcn In my case it seemed like co_awaiting expressions that involved compiler-generator constructors binding references to pr-values was problematic, or something along these lines. Was a problem on 11.1. Couldn't reproduce on 10.2.
[Bug c++/100673] [coroutines] Non-template, UDT await_suspend return-type results in ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100673 --- Comment #1 from John Eivind Helset --- Created attachment 50854 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50854=edit Add CLASSTYPE_TEMPLATE_INFO guard and test-case. Tried to guard the the conditional with CLASSTYPE_TEMPLATE_INFO as it seemed like the common approach in the codebase, to verify that the return-type was a template. And a testcase. Remove the guard to observe ICE in the test-case.
[Bug c++/100673] New: [coroutines] Non-template, UDT await_suspend return-type results in ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100673
Bug ID: 100673
Summary: [coroutines] Non-template, UDT await_suspend
return-type results in ICE.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jehelset at gmail dot com
Target Milestone: ---
Created attachment 50844
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50844=edit
ICE on non-template UDT await_suspend return-type.
A non-template udt return-type from await_suspend will ICE on trunk:
https://godbolt.org/z/Gn7djfrac
#0 build_co_await (loc=674010823, a=0x7163f1c0, suspend_kind=) at ../../gcc/cp/coroutines.cc:993
993 tree tt = CLASSTYPE_TI_TEMPLATE (susp_return_type);
Relevant code:
else if (TREE_CODE (susp_return_type) == RECORD_TYPE
&& CLASS_TYPE_P (susp_return_type))
{
tree tt = CLASSTYPE_TI_TEMPLATE (susp_return_type);
if (tt == coro_handle_templ)
ok = true;
}
Seems to be checking the validity of the await_suspend call, to produce a
helpful diagnostic. Perhaps the conditional also needs to verify that
CLASSTYPE_TEMPLATE_INFO (coro_handle_templ) is non-NULL, before using
CLASSTYPE_TI_TEMPLATE.
Seemed to be the case on 10.3, 11.1 and on 12.0. 10.2 failed to compile it
without crashing.
[Bug c++/97587] New: [coroutines] promise_type constructor is called with original parameters, not parameter copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97587 Bug ID: 97587 Summary: [coroutines] promise_type constructor is called with original parameters, not parameter copies Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jehelset at gmail dot com Target Milestone: --- Created attachment 49443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49443=edit Program that results in assertion-failure due to wrong arguments to promise. The promise-type constructor should be called with the parameter copies from the coroutine-frame. I couldn't quite understand that this is supposed to be the case from the current draft of the standard, but I got some help from Lewis Baker who also referred me to this rewording, where in the previous version it is clear: https://github.com/cplusplus/draft/commit/0b4ab68a54e197eba9d894a8f91270bb0dcdb546 The attached code triggers an assertion that show that this is not the case on gcc. I initially had the problem on gcc-10.2.0, but reproduced it on gcc-trunk on godbolt. Compile either version with -fcoroutines, or see https://gcc.godbolt.org/z/j16Wqx. I speculated that the logic here, https://github.com/gcc-mirror/gcc/blob/master/gcc/cp/coroutines.cc#L4491-L4494, was inverted. It seemed to pass the copied version of a by-reference parameter, but the original version of a by-value parameter. The opposite would not trigger the assertion. But I am not that familiar.
