From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id D6AFE3858D28 for ; Tue, 20 Feb 2024 10:11:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D6AFE3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D6AFE3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708423894; cv=none; b=DUEj1KTOJN8IHvSABPYlJonlUDMF4DSz0m7eboA9xFpnJt9338yKdbDB2ODVfD21FYs9LmDeMQvQNxVXqcXftVacR8jfkyjbOgRSTSf+FvnUsTVJKGr9ob/dEhhtqMUfJ8RKitBJ+efephwuW1k+RWJIp/SfWywOnRzVjeoolMQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708423894; c=relaxed/simple; bh=qWevkTTg/Z4nirUtRUN8weQyHseTizAgT0mz0LyP6aU=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=ZApgAeMSAg9Y0ZOLlVQIIEHhf+c+rhEYwBCK/ELWaUmCRihQlrKssCiKjnptBLC7hVu5/pwGUdZUGdOPtjNxQbUaHpCJjoJft/HTDdNYmEfcIchaaEywKmljcp7R7iLnEdAGFJxE8FVQgQt2TJRIk7Ktgo3GcpG+ftAIcid4OME= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.4.150] (unknown [10.168.4.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id ABC691FD35; Tue, 20 Feb 2024 10:11:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1708423882; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qsOyhiwSepb1p9vwiFTZfDzmspWO+lSKS9T/cevmGWk=; b=vK7PB4dCM0AhKkLNBDzEZUjsU6w47tmOhR6JvrktfFQjC7XjrohtRz+oRIygndoFSBqYFr E1/f1suGyUEamrfdczQZOEoIy8CD4FyqiA0V2sXByBFoTPoopm+34oHXEVHgKbppi2Qngm JU8+Pm8MlKd6zi7v5M05NYtyt2Frz9U= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1708423882; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qsOyhiwSepb1p9vwiFTZfDzmspWO+lSKS9T/cevmGWk=; b=hNA9V94BxGNUTYlGKpXHrRqjexfJ6RbaZoXmgExczAkJpJiENP22tCq9asIzODQY5umdYY LcaUmBBjo+gujuAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1708423882; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qsOyhiwSepb1p9vwiFTZfDzmspWO+lSKS9T/cevmGWk=; b=vK7PB4dCM0AhKkLNBDzEZUjsU6w47tmOhR6JvrktfFQjC7XjrohtRz+oRIygndoFSBqYFr E1/f1suGyUEamrfdczQZOEoIy8CD4FyqiA0V2sXByBFoTPoopm+34oHXEVHgKbppi2Qngm JU8+Pm8MlKd6zi7v5M05NYtyt2Frz9U= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1708423882; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qsOyhiwSepb1p9vwiFTZfDzmspWO+lSKS9T/cevmGWk=; b=hNA9V94BxGNUTYlGKpXHrRqjexfJ6RbaZoXmgExczAkJpJiENP22tCq9asIzODQY5umdYY LcaUmBBjo+gujuAA== Date: Tue, 20 Feb 2024 11:11:22 +0100 (CET) From: Richard Biener To: Jakub Jelinek cc: Jason Merrill , gcc-patches@gcc.gnu.org, Jonathan Wakely Subject: Re: [PATCH] c-family, c++, v2: Fix up handling of types which may have padding in __atomic_{compare_}exchange In-Reply-To: Message-ID: <2p7p8150-3017-46s5-042p-rp4r3r076oos@fhfr.qr> References: <5988812a-3f21-4ef4-9205-fe267c356d58@redhat.com> <39q9r137-3884-67oq-2334-70q42so2sp22@fhfr.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Authentication-Results: smtp-out2.suse.de; none X-Spam-Level: X-Spam-Score: -4.29 X-Spamd-Result: default: False [-4.29 / 50.00]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.20)[-0.976]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; BAYES_HAM(-3.00)[100.00%]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FUZZY_BLOCKED(0.00)[rspamd.com] X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 20 Feb 2024, 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: > > 2024-02-20 Jakub Jelinek > > gcc/c-family/ > * c-common.cc (resolve_overloaded_atomic_exchange): Instead of setting > p1 to VIEW_CONVERT_EXPR (*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), Why the V_C_E to I_type_ptr? The type of p1 doesn't really matter (unless it could be a non-pointer). Also note that I_type needs to be properly address-space qualified in case the access should be to an address-space. Formerly with the INDIRECT_REF that would likely be automagic. > + 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 > +void > +foo (long double *ptr, long double *val, long double *ret) > +{ > + __atomic_exchange (ptr, val, ret, __ATOMIC_RELAXED); > +} > + > +template > +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 > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)