aboutsummaryrefslogtreecommitdiff
path: root/gcc/genflags.c
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2021-03-30 18:15:32 +0200
committerJakub Jelinek <jakub@redhat.com>2021-04-22 16:53:20 +0200
commit718c32a39895ea12ff79f05d6001d7401e6e7e11 (patch)
tree02209421aade22872105468684469c7a5f30c82e /gcc/genflags.c
parent1ee66d06f25d5bf14e2f3b599fc391dc3d532722 (diff)
downloadgcc-718c32a39895ea12ff79f05d6001d7401e6e7e11.zip
gcc-718c32a39895ea12ff79f05d6001d7401e6e7e11.tar.gz
gcc-718c32a39895ea12ff79f05d6001d7401e6e7e11.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. (cherry picked from commit 7cdd30b43a63832d6f908b2dd64bd19a0817cd7b)
Diffstat (limited to 'gcc/genflags.c')
0 files changed, 0 insertions, 0 deletions