diff options
author | Jakub Jelinek <jakub@redhat.com> | 2021-03-30 18:15:32 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2021-03-30 18:15:32 +0200 |
commit | 953624089be3f51c2ebacba65be8521bf6ae8430 (patch) | |
tree | ad0a64921cac5f6e96db8199a1e60fdaa2759b8e /libiberty/cp-demangle.c | |
parent | c277abd9cd3d10db59f9965d7d6356868da42a9f (diff) | |
download | gcc-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