c++: 'mutable' subobject of constexpr variable [PR109745]
r13-2701-g7107ea6fb933f1 made us correctly accept during constexpr evaluation 'mutable' member accesses of objects constructed during that evaluation, while continuing to reject such accesses for constexpr objects constructed outside of that evaluation, by considering the CONSTRUCTOR_MUTABLE_POISON flag during cxx_eval_component_reference. However, this flag is set only for the outermost CONSTRUCTOR of a constexpr variable initializer, so if we're accessing a 'mutable' member of a nested CONSTRUCTOR, the flag won't be set and we won't reject the access. This can lead to us accepting invalid code, as in the first testcase, or even wrong code generation due to our speculative constexpr evaluation, as in the second and third testcase. This patch fixes this by setting CONSTRUCTOR_MUTABLE_POISON recursively rather than only on the outermost CONSTRUCTOR. PR c++/109745 gcc/cp/ChangeLog: * typeck2.cc (poison_mutable_constructors): Define. (store_init_value): Use it instead of setting CONSTRUCTOR_MUTABLE_POISON directly. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-mutable4.C: New test. * g++.dg/cpp0x/constexpr-mutable5.C: New test. * g++.dg/cpp1y/constexpr-mutable2.C: New test.
Showing
- gcc/cp/typeck2.cc 22 additions, 4 deletionsgcc/cp/typeck2.cc
- gcc/testsuite/g++.dg/cpp0x/constexpr-mutable4.C 15 additions, 0 deletionsgcc/testsuite/g++.dg/cpp0x/constexpr-mutable4.C
- gcc/testsuite/g++.dg/cpp0x/constexpr-mutable5.C 39 additions, 0 deletionsgcc/testsuite/g++.dg/cpp0x/constexpr-mutable5.C
- gcc/testsuite/g++.dg/cpp1y/constexpr-mutable2.C 20 additions, 0 deletionsgcc/testsuite/g++.dg/cpp1y/constexpr-mutable2.C
Loading
Please register or sign in to comment