On Wed, Nov 16, 2022 at 12:27:02AM +0000, Jonathan Wakely wrote: > On Tue, 15 Nov 2022 at 23:50, Jakub Jelinek <ja...@redhat.com> wrote: > > > > On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote: > > > > Here is an updated patch that passed bootstrap/regtest, the only > > > > change is another testcase tweak. > > > > > > > > 2022-11-13 Jakub Jelinek <ja...@redhat.com> > > > > > > > > gcc/c-family/ > > > > * c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_constexpr > > > > value from 202207L to 202211L. > > > > gcc/cp/ > > > > * constexpr.cc (cxx_eval_constant_expression): Implement C++23 > > > > P2647R1 - Permitting static constexpr variables in constexpr > > > > functions. > > > > Allow decl_maybe_constant_var_p static or thread_local vars for > > > > C++23. > > > > > > This was accepted as a DR, so it shouldn't be limited to C++23 mode. > > > Certainly it should be allowed in C++20 mode; I don't have a strong > > > opinion > > > about C++14/17. Jonathan, do you? > > > > How will a feature with feature test macro with multiple values work as DR? > > Or will everything but the macro be treated as a DR (so __cpp_constexpr >= > > 202211L only for C++23)? > > Yes, I think so. We just won't be able to advertise this feature as > supported in C++20.
Ok. But there is another issue, the https://eel.is/c++draft/expr.const#5.2 spot that P2647R1 is changing didn't exist in C++20, it was only added with P2242R3. So, if one would treat P2647R1 as a DR for C++20, one has to come up with a different standard modification. Probably change the last bullet of: [dcl.constexpr]/3 its function-body shall not enclose a goto statement, an identifier label, a definition of a variable of non-literal type or of static or thread storage duration. to a definition of a variable of non-literal type or of a non-constexpr variable of static or thread storage duration. or so. Jakub
