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.133.124]) by sourceware.org (Postfix) with ESMTPS id C94053858D20 for ; Fri, 28 Jul 2023 14:26:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C94053858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690554373; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T4QvxtTsw9PNK1ILW7NGgfW2Xoc8esxPrpy6RVjT0Xw=; b=hSu6U3NkXM4sLTbJCxkzfUbOJ7WCFUtwwpL8jNdT1DNyaFuz5OuAwL98EGsGSFMzDqc4Vd zoz+Q3b6e0soWFOKBIKLzw4e46BU5mqvEoSMktPjWkgkla8Q8jj30q3Np0JqzZVMyh5xtE FuNx7euN7hsyiYB+mCTk+CIarTamqqo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-224-Tf-7GdUcPyqan4WrG5Cchg-1; Fri, 28 Jul 2023 10:26:09 -0400 X-MC-Unique: Tf-7GdUcPyqan4WrG5Cchg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3BD3180027F; Fri, 28 Jul 2023 14:26:09 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 00B572166B25; Fri, 28 Jul 2023 14:26:08 +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 36SEQ6mo2839725 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 28 Jul 2023 16:26:06 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 36SEQ5OU2839724; Fri, 28 Jul 2023 16:26:05 +0200 Date: Fri, 28 Jul 2023 16:26:04 +0200 From: Jakub Jelinek To: Martin Uecker Cc: gcc-patches@gcc.gnu.org Subject: Re: _BitInt vs. _Atomic Message-ID: Reply-To: Jakub Jelinek References: <8ebe73bb1f51d1a3e01ac9e901223a3db51b310a.camel@gwdg.de> MIME-Version: 1.0 In-Reply-To: <8ebe73bb1f51d1a3e01ac9e901223a3db51b310a.camel@gwdg.de> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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_H4,RCVD_IN_MSPIKE_WL,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 Fri, Jul 28, 2023 at 04:03:39PM +0200, Martin Uecker wrote: > > On Thu, Jul 27, 2023 at 07:06:03PM +0000, Joseph Myers wrote: > > > I think there should be tests for _Atomic _BitInt types. Hopefully atomic > > > compound assignment just works via the logic for compare-and-exchange > > > loops, but does e.g. atomic_fetch_add work with _Atomic _BitInt types? > > > > So, there are 2 issues. > > > > One is something I haven't seen being handled for C at all so far, but > > handled for C++ - padding bits. > > > > Already e.g. x86 long double has some padding bits - 16 bits on ia32, > > 48 bits on x86_64, when one does > > _Atomic long double l; > > ... > > l += 2.0; > > it will sometimes work and sometimes hang forever. > > Similarly atomic_compare_exchange with structs which contain padding > > (unions with padding bits are lost case, there is nothing that can be > > reliably done for that, because we don't know at runtime what is the active > > union member if any). And _BitInt if it doesn't use all bits in > > all containing limbs has padding as well (and psABI doesn't say it is sign > > or zero extended). > > What is the problem here? In C, atomic_compare_exchange is defined in terms > of the memory content which includes padding. So it may fail spuriously > due to padding differences (but it may fail anyway for arbitrary reasons > even without padding differences), but then should work in the second  > iterations. See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0528r3.html for background. The thing is that user doesn't have much control over those padding bits, so whether _Atomic operations on long double (when it is 80 bit and stores from hw actually store 10 bytes rather than 12 or 16), or _BitInt(37) or _BitInt(195) or struct S { char a; int b; }; then depend purely on luck. If the expected value is based on atomic_load on the atomic_compare_exchange location or whatever atomic_compare_exchange gave back, if in the loop one e.g. adds something to it, then again it might get different padding bits from what is originally in memory, so it isn't true that it will always succeed at least in the second loop iteration. Jakub