public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] c: Call c_fully_fold on __atomic_* operands in atomic_bitint_fetch_using_cas_loop [PR113518]
@ 2024-01-23  8:09 Jakub Jelinek
  2024-01-23 18:46 ` Joseph Myers
  0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2024-01-23  8:09 UTC (permalink / raw)
  To: Joseph Myers, Marek Polacek; +Cc: gcc-patches

Hi!

As the following testcase shows, I forgot to call c_fully_fold on the
__atomic_*/__sync_* operands called on _BitInt address, the expressions
are then used inside of TARGET_EXPR initializers etc. and are never fully
folded later, which means we can ICE e.g. on C_MAYBE_CONST_EXPR trees
inside of those.

The following patch fixes it, while the function currently is only called
in the C FE because C++ doesn't support BITINT_TYPE, I think guarding the
calls on !c_dialect_cxx () is safer.

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

2024-01-22  Jakub Jelinek  <jakub@redhat.com>

	PR c/113518
	* c-common.cc (atomic_bitint_fetch_using_cas_loop): Call c_fully_fold
	on lhs_addr, val and model for C.

	* gcc.dg/bitint-77.c: New test.

--- gcc/c-family/c-common.cc.jj	2024-01-03 12:07:03.384717147 +0100
+++ gcc/c-family/c-common.cc	2024-01-22 14:24:44.209262552 +0100
@@ -8082,6 +8082,12 @@ atomic_bitint_fetch_using_cas_loop (loca
   tree lhs_addr = (*orig_params)[0];
   tree val = convert (nonatomic_lhs_type, (*orig_params)[1]);
   tree model = convert (integer_type_node, (*orig_params)[2]);
+  if (!c_dialect_cxx ())
+    {
+      lhs_addr = c_fully_fold (lhs_addr, false, NULL);
+      val = c_fully_fold (val, false, NULL);
+      model = c_fully_fold (model, false, NULL);
+    }
   if (TREE_SIDE_EFFECTS (lhs_addr))
     {
       tree var = create_tmp_var_raw (TREE_TYPE (lhs_addr));
--- gcc/testsuite/gcc.dg/bitint-77.c.jj	2024-01-22 14:40:22.505993511 +0100
+++ gcc/testsuite/gcc.dg/bitint-77.c	2024-01-22 14:40:02.445276390 +0100
@@ -0,0 +1,25 @@
+/* PR c/113518 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-O2 -std=c23" } */
+
+#if __BITINT_MAXWIDTH__ >= 607
+_BitInt(607) v;
+#else
+_BitInt(63) v;
+#endif
+
+void
+foo (void)
+{
+  __atomic_fetch_or (&v, 1 << 31, __ATOMIC_RELAXED);
+}
+
+#if __BITINT_MAXWIDTH__ >= 16321
+_BitInt(16321) w;
+
+void
+bar (void)
+{
+  __atomic_fetch_add (&w, 1 << 31, __ATOMIC_SEQ_CST);
+}
+#endif

	Jakub


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] c: Call c_fully_fold on __atomic_* operands in atomic_bitint_fetch_using_cas_loop [PR113518]
  2024-01-23  8:09 [PATCH] c: Call c_fully_fold on __atomic_* operands in atomic_bitint_fetch_using_cas_loop [PR113518] Jakub Jelinek
@ 2024-01-23 18:46 ` Joseph Myers
  0 siblings, 0 replies; 2+ messages in thread
From: Joseph Myers @ 2024-01-23 18:46 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Marek Polacek, gcc-patches

On Tue, 23 Jan 2024, Jakub Jelinek wrote:

> Hi!
> 
> As the following testcase shows, I forgot to call c_fully_fold on the
> __atomic_*/__sync_* operands called on _BitInt address, the expressions
> are then used inside of TARGET_EXPR initializers etc. and are never fully
> folded later, which means we can ICE e.g. on C_MAYBE_CONST_EXPR trees
> inside of those.
> 
> The following patch fixes it, while the function currently is only called
> in the C FE because C++ doesn't support BITINT_TYPE, I think guarding the
> calls on !c_dialect_cxx () is safer.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
josmyers@redhat.com


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-01-23 18:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-23  8:09 [PATCH] c: Call c_fully_fold on __atomic_* operands in atomic_bitint_fetch_using_cas_loop [PR113518] Jakub Jelinek
2024-01-23 18:46 ` Joseph Myers

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).