public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] c++: Don't defer local statics initialized with constant expressions [PR108702]
Date: Thu, 9 Feb 2023 17:14:39 +0100	[thread overview]
Message-ID: <Y+Ub70j63NkbaekZ@tucnak> (raw)

Hi!

The stmtexpr19.C testcase used to be rejected as it has a static
variable in statement expression in constexpr context, but as that
static variable is initialized by constant expression, when P2647R1
was implemented we agreed to make it valid.

Now, as reported, the testcase compiles fine, but doesn't actually link
because the static variable isn't defined anywhere, and with -flto ICEs
because of this problem.  This is because we never
varpool_node::finalize_decl those vars, the constant expression in which
the DECL_EXPR is present for the static VAR_DECL is folded (constant
evaluated) into just the address of the VAR_DECL.
Now, similar testcase included below (do we want to include it in the
testsuite too?) works fine, because in
cp_finish_decl -> make_rtl_for_nonlocal_decl
we have since PR70353 fix:
  /* We defer emission of local statics until the corresponding
     DECL_EXPR is expanded.  But with constexpr its function might never
     be expanded, so go ahead and tell cgraph about the variable now.  */
  defer_p = ((DECL_FUNCTION_SCOPE_P (decl)
              && !var_in_maybe_constexpr_fn (decl))
             || DECL_VIRTUAL_P (decl));
and so don't defer them in constexpr/consteval functions.  The following
patch extends that and doesn't defer vars initialized by constant
expressions either, because otherwise there is nothing to finalize those.
It is true that e.g. with -O0
int foo (int x) {
  if (x) { static int y = 1; ++y; }
  if (0) { static int z = 1; ++z; }
  return sizeof (({ static int w = 1; w; }));
}
we used to emit just y and z and with the patch emit also w, but with
optimizations that is optimized away properly.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

The testcase I was talking above that works because of the
&& !var_in_maybe_constexpr_fn (decl) case is:

extern "C" void abort ();

constexpr const int *
foo ()
{
  static constexpr int a = 1;
  return &a;
}

consteval const int *
bar ()
{
  static constexpr int a = 1;
  return &a;
}

[[gnu::noipa]] void
baz (const int *x)
{
  if (*x != 1)
    abort ();
}

int
main ()
{
  constexpr const int *p = foo ();
  constexpr const int *q = bar ();
  baz (p);
  baz (q);
  if (p == q)
    abort ();
}

2023-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR c++/108702
	* decl.cc (make_rtl_for_nonlocal_decl): Don't defer local statics
	initialized by constant expressions.

	* g++.dg/ext/stmtexpr19.C: Use dg-do link rather than dg-do compile.

--- gcc/cp/decl.cc.jj	2023-01-24 11:10:13.151076134 +0100
+++ gcc/cp/decl.cc	2023-02-09 13:29:50.527083618 +0100
@@ -7731,9 +7731,12 @@ make_rtl_for_nonlocal_decl (tree decl, t
 
   /* We defer emission of local statics until the corresponding
      DECL_EXPR is expanded.  But with constexpr its function might never
-     be expanded, so go ahead and tell cgraph about the variable now.  */
+     be expanded, so go ahead and tell cgraph about the variable now.
+     Also don't defer local statics initialized by constant expressions,
+     see PR108702.  */
   defer_p = ((DECL_FUNCTION_SCOPE_P (decl)
-	      && !var_in_maybe_constexpr_fn (decl))
+	      && !var_in_maybe_constexpr_fn (decl)
+	      && !DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl))
 	     || DECL_VIRTUAL_P (decl));
 
   /* Defer template instantiations.  */
--- gcc/testsuite/g++.dg/ext/stmtexpr19.C.jj	2022-11-19 09:26:30.168061316 +0100
+++ gcc/testsuite/g++.dg/ext/stmtexpr19.C	2023-02-09 13:32:48.887453520 +0100
@@ -1,6 +1,6 @@
 // PR c++/81073
 // { dg-options "" }
-// { dg-do compile { target c++11 } }
+// { dg-do link { target c++11 } }
 
 struct test { const int *addr; };
 

	Jakub


             reply	other threads:[~2023-02-09 16:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-09 16:14 Jakub Jelinek [this message]
2023-03-02 16:48 ` Jason Merrill
2023-03-03 15:18   ` [PATCH] c++, v2: " Jakub Jelinek
2023-03-03 16:15     ` Jason Merrill

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=Y+Ub70j63NkbaekZ@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@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).