https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123740
Bug ID: 123740
Summary: internal compiler error: in convert_move, at
expr.cc:227 when lambda captures fixed-size array of
template struct by value
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: attackerj1113 at gmail dot com
Target Milestone: ---
The following code causes ICE on x86-64 gcc since version 4.8.1/4.5.3 and still
reproducible on trunk:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
template<typename T>
struct S {
T i;
};
void l() {
S<int> arr[4] = { 1, 2, 3, 4 }; //since 4.8.1
//S<int> arr[1] = { 1 }; //since 4.5.3
int x = [&arr] { return arr[0].i; }(); //OK
int y = [arr] { return arr[0].i; }(); //crash here
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please check https://godbolt.org/z/TPssz1o48
GCC crashes with an ICE in convert_move (expr.cc:227) during the RTL expand
pass when a lambda captures a fixed-size array of an instantiated template
struct by value and accesses the array element's member.
These codes do not trigger the crash：
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
template<typename T>
struct S {
T i;
};
void l() {
S<int> a{1};
S<int> arr[1] = { a };
int x = [arr] { return arr[0].i; }();
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
https://godbolt.org/z/7qMcGfxx8
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
struct S {
int i;
};
void l() {
S arr[1] = { 1 };
int x = [arr] { return arr[0].i; }();
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
https://godbolt.org/z/MrY7vEGv3
Output:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
during RTL pass: expand
<source>: In function 'void l()':
<source>:11:13: internal compiler error: in convert_move, at expr.cc:227
11 | int y = [arr] { return arr[0].i; }(); //crash here
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
0x2950e48 diagnostics::context::diagnostic_impl(rich_location*,
diagnostics::metadata const*, diagnostics::option_id, char const*,
__va_list_tag (*) [1], diagnostics::kind)
???:0
0x2945b8b internal_error(char const*, ...)
???:0
0xb1ed4e fancy_abort(char const*, int, char const*)
???:0
0x10ca8cb store_expr(tree_node*, rtx_def*, int, bool, bool)
???:0
/cefs/66/66148c1d7810c775ba4cd2e4_gcc-trunk-20260121/bin/../libexec/gcc/x86_64-linux-gnu/16.0.1/cc1plus
-quiet -imultiarch x86_64-linux-gnu -iprefix
/cefs/66/66148c1d7810c775ba4cd2e4_gcc-trunk-20260121/bin/../lib/gcc/x86_64-linux-gnu/16.0.1/
-D_GNU_SOURCE <source> -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -masm=intel -mtune=generic -march=x86-64 -g -fdiagnostics-color=always
-fno-verbose-asm -o /app/output.s
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By the way, Clang fixed a similar
bug:https://github.com/llvm/llvm-project/issues/57135
