From: Jason Merrill <jason@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>, Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org, Jonathan Wakely <jwakely@redhat.com>
Subject: Re: [PATCH] c-family, c++, v2: Fix up handling of types which may have padding in __atomic_{compare_}exchange
Date: Wed, 6 Mar 2024 19:00:17 -0500 [thread overview]
Message-ID: <c70a4e4f-00a6-4961-82fa-1eb15f26f483@redhat.com> (raw)
In-Reply-To: <ZdR4tSEiYnKypjoc@tucnak>
On 2/20/24 05:02, Jakub Jelinek wrote:
> On Tue, Feb 20, 2024 at 09:01:10AM +0100, Richard Biener wrote:
>> I'm not sure those would be really equivalent (MEM_REF vs. V_C_E
>> as well as combined vs. split). It really depends how RTL expansion
>> handles this (as you can see padding can be fun here).
>>
>> So I'd be nervous for a match.pd rule here (also we can't match
>> memory defs).
>
> Ok. Perhaps forwprop then; anyway, that would be an optimization.
>
>> As for your patch I'd go with a MEM_REF unconditionally, I don't
>> think we want different behavior whether there's padding or not ...
>
> I've made it conditional so that the MEM_REFs don't appear that often in the
> FE trees, but maybe that is fine.
>
> The unconditional patch would then be:
OK.
> 2024-02-20 Jakub Jelinek <jakub@redhat.com>
>
> gcc/c-family/
> * c-common.cc (resolve_overloaded_atomic_exchange): Instead of setting
> p1 to VIEW_CONVERT_EXPR<I_type> (*p1), set it to MEM_REF with p1 and
> (typeof (p1)) 0 operands and I_type type.
> (resolve_overloaded_atomic_compare_exchange): Similarly for p2.
> gcc/cp/
> * pt.cc (tsubst_expr): Handle MEM_REF.
> gcc/testsuite/
> * g++.dg/ext/atomic-5.C: New test.
>
> --- gcc/c-family/c-common.cc.jj 2024-02-17 16:40:42.831571693 +0100
> +++ gcc/c-family/c-common.cc 2024-02-20 10:58:56.599865656 +0100
> @@ -7793,9 +7793,14 @@ resolve_overloaded_atomic_exchange (loca
> /* Convert object pointer to required type. */
> p0 = build1 (VIEW_CONVERT_EXPR, I_type_ptr, p0);
> (*params)[0] = p0;
> - /* Convert new value to required type, and dereference it. */
> - p1 = build_indirect_ref (loc, p1, RO_UNARY_STAR);
> - p1 = build1 (VIEW_CONVERT_EXPR, I_type, p1);
> + /* Convert new value to required type, and dereference it.
> + If *p1 type can have padding or may involve floating point which
> + could e.g. be promoted to wider precision and demoted afterwards,
> + state of padding bits might not be preserved. */
> + build_indirect_ref (loc, p1, RO_UNARY_STAR);
> + p1 = build2_loc (loc, MEM_REF, I_type,
> + build1 (VIEW_CONVERT_EXPR, I_type_ptr, p1),
> + build_zero_cst (TREE_TYPE (p1)));
> (*params)[1] = p1;
>
> /* Move memory model to the 3rd position, and end param list. */
> @@ -7873,9 +7878,14 @@ resolve_overloaded_atomic_compare_exchan
> p1 = build1 (VIEW_CONVERT_EXPR, I_type_ptr, p1);
> (*params)[1] = p1;
>
> - /* Convert desired value to required type, and dereference it. */
> - p2 = build_indirect_ref (loc, p2, RO_UNARY_STAR);
> - p2 = build1 (VIEW_CONVERT_EXPR, I_type, p2);
> + /* Convert desired value to required type, and dereference it.
> + If *p2 type can have padding or may involve floating point which
> + could e.g. be promoted to wider precision and demoted afterwards,
> + state of padding bits might not be preserved. */
> + build_indirect_ref (loc, p2, RO_UNARY_STAR);
> + p2 = build2_loc (loc, MEM_REF, I_type,
> + build1 (VIEW_CONVERT_EXPR, I_type_ptr, p2),
> + build_zero_cst (TREE_TYPE (p2)));
> (*params)[2] = p2;
>
> /* The rest of the parameters are fine. NULL means no special return value
> --- gcc/cp/pt.cc.jj 2024-02-17 16:40:42.868571182 +0100
> +++ gcc/cp/pt.cc 2024-02-20 10:57:36.646973603 +0100
> @@ -20088,6 +20088,14 @@ tsubst_expr (tree t, tree args, tsubst_f
> RETURN (r);
> }
>
> + case MEM_REF:
> + {
> + tree op0 = RECUR (TREE_OPERAND (t, 0));
> + tree op1 = RECUR (TREE_OPERAND (t, 0));
> + tree new_type = tsubst (TREE_TYPE (t), args, complain, in_decl);
> + RETURN (build2_loc (EXPR_LOCATION (t), MEM_REF, new_type, op0, op1));
> + }
> +
> case NOP_EXPR:
> {
> tree type = tsubst (TREE_TYPE (t), args, complain, in_decl);
> --- gcc/testsuite/g++.dg/ext/atomic-5.C.jj 2024-02-20 10:57:36.647973589 +0100
> +++ gcc/testsuite/g++.dg/ext/atomic-5.C 2024-02-20 10:57:36.647973589 +0100
> @@ -0,0 +1,42 @@
> +// { dg-do compile { target c++14 } }
> +
> +template <int N>
> +void
> +foo (long double *ptr, long double *val, long double *ret)
> +{
> + __atomic_exchange (ptr, val, ret, __ATOMIC_RELAXED);
> +}
> +
> +template <int N>
> +bool
> +bar (long double *ptr, long double *exp, long double *des)
> +{
> + return __atomic_compare_exchange (ptr, exp, des, false,
> + __ATOMIC_RELAXED, __ATOMIC_RELAXED);
> +}
> +
> +bool
> +baz (long double *p, long double *q, long double *r)
> +{
> + foo<0> (p, q, r);
> + foo<1> (p + 1, q + 1, r + 1);
> + return bar<0> (p + 2, q + 2, r + 2) || bar<1> (p + 3, q + 3, r + 3);
> +}
> +
> +constexpr int
> +qux (long double *ptr, long double *val, long double *ret)
> +{
> + __atomic_exchange (ptr, val, ret, __ATOMIC_RELAXED);
> + return 0;
> +}
> +
> +constexpr bool
> +corge (long double *ptr, long double *exp, long double *des)
> +{
> + return __atomic_compare_exchange (ptr, exp, des, false,
> + __ATOMIC_RELAXED, __ATOMIC_RELAXED);
> +}
> +
> +long double a[6];
> +const int b = qux (a, a + 1, a + 2);
> +const bool c = corge (a + 3, a + 4, a + 5);
>
>
> Jakub
>
prev parent reply other threads:[~2024-03-07 0:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-08 1:01 [PATCH] libstdc++: atomic: Add missing clear_padding in __atomic_float constructor xndcn
2024-01-15 0:45 ` [PING][PATCH] " xndcn
2024-01-15 3:46 ` [PATCH] " H.J. Lu
2024-01-16 9:53 ` xndcn
2024-01-16 10:12 ` Xi Ruoyao
2024-01-16 16:16 ` xndcn
2024-01-24 15:53 ` xndcn
2024-01-30 16:08 ` [PING][PATCH] " xndcn
2024-01-30 16:31 ` [PATCH] " Jonathan Wakely
2024-01-30 16:34 ` Jonathan Wakely
2024-01-30 16:50 ` Jakub Jelinek
2024-01-31 17:19 ` xndcn
2024-02-01 13:54 ` Jonathan Wakely
2024-02-02 16:52 ` xndcn
2024-02-16 12:38 ` Jonathan Wakely
2024-02-16 13:51 ` Jonathan Wakely
2024-02-16 14:10 ` Jakub Jelinek
2024-02-16 15:15 ` Jonathan Wakely
2024-03-14 15:13 ` Jonathan Wakely
2024-03-25 15:42 ` [PING][PATCH] " xndcn
2024-02-19 7:55 ` [PATCH] c-family, c++: Fix up handling of types which may have padding in __atomic_{compare_}exchange Jakub Jelinek
2024-02-20 0:12 ` Jason Merrill
2024-02-20 0:51 ` Jakub Jelinek
2024-02-20 8:01 ` Richard Biener
2024-02-20 10:02 ` [PATCH] c-family, c++, v2: " Jakub Jelinek
2024-02-20 10:11 ` Richard Biener
2024-02-20 10:27 ` Jakub Jelinek
2024-03-07 0:00 ` Jason Merrill [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=c70a4e4f-00a6-4961-82fa-1eb15f26f483@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jwakely@redhat.com \
--cc=rguenther@suse.de \
/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).