From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id F3D4A3858D33 for ; Tue, 20 Feb 2024 10:27:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F3D4A3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F3D4A3858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708424851; cv=none; b=UVsM26CCO71Y8b6Cb4+4CrwyXXNE8ZuGPQnAMFN3qTka1TZr6ue0AERc1MomPpE072OIJUsdymVqboQ07AXvtfXRD9RW0yGa8myGfxqh3XZnpJ5xcI7cDjEKKrCNtdePmpUH3rh5rhe4lGInyfg/hI91UXbKRL6h7D9KztJdegI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708424851; c=relaxed/simple; bh=/p7C5wmzrwjfCZ5m+LZg1uzWR+6Atx7wHD9awKruRNM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=dZVuQZe7FrqWtBAVuFioZTLLTKZKXQ91S4CmToEjJaw6yWJmEBYlz2e+gkq3emCWDpN3Dq5CYtn0EVH3o/TJDj+/VRY4fjNCl3A0OLq8E+rhEL00Xo112DLJfP6m9Z08rF3LctfZzOw/8/5PvuUrhnRt1c1fkLiFbe7gmzD4tOA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708424849; h=from:from:reply-to:reply-to:subject:subject: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=B3cSRJgUlZknikI8k/b3FcEtsV3dOxlYEc18G9QXbF8=; b=BzV6eY+EjP710prKQVgOgUk3n+j/nyB+M/hltjyqlwegsj0nAteagKrAyipDY4NTzsgReC BvbrbUvlz8vjM7wjqv/onIPyUQrxgNiHea0638cyRJjafHhJXTogtaitihAekFMtfOkoQG rdEMcmuPzRtXZo4f5ZeKopiuLOQZXJ8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-355-t49KKbYKO7G2nTotfZ2nAw-1; Tue, 20 Feb 2024 05:27:27 -0500 X-MC-Unique: t49KKbYKO7G2nTotfZ2nAw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 46748185A780; Tue, 20 Feb 2024 10:27:27 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0968740C1064; Tue, 20 Feb 2024 10:27:26 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 41KAROCi436747 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 20 Feb 2024 11:27:24 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 41KARNAc436746; Tue, 20 Feb 2024 11:27:23 +0100 Date: Tue, 20 Feb 2024 11:27:23 +0100 From: Jakub Jelinek To: Richard Biener 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 Message-ID: Reply-To: Jakub Jelinek References: <5988812a-3f21-4ef4-9205-fe267c356d58@redhat.com> <39q9r137-3884-67oq-2334-70q42so2sp22@fhfr.qr> <2p7p8150-3017-46s5-042p-rp4r3r076oos@fhfr.qr> MIME-Version: 1.0 In-Reply-To: <2p7p8150-3017-46s5-042p-rp4r3r076oos@fhfr.qr> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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, Feb 20, 2024 at 11:11:22AM +0100, Richard Biener wrote: > > --- 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). Just to help the FE when trying to constexpr evaluate it, because for constexpr evaluation it evaluates MEM_REF the same as INDIRECT_REF (and punts on non-0 second argument). The actual call is non-constexpr, just wanted to avoid ICEs or something similar, constexpr evaluation can try to process the arguments (and succeed or fail, doesn't matter, but not ICE) and then the call will not be constant expression and so everything won't be. > 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. I don't think using __atomic_*exchange on non-default as is valid, if one doesn't have the exact __atomic_*exchange_N, it is handled as a library call which is passed pointers and that definitely will not deal with non-default address spaces. Furthermore, the type should be the same in all arguments, and the first argument is just converted to I_type_ptr and dealt with later, so I don't think it ever worked even for the supported sizes. int foo (__seg_gs int *a, __seg_gs int *b, __seg_gs int *c) { return __atomic_compare_exchange (a, b, c, 0, __ATOMIC_RELAXED, __ATOMIC_RELAXED); } results in movl (%rsi), %eax movl %gs:(%rdx), %edx lock cmpxchgl %edx, (%rdi) sete %dl je .L2 movl %eax, (%rsi) .L2: i.e. pretty much random what is loaded from a different AS and what is not. Jakub