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 736133858C50 for ; Thu, 30 Mar 2023 14:44:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 736133858C50 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=1680187480; h=from:from: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=wn25T9ASuPNeWbaDNVf/82L00HRXUIe8KetusepBMeE=; b=N0dH3a9YHrwKiD3fXMEUyNOPzz9HDc+BGyFcFIztp2SzCYhb47+Wt8AbVPQ2tru8zmutet j8Em8Di4Moa1LdwzQIMFgfonLAG4mMEEi4bGp114P9WHIBg+cccDqReMLlkDRbC1QQBxZm g54HBeGX60Zdp1rQIiBSPWb+5JB+fLs= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-138-VTxH40qMPmqZoy1xIPRW4w-1; Thu, 30 Mar 2023 10:44:38 -0400 X-MC-Unique: VTxH40qMPmqZoy1xIPRW4w-1 Received: by mail-lj1-f198.google.com with SMTP id e15-20020a05651c038f00b002a226c2a222so4318007ljp.12 for ; Thu, 30 Mar 2023 07:44:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680187477; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wn25T9ASuPNeWbaDNVf/82L00HRXUIe8KetusepBMeE=; b=lwqAOf0WaoV2wIPBwFfOLOzQZ/ZFQkU+8DmRvuc6KZnLsYk/0ax8HQvSCAjoYAFYjw 4fI+MT5dSQ/+pQ39RNqwWq4lQn1H8MQmFj7mIDoT/xq216yqk/L2B0Yls/UyxTNpcx+n tgBhT6XPFrzQq/UG9x4CLhS6vjzQS38EcFkArcXH2qd8vO3Khp0nFUlOHfdtbloFtfH6 PqGi3KJwZakHF/XPpmnxwXO/Eempoopa5+xkFoNZD6xWpzr9hGSpGzuGHHnGrxXoq0q+ S93RdRCAEsyUGrgx/zPl1jWfMxquc2C4o0jdAIRArgs6vt8B8LMBwODc5sMqUtEXb0Or Y4Rg== X-Gm-Message-State: AAQBX9eLbuIlfpwVmKHwOkZaeR7U04ZPlpr2ntEftRa/aMqkeQrSnGTV nS0aoiayWqQXlRCcb3hk2O7l3oj9e7gkr9HPywLb6G5DG4xHvJya1f/lLSNgoHE/huFvJhjsINw KPSZW0GvT3MaiWi0PouC06SVyHSLz/6a0sXM1xwV5bg== X-Received: by 2002:ac2:514e:0:b0:4e8:dcb2:b2ea with SMTP id q14-20020ac2514e000000b004e8dcb2b2eamr7015053lfd.8.1680187477416; Thu, 30 Mar 2023 07:44:37 -0700 (PDT) X-Google-Smtp-Source: AKy350bDrIGGOO2galQ+TlbQB1JF9FwQSIm/diJlvDRFweiaorsB7/mYfWS34q89nVnfdnJw28y8UZ5G6rT222Lwl/s= X-Received: by 2002:ac2:514e:0:b0:4e8:dcb2:b2ea with SMTP id q14-20020ac2514e000000b004e8dcb2b2eamr7015042lfd.8.1680187476872; Thu, 30 Mar 2023 07:44:36 -0700 (PDT) MIME-Version: 1.0 References: <20230329234000.1405216-1-jwakely@redhat.com> In-Reply-To: <20230329234000.1405216-1-jwakely@redhat.com> From: Jonathan Wakely Date: Thu, 30 Mar 2023 15:44:25 +0100 Message-ID: Subject: Re: [committed] libstdc++: Fix constexpr functions in To: libstdc++@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.0 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 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 Thu, 30 Mar 2023 at 00:40, Jonathan Wakely via Libstdc++ wrote: > > Tested powerpc64le-linux. Pushed to trunk. > > -- >8 -- > > Change ip::basic_endpoint to work in constant expressions, but only for > C++20 and later (due to the use of a union, which cannot change active > member in constexpr evaluation until C++20). > > During constant evaluation we cannot inspect the common initial sequence > of basic_endpoint's union members to check whether sin_family == AF_INET > or AF_INET6. This means we need to store an additional boolean member > that remembers whether we have a v4 or v6 address. The address type can > change behind our backs if a user copies an address to the data() > pointer and then calls resize(n), so we need to inspect the sa_family_t > member in the union after a resize and update the boolean. POSIX only > guarantees that the sa_family_t member of each protocol-specific address > structure is at the same offset and of the same type, not that there is > a common initial sequence. The check in resize is done using memcmp, so > that we avoid accessing an inactive member of the union if the > sockaddr_in and sockaddr_in6 structures do not have a common initial > sequence that includes the sa_family_t member. If we had https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2641r2.html then we wouldn't need the extra boolean. During constant evaluation we could use the new magic function to check which union member is active, and during runtime we could inspect the sa_family_t member (still using memcmp, because POSIX doesn't guarantee a common initial sequence, even though I think everybody does give it one in practice).