On 11/16/22 01:19, Jakub Jelinek wrote:
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.
Indeed, though the hypothetical C++20 change could still use the "usable
in constant expressions" phrase.
Jason
