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