[Bug c++/97848] [missed optimization] tls init function check emitted for consinit thread_local variables (C++20)

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97848

--- Comment #1 from Avi Kivity  ---
Still bad on trunk. Clang gets this right:

foo_good():   # @foo_good()
movqx@GOTTPOFF(%rip), %rax
movl%fs:(%rax), %eax
retq
set_foo(int):# @set_foo(int)
movqx@GOTTPOFF(%rip), %rax
movl%edi, %fs:(%rax)
retq

[Bug c++/92985] missed optimization opportunity for switch linear transformation

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92985

Avi Kivity  changed:

   What|Removed |Added

 CC||a...@cloudius-systems.com

--- Comment #5 from Avi Kivity  ---
Here's another example:


#include 

int strong_ordering_to_int(std::strong_ordering x) {
if (x == std::strong_ordering::equal) {
return 0;
} else if (x == std::strong_ordering::less) {
return -1;
} else if (x == std::strong_ordering::greater) {
return 1;
}
__builtin_unreachable();
}

Used to translate the new std::strong_ordering back to int (in this case for
compatibility with older code, but one can imagine many such translations from
opaque enums to another enum when crossing an API boundary).

gcc generates (-O3)

strong_ordering_to_int(std::strong_ordering):
xorl%eax, %eax
testb   %dil, %dil
je  .L1
xorl%eax, %eax
cmpb$-1, %dil
setne   %al
leal-1(%rax,%rax), %eax
.L1:
ret


Where it could have generated

movsx%dil, %eax
ret

[Bug c++/97438] New: [accepts-invalid] coroutines accepts prmomise type with both return_value() and return_void()

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97438

Bug ID: 97438
   Summary: [accepts-invalid] coroutines accepts prmomise type
with both return_value() and return_void()
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

The standard says:

[dcl.fct.def.coroutine]

6. The unqualified-ids return_­void and return_­value are looked up in the
scope of the promise type. If both are found, the program is ill-formed.


But gcc accepts such a promise type. Clang rejects it.

[Bug c++/97438] [accepts-invalid] coroutines accepts prmomise type with both return_value() and return_void()

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97438

--- Comment #2 from Avi Kivity  ---
Created attachment 49379
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49379&action=edit
test case

[Bug c++/97438] [accepts-invalid] coroutines accepts prmomise type with both return_value() and return_void()

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97438

--- Comment #5 from Avi Kivity  ---
No pressing reason to backport (for me gcc coroutines are useless anyway due to
95137)

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137

--- Comment #36 from Avi Kivity  ---
A reminder that coroutines are crippled without this fixed, as it is standard
practice these days to use sanitizers.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137

--- Comment #38 from Avi Kivity  ---
I do not have a patch, and unfortunately, it will take me several months at the
most optimistic least to get up to speed with gcc internals to fix this. I've
switched to clang, but I'd really like to switch back, I miss gcc's better
support for C++20 and also just irrationally prefer it.

I'll cross my fingers and toes for more luck with gcc 11.

[Bug c++/97848] New: [missed optimization] tls init function check emitted for consinit thread_local variables (C++20)

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97848

Bug ID: 97848
   Summary: [missed optimization] tls init function check emitted
for consinit thread_local variables (C++20)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

The code

=== begin code ===


extern thread_local constinit int x;

int foo_good() {
return x;
}

void set_foo(int y) {
x = y;
}

=== end code ===

knows that x will be statically initialized, but still emits the code to check
for the TLS init function and maybe call it:

=== begin objdump ===

foo_good():
movl$TLS init function for x, %eax
testq   %rax, %rax
je  .L7
subq$8, %rsp
callTLS init function for x
movqx@gottpoff(%rip), %rax
movl%fs:(%rax), %eax
addq$8, %rsp
ret
.L7:
movqx@gottpoff(%rip), %rax
movl%fs:(%rax), %eax
ret
set_foo(int):
movl$TLS init function for x, %eax
pushq   %rbx
movl%edi, %ebx
testq   %rax, %rax
je  .L12
callTLS init function for x
.L12:
movqx@gottpoff(%rip), %rax
movl%ebx, %fs:(%rax)
popq%rbx
ret

=== end objdump ===

Instead, we should see the same output as for __thread_local.

[Bug c++/100493] New: Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493

Bug ID: 100493
   Summary: Lambda default copy capture that captures "this"
cannot be used in both C++17 and C++20 modes
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

Consider the following masterpiece:



struct a {
int b;
void f(int x) {
(void)[=] { (void)(b + x); };
}
};


The C++20 compiler wants me to disambiguate the [=] capture to mean either [=,
this] or [=, *this]:

:6:15: warning: implicit capture of 'this' via '[=]' is deprecated in
C++20 [-Wdeprecated]
6 | (void)[=] { (void)(b + x); };
  |   ^
:6:15: note: add explicit 'this' or '*this' capture

Humoring it, I add ", this" to the capture list:


struct a {
int b;
void f(int x) {
(void)[=, this] { (void)(b + x); };
}
};


This works in C++20 mode, but in C++17 mode, I get:

source>:6:19: warning: explicit by-copy capture of 'this' redundant with
by-copy capture default
6 | (void)[=, this] { (void)(b + x); };
  |   ^~~~


These warnings are either always on, or enabled by -Wdeprecated. Given I want
-Wdeprecated for other deprecated features, it's impossible for me to write
similar code that works in both C++17 and C++20.

Perhaps the C++20 warning can be moved to a separate flag, to allow library
code that targets both C++17 and C++20.

[Bug libstdc++/100900] New: error: missing 'typename' prior to dependent type name in elements_view

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100900

Bug ID: 100900
   Summary: error: missing 'typename' prior to dependent type name
in  elements_view
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

clang++ complains:

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/ranges:3392:19:
error: missing 'typename' prior to dependent type name
'iterator_traits>::iterator_category'
using _Cat = iterator_traits>::iterator_category;

[Bug libstdc++/100900] error: missing 'typename' prior to dependent type name in elements_view

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100900

--- Comment #3 from Avi Kivity  ---
Note, I posted a patch for this to gcc-patches, to save you the effort of
typing those 9 letters.

[Bug libstdc++/100900] error: missing 'typename' prior to dependent type name in elements_view

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100900

--- Comment #8 from Avi Kivity  ---
I see you added the changelog entry. I'll be sure to do that next time I post a
patch.

[Bug c++/103319] New: [coroutines] ICE in is_this_parameter, at cp/semantics.c:10672

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103319

Bug ID: 103319
   Summary: [coroutines] ICE in is_this_parameter, at
cp/semantics.c:10672
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

Possibly related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102489

A very large test case gives me this:

distcc[3605276] ERROR: compile /home/avi/scylla/db/commitlog/commitlog.cc on
localhost failed
/home/avi/scylla/db/commitlog/commitlog.cc: In function ‘void
db::commitlog::segment::cycle(bool,
bool)operator()(db::commitlog::segment::cycle(bool,
bool)_ZZN2db9commitlog7segment5cycleEbbENKUlvE_clEv.frame*)’:
/home/avi/scylla/db/commitlog/commitlog.cc:901:9: internal compiler error: in
is_this_parameter, at cp/semantics.c:10672
  901 | }, [&]() -> future<> {


It is accepted by clang.

gcc 12 accepts the code, and gcc 11 with this patch backported:

commit daa9c6b015a33fa98af0ee7cd6919120248ab5f9 (tag: is_this_parameter)
Author: Jason Merrill 
Date:   Sat Nov 13 17:16:46 2021 -0500

c++: is_this_parameter and coroutines proxies

Compiling coroutines/pr95736.C with the implicit constexpr patch broke
because is_this_parameter didn't recognize the coroutines proxy for 'this'.

gcc/cp/ChangeLog:

* semantics.c (is_this_parameter): Check DECL_HAS_VALUE_EXPR_P
instead of is_capture_proxy.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 60e0982cc48..15404426bce 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -11380,11 +11380,12 @@ float_const_decimal64_p (void)
 bool
 is_this_parameter (tree t)
 {
   if (!DECL_P (t) || DECL_NAME (t) != this_identifier)
 return false;
-  gcc_assert (TREE_CODE (t) == PARM_DECL || is_capture_proxy (t)
+  gcc_assert (TREE_CODE (t) == PARM_DECL
+ || (TREE_CODE (t) == VAR_DECL && DECL_HAS_VALUE_EXPR_P (t))
  || (cp_binding_oracle && TREE_CODE (t) == VAR_DECL));
   return true;
 }

 /* Insert the deduced return type for an auto function.  */



Also works. Requesting this backport for gcc 11 (I don't know if this is a
regression or not since I'm attempting to migrate from clang).

I don't have a reduced test case. I can try to reduce it, but perhaps knowledge
of the fix will make coming up with a small test case simple.

[Bug c++/103328] New: IC in remap_gimple_stmt, at tree-inline.c:1921

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328

Bug ID: 103328
   Summary: IC in remap_gimple_stmt, at tree-inline.c:1921
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

Created attachment 51836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51836&action=edit
reduced reproducer. Thanks cvise.

The attached test case, compiled with 


   g++  -O2  --std=gnu++20   -c -o out.o raft-server.i


produces

during GIMPLE pass: einline
raft-server.i: In static member function ‘static seastar::futurize::type
seastar::futurize::invoke(Func&&, FuncArgs&& ...) [with Func = const
std::server_impl::send_message
>({anonymous}::server_id,
std::variant<{anonymous}::append_request>)&;
FuncArgs = {}; T = const
std::server_impl::send_message
>({anonymous}::server_id,
std::variant<{anonymous}::append_request>)&]’:
raft-server.i:405:7: internal compiler error: in remap_gimple_stmt, at
tree-inline.c:1921
  405 |   func();
  |   ^~
0xd11c4f remap_gimple_stmt
../../gcc/gcc/tree-inline.c:1921
0xd14357 copy_bb
../../gcc/gcc/tree-inline.c:2022
0xd15744 copy_cfg_body
../../gcc/gcc/tree-inline.c:3054
0xd15744 copy_body
../../gcc/gcc/tree-inline.c:3309
0xd189af expand_call_inline
../../gcc/gcc/tree-inline.c:5129
0xd19f59 gimple_expand_calls_inline
../../gcc/gcc/tree-inline.c:5319
0xd19f59 optimize_inline_calls(tree_node*)
../../gcc/gcc/tree-inline.c:5492
0x15ee69e early_inliner(function*)
../../gcc/gcc/ipa-inline.c:3007
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The test case is invalid code now, but pre-reduction was valid (and accepted by
clang) and produced the same error.

Tested with current gcc releases/gcc-11 branch HEAD
(f62039efd679ffa8719732c71535457eb3ec61e0) + one patch backported
(daa9c6b015a33fa98af0ee7cd6919120248ab5f9).

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328

--- Comment #5 from Avi Kivity  ---
Sure, I'll redo the reduction.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328

--- Comment #6 from Avi Kivity  ---
Unfortunately, clang doesn't accept the preprocessed source, only the original.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328

--- Comment #8 from Avi Kivity  ---
Aha, I'll validate against g++ -O0.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328

--- Comment #9 from Avi Kivity  ---
btw, I also noticed these warnings:

raft/server.cc: In member function ‘virtual seastar::future<>
raft::server_impl::abort()’:
raft/server.cc:932:1: warning:
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame’ has a field
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame::append_futures_1_2’
whose type uses the anonymous namespace [-Wsubobject-linkage]
  932 | }
  | ^
raft/server.cc:932:1: warning:
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame’ has a field
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame::all_futures_1_2’
whose type uses the anonymous namespace [-Wsubobject-linkage]
raft/server.cc:932:1: warning:
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame’ has a field
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame::D.579510_2_9’
whose type uses the anonymous namespace [-Wsubobject-linkage]
raft/server.cc:932:1: warning:
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame’ has a field
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame::D.579509_2_9’
whose type uses the anonymous namespace [-Wsubobject-linkage]

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328

--- Comment #10 from Avi Kivity  ---
It's reducing with the stricter test, expect something in around 24 hours.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328

--- Comment #17 from Avi Kivity  ---
Created attachment 51843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51843&action=edit
valid-code reproducer (compiles with -O0)

Uploaded a valid-code reproducer (if you don't mind warnings). Compiles with
-O0, ICEs with -O2.

[Bug c++/98056] coroutines: ICE tree check: expected record_type or union_type or qual_union_type, have array_type since r11-2183-g0f66b8486cea8668

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056

--- Comment #13 from Avi Kivity  ---
In current master (90c3a62272313bb08cd5d9a948ff2d71af73b294), we don't ICE, but
instead get this error:

coroutine-initializer-list.cc: In member function ‘task task::e()’:
coroutine-initializer-list.cc:23:3: error: array used as initializer

[Bug c++/89062] class template argument deduction failure with parentheses

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062

Avi Kivity  changed:

   What|Removed |Added

 CC||a...@cloudius-systems.com

--- Comment #11 from Avi Kivity  ---
Seeing this in 11.2, so asking for a backport.

[Bug c++/101420] New: ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

Bug ID: 101420
   Summary: ICE in build_special_member_call, at cp/call.c:10179
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

The attached file ICEs with gcc 11.1.1. It compiles cleanly with clang 11.

Command line:

g++ -MD -MT build/dev/table.o -MF build/dev/table.o.d
-I/home/avi/scylla/seastar/include
-I/home/avi/scylla/build/dev/seastar/gen/include -std=gnu++20 -U_FORTIFY_SOURCE
-Wno-maybe-uninitialized -DSEASTAR_SSTRING -Werror=unused-result
-fstack-clash-protection -DSEASTAR_API_LEVEL=6
-DSEASTAR_ENABLE_ALLOC_FAILURE_INJECTION -DSEASTAR_TYPE_ERASE_MORE -DFMT_LOCALE
-DFMT_SHARED -I/usr/include/p11-kit-1  -DDEVEL
-DSEASTAR_ENABLE_ALLOC_FAILURE_INJECTION -DSCYLLA_ENABLE_ERROR_INJECTION
-Wstack-usage=21504 -Wno-error=stack-usage= -O2 -iquote. -iquote build/dev/gen
--std=gnu++20 -Wno-array-bounds -Wno-unused-but-set-variable -Wno-sign-compare
-Wno-narrowing -ffile-prefix-map=/home/avi/scylla=.  -march=westmere
-DBOOST_TEST_DYN_LINK   -Iabseil -fvisibility=hidden  -Wall -Werror
-Wno-mismatched-tags -Wno-maybe-uninitialized -Wno-tautological-compare
-Wno-missing-braces -Wno-misleading-indentation -Wno-overflow
-Wno-noexcept-type -Wno-nonnull-compare -Wno-error=cpp -Wno-ignored-attributes
-Wno-overloaded-virtual -Wno-stringop-overflow -Wno-redundant-move
-Wno-unused-variable -Wno-psabi -Wno-error=deprecated-declarations
-DXXH_PRIVATE_API -DSEASTAR_TESTING_MAIN -DHAVE_LZ4_COMPRESS_DEFAULT  -c -o
build/dev/table.o ice.cc

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #1 from Avi Kivity  ---
File is in https://scratch.scylladb.com/ice.cc (too large to upload to
bugzilla). I'll try to reduce it a little.

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #2 from Avi Kivity  ---
Simplified command line:

g++ -march=westmere --std=c++20 -fext-numeric-literals  ice.cc

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

Avi Kivity  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #3 from Avi Kivity  ---
Adding Iain since the ICE happens in a coroutine. Meanwhile my desktop is
reducing the testcase.

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #5 from Avi Kivity  ---
How does one ask gcc to generate a backtrace on ICE?

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #7 from Avi Kivity  ---
ice.cc: In member function 'seastar::future<>
table::generate_and_propagate_view_updates(const schema_ptr&, reader_permit,
std::vector&&, mutation&&, flat_mutation_reader_opt,
tracing::trace_state_ptr, gc_clock::time_point) const':
ice.cc:199329:1: internal compiler error: in build_special_member_call, at
cp/call.c:10179
199329 | }
   | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



libbacktrace should have been available, since it's the distro package. Is
there a breakpoint I can set in gcc to obtain the backtrace?

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #8 from Avi Kivity  ---
Ugh, I forgot g++ isn't the compiler proper and setting a breakpoint is going
to be tricky.

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #9 from Avi Kivity  ---
I found -dH and have a core:

(gdb) bt
#0  0x7f26600e02a2 in ?? () from /lib64/libc.so.6
#1  0x7f26600c98a4 in ?? () from /lib64/libc.so.6
#2  0x00ff1af4 in diagnostic_action_after_output(diagnostic_context*,
diagnostic_t) [clone .cold] ()
#3  0x0142bdab in diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) ()
#4  0x0162d12a in diagnostic_impl(rich_location*, diagnostic_metadata
const*, int, char const*, __va_list_tag (*) [1], diagnostic_t) ()
#5  0x00ff2ac8 in internal_error(char const*, ...) ()
#6  0x00ff2ba3 in fancy_abort(char const*, int, char const*) ()
#7  0x00620c80 in build_special_member_call(tree_node*, tree_node*,
vec**, tree_node*, int, int) [clone .cold] ()
#8  0x006400fa in flatten_await_stmt(var_nest_node*,
hash_set >*,
hash_set >*, tree_node**) ()
#9  0x00640252 in flatten_await_stmt(var_nest_node*,
hash_set >*,
hash_set >*, tree_node**) ()
#10 0x00640252 in flatten_await_stmt(var_nest_node*,
hash_set >*,
hash_set >*, tree_node**) ()
#11 0x00640262 in flatten_await_stmt(var_nest_node*,
hash_set >*,
hash_set >*, tree_node**) ()
#12 0x00640252 in flatten_await_stmt(var_nest_node*,
hash_set >*,
hash_set >*, tree_node**) ()
#13 0x00640252 in flatten_await_stmt(var_nest_node*,
hash_set >*,
hash_set >*, tree_node**) ()
#14 0x00640252 in flatten_await_stmt(var_nest_node*,
hash_set >*,
hash_set >*, tree_node**) ()
#15 0x0064116f in await_statement_walker(tree_node**, int*, void*) ()
#16 0x012fb259 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ()
#17 0x0064094e in await_statement_walker(tree_node**, int*, void*) ()
#18 0x012fb259 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ()
#19 0x00640904 in await_statement_walker(tree_node**, int*, void*) ()
#20 0x012fb259 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ()
#21 0x0064094e in await_statement_walker(tree_node**, int*, void*) ()
#22 0x012fb259 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ()
#23 0x012fb3da in walk_tree_1(tree_node**, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ()
#24 0x0064094e in await_statement_walker(tree_node**, int*, void*) ()
#25 0x012fb259 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ()
#26 0x00640904 in await_statement_walker(tree_node**, int*, void*) ()
#27 0x012fb259 in walk_tree_1(tree_node**, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ()
#28 0x0063d33b in morph_fn_to_coro(tree_node*, tree_node**,
tree_node**) ()
#29 0x00655a90 in finish_function(bool) [clone .cold] ()
#30 0x010a3210 in
cp_parser_function_definition_after_declarator(cp_parser*, bool) ()
#31 0x006a46b4 in cp_parser_init_declarator(cp_parser*, int,
cp_decl_specifier_seq*, vec*, bool,
bool, int, bool*, tree_node**, unsigned int*, tree_node**) [clone .cold] ()
#32 0x010937dc in cp_parser_simple_declaration(cp_parser*, bool,
tree_node**) ()
#33 0x006a1966 in cp_parser_declaration(cp_parser*, tree_node*) [clone
.cold] ()
#34 0x014578dc in c_parse_file() ()
#35 0x01488094 in c_common_parse_file() ()
#36 0x01525c41 in compile_file() ()
#37 0x0103ba92 in toplev::main(int, char**) ()
#38 0x0103cc23 in main ()

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #10 from Avi Kivity  ---
Reproduces on trunk:

#7  0x00b439af in cp_build_modify_expr (loc=1376651745,
lhs=0x7f0c55c12c60, modifycode=, rhs=0x7f0c55e63ee0,
complain=) at ../../gcc/gcc/cp/typeck.c:8919

8919error_at (loc, "array used as initializer");


8914  /* This routine is used for both initialization and
assignment.
8915 Make sure the diagnostic message differentiates the
context.  */
8916  if (complain & tf_error)
8917{
8918  if (modifycode == INIT_EXPR)
8919error_at (loc, "array used as initializer");
8920  else
8921error_at (loc, "invalid array assignment");
8922}
8923  return error_mark_node;

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #13 from Avi Kivity  ---
The coroutine that breaks is

future<> table::generate_and_propagate_view_updates(const schema_ptr& base,
reader_permit permit,
std::vector&& views,
mutation&& m,
flat_mutation_reader_opt existings,
tracing::trace_state_ptr tr_state,
gc_clock::time_point now) const {
auto base_token = m.token();
db::view::view_update_builder builder = co_await
db::view::make_view_update_builder(
base,
std::move(views),
flat_mutation_reader_from_mutations(std::move(permit),
{std::move(m)}),
std::move(existings),
now);
while (true) {
try {
auto updates = co_await builder.build_some();
if (updates.empty()) {
break;
}
tracing::trace(tr_state, "Generated {} view update mutations",
updates.size());
auto units =
seastar::consume_units(*_config.view_update_concurrency_semaphore,
memory_usage_of(updates));
co_await db::view::mutate_MV(base_token, std::move(updates),
_view_stats, *_config.cf_stats, tr_state,
std::move(units), service::allow_hints::yes,
db::view::wait_for_all_updates::no).handle_exception([] (auto ignored) { });
} catch (...) {
}
}
co_await builder.close();
}


Nothing special in there, in particular nothing that looks like an array.

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #14 from Avi Kivity  ---
Very likely it's a dup:

db::view::view_update_builder builder = co_await
db::view::make_view_update_builder(
base,
std::move(views),
flat_mutation_reader_from_mutations(std::move(permit),
{std::move(m)}),
std::move(existings),
now);


The {std::move(m)} thing becomes an std::initializer_list used to initialize an
std::vector, and that other bug also had an std::initializer_list.

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #15 from Avi Kivity  ---
If I move the sub-expression that contains the std::initializer_list outside
co_await, the internal error is avoided.

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #16 from Avi Kivity  ---
So I confirm it's a dup. Are you still interested in a reduced testcase?

[Bug c++/101420] ICE in build_special_member_call, at cp/call.c:10179

[avi--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420

--- Comment #18 from Avi Kivity  ---
It's still >7MB long, so I'll stop reducing.