From: Jonathan Wakely <jwakely@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
gcc-patches@gcc.gnu.org, Marek Polacek <polacek@redhat.com>
Subject: Re: [PATCH] c++, v2: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions
Date: Wed, 16 Nov 2022 00:26:03 +0000 [thread overview]
Message-ID: <CACb0b4nBCW+2Smro8z80VgmbEp1HrMrRhmUK17W191wXwmJaWw@mail.gmail.com> (raw)
In-Reply-To: <c5025573-d5d6-1d6e-a629-a9624ea14d5c@redhat.com>
On Tue, 15 Nov 2022 at 23:36, Jason Merrill <jason@redhat.com> wrote:
>
> On 11/13/22 01:45, Jakub Jelinek wrote:
> > On Fri, Nov 11, 2022 at 06:07:04PM +0100, Jakub Jelinek wrote:
> >> The following patch on top of Marek's P2448 PR106649 patch
> >> (mainly because that patch implements the previous __cpp_constexpr
> >> feature test macro bump so this can't go in earlier; OT,
> >> P2280R4 doesn't have any feature test macro?) implements this
> >> simple paper.
> >>
> >> Ok for trunk if it passes bootstrap/regtest and is voted into C++23?
> >
> > Here is an updated patch that passed bootstrap/regtest, the only
> > change is another testcase tweak.
> >
> > 2022-11-13 Jakub Jelinek <jakub@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?
I don't. The lack of this feature caused some awkwardness implementing
a C++23 library feature in <charconv>, but that means my desire for it
was only in C++23 mode. And that has been mitigated by changes Patrick
made to work around it anyway.
I think it does make sense for C++20, where constexpr is pretty close
to "normal" code, what with dynamic allocations, std::string etc. but
I don't see a great need for it before C++20.
>
> > (potential_constant_expression_1): Likewise.
> > gcc/testsuite/
> > * g++.dg/cpp23/constexpr-nonlit17.C: New test.
> > * g++.dg/cpp23/feat-cxx2b.C: Adjust expected __cpp_constexpr
> > value.
> > * g++.dg/ext/stmtexpr19.C: Don't expect an error for C++23 or later.
> >
> > --- gcc/c-family/c-cppbuiltin.cc.jj 2022-11-11 17:14:52.021613271 +0100
> > +++ gcc/c-family/c-cppbuiltin.cc 2022-11-11 17:17:45.065265246 +0100
> > @@ -1074,7 +1074,7 @@ c_cpp_builtins (cpp_reader *pfile)
> > /* Set feature test macros for C++23. */
> > cpp_define (pfile, "__cpp_size_t_suffix=202011L");
> > cpp_define (pfile, "__cpp_if_consteval=202106L");
> > - cpp_define (pfile, "__cpp_constexpr=202207L");
> > + cpp_define (pfile, "__cpp_constexpr=202211L");
> > cpp_define (pfile, "__cpp_multidimensional_subscript=202110L");
> > cpp_define (pfile, "__cpp_named_character_escapes=202207L");
> > cpp_define (pfile, "__cpp_static_call_operator=202207L");
> > --- gcc/cp/constexpr.cc.jj 2022-11-11 17:14:52.024613231 +0100
> > +++ gcc/cp/constexpr.cc 2022-11-11 17:16:54.384952917 +0100
> > @@ -7085,7 +7085,8 @@ cxx_eval_constant_expression (const cons
> > && (TREE_STATIC (r)
> > || (CP_DECL_THREAD_LOCAL_P (r) && !DECL_REALLY_EXTERN (r)))
> > /* Allow __FUNCTION__ etc. */
> > - && !DECL_ARTIFICIAL (r))
> > + && !DECL_ARTIFICIAL (r)
> > + && (cxx_dialect < cxx23 || !decl_maybe_constant_var_p (r)))
> > {
> > if (!ctx->quiet)
> > {
> > @@ -9577,7 +9578,10 @@ potential_constant_expression_1 (tree t,
> > tmp = DECL_EXPR_DECL (t);
> > if (VAR_P (tmp) && !DECL_ARTIFICIAL (tmp))
> > {
> > - if (CP_DECL_THREAD_LOCAL_P (tmp) && !DECL_REALLY_EXTERN (tmp))
> > + if (CP_DECL_THREAD_LOCAL_P (tmp)
> > + && !DECL_REALLY_EXTERN (tmp)
> > + && (cxx_dialect < cxx23
> > + || !decl_maybe_constant_var_p (tmp)))
> > {
> > if (flags & tf_error)
> > constexpr_error (DECL_SOURCE_LOCATION (tmp), fundef_p,
> > @@ -9585,7 +9589,9 @@ potential_constant_expression_1 (tree t,
> > "%<constexpr%> context", tmp);
> > return false;
> > }
> > - else if (TREE_STATIC (tmp))
> > + else if (TREE_STATIC (tmp)
> > + && (cxx_dialect < cxx23
> > + || !decl_maybe_constant_var_p (tmp)))
> > {
> > if (flags & tf_error)
> > constexpr_error (DECL_SOURCE_LOCATION (tmp), fundef_p,
> > --- gcc/testsuite/g++.dg/cpp23/constexpr-nonlit17.C.jj 2022-11-11 17:59:59.972852793 +0100
> > +++ gcc/testsuite/g++.dg/cpp23/constexpr-nonlit17.C 2022-11-11 17:59:38.725141231 +0100
> > @@ -0,0 +1,12 @@
> > +// P2647R1 - Permitting static constexpr variables in constexpr functions
> > +// { dg-do compile { target c++23 } }
> > +
> > +constexpr char
> > +test ()
> > +{
> > + static const int x = 5;
> > + static constexpr char c[] = "Hello World";
> > + return *(c + x);
> > +}
> > +
> > +static_assert (test () == ' ');
> > --- gcc/testsuite/g++.dg/cpp23/feat-cxx2b.C.jj 2022-11-11 17:14:52.194610922 +0100
> > +++ gcc/testsuite/g++.dg/cpp23/feat-cxx2b.C 2022-11-11 17:48:56.038865825 +0100
> > @@ -134,8 +134,8 @@
> >
> > #ifndef __cpp_constexpr
> > # error "__cpp_constexpr"
> > -#elif __cpp_constexpr != 202207
> > -# error "__cpp_constexpr != 202207"
> > +#elif __cpp_constexpr != 202211
> > +# error "__cpp_constexpr != 202211"
> > #endif
> >
> > #ifndef __cpp_decltype_auto
> > --- gcc/testsuite/g++.dg/ext/stmtexpr19.C.jj 2020-01-14 20:02:46.839608995 +0100
> > +++ gcc/testsuite/g++.dg/ext/stmtexpr19.C 2022-11-12 09:17:40.706245495 +0100
> > @@ -8,7 +8,7 @@ const test* setup()
> > {
> > static constexpr test atest =
> > {
> > - ({ static const int inner = 123; &inner; }) // { dg-error "static" }
> > + ({ static const int inner = 123; &inner; }) // { dg-error "static" "" { target c++20_down } }
> > };
> >
> > return &atest;
> >
> >
> > Jakub
> >
>
prev parent reply other threads:[~2022-11-16 0:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-11 17:07 [PATCH] c++: " Jakub Jelinek
2022-11-13 11:45 ` [PATCH] c++, v2: " Jakub Jelinek
2022-11-15 23:36 ` Jason Merrill
2022-11-15 23:50 ` Jakub Jelinek
2022-11-16 0:27 ` Jonathan Wakely
2022-11-16 6:19 ` Jakub Jelinek
2022-11-16 13:20 ` Jason Merrill
2022-11-16 14:08 ` Jakub Jelinek
2022-11-16 14:33 ` Jason Merrill
2022-11-16 14:46 ` Jakub Jelinek
2022-11-16 20:26 ` Jason Merrill
2022-11-17 9:13 ` [PATCH] c++, v3: " Jakub Jelinek
2022-11-17 14:42 ` Jason Merrill
2022-11-17 18:42 ` Jakub Jelinek
2022-11-17 20:42 ` [PATCH] c++, v4: " Jakub Jelinek
2022-11-18 0:15 ` Marek Polacek
2022-11-18 7:48 ` Jakub Jelinek
2022-11-18 15:03 ` Marek Polacek
2022-11-18 15:14 ` Jakub Jelinek
2022-11-18 16:24 ` Jason Merrill
2022-11-18 16:34 ` Jakub Jelinek
2022-11-18 16:52 ` Jason Merrill
2022-11-18 0:28 ` Jason Merrill
2022-11-18 9:10 ` [PATCH] c++, v5: " Jakub Jelinek
2022-11-16 0:26 ` Jonathan Wakely [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACb0b4nBCW+2Smro8z80VgmbEp1HrMrRhmUK17W191wXwmJaWw@mail.gmail.com \
--to=jwakely@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jason@redhat.com \
--cc=polacek@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).