aboutsummaryrefslogtreecommitdiff
path: root/libiberty/cp-demangle.c
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2021-03-30 18:15:32 +0200
committerJakub Jelinek <jakub@redhat.com>2021-03-30 18:15:32 +0200
commit953624089be3f51c2ebacba65be8521bf6ae8430 (patch)
treead0a64921cac5f6e96db8199a1e60fdaa2759b8e /libiberty/cp-demangle.c
parentc277abd9cd3d10db59f9965d7d6356868da42a9f (diff)
downloadgcc-953624089be3f51c2ebacba65be8521bf6ae8430.zip
gcc-953624089be3f51c2ebacba65be8521bf6ae8430.tar.gz
gcc-953624089be3f51c2ebacba65be8521bf6ae8430.tar.bz2
c++: Fix ICE on PTRMEM_CST in lambda in inline var initializer [PR99790]
The following testcase ICEs (since the addition of inline var support), because the lambda contains PTRMEM_CST but finish_function is called for the lambda quite early during parsing it (from finish_lambda_function) when the containing class is still incomplete. That means that during genericization cplus_expand_constant keeps the PTRMEM_CST unmodified, but later nothing lowers it when the class is finalized. Using sizeof etc. on the class in such contexts is rejected by both g++ and clang++, and when the PTRMEM_CST appears e.g. in static var initializers rather than in functions, we handle it correctly because c_parse_final_cleanups -> lower_var_init will handle those cplus_expand_constant when all classes are already finalized. The following patch fixes it by calling cplus_expand_constant again during gimplification, as we are now unconditionally unit at a time, I'd think everything that could be completed will be before we start gimplification. 2021-03-30 Jakub Jelinek <jakub@redhat.com> PR c++/99790 * cp-gimplify.c (cp_gimplify_expr): Handle PTRMEM_CST. * g++.dg/cpp1z/pr99790.C: New test.
Diffstat (limited to 'libiberty/cp-demangle.c')
0 files changed, 0 insertions, 0 deletions