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 D64553858CDB for ; Thu, 30 Mar 2023 15:59:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D64553858CDB 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=1680191986; 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=n2VsBY2odmMcT6Uch5Uhwjew8odskBWHIMPLXj2zkd4=; b=NnuJtBN3AYwhNb0daQFZaDpU5geTa/AYOu/rB7sgr6XpXkb4Ri1Q8uShE8edscrhBfJFCA uPUCDWGVCKID65PHa2wXaWh/lJteOR8mwkTRiIeKok5XYTnveQH11XID98mSqRPCU0P6Je /71tvPFPNqAxWN27EGQpE4c+vfBuGEg= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-30-Xd7lkwogNzCcYvCudsMP3A-1; Thu, 30 Mar 2023 11:59:44 -0400 X-MC-Unique: Xd7lkwogNzCcYvCudsMP3A-1 Received: by mail-lf1-f71.google.com with SMTP id e12-20020a19674c000000b004e9af173e04so7525965lfj.14 for ; Thu, 30 Mar 2023 08:59:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680191983; 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=n2VsBY2odmMcT6Uch5Uhwjew8odskBWHIMPLXj2zkd4=; b=m53/GroeXizjvLBFdcfs/ql271hso3phfO7ST5FMBWe8Y56GNeiPBDD6R5F3ESkLwY kyouDkNJshGxcOkf+PuUZDxcN9/RQaV1FffofXcxI3qOHPlcuo/0QtS5sc0CV/pXl6Wl pnVbRIjBvLxLPvXCuSNXvMRAGQ5aqU36uGozNfT/vsYJafgtGAiDKV0iazESgW1iUOMD 0ccMSOnyXU2lQzkjF2Bw9J50bzLaEfj//aKjSQroZJkLAL8Juo7feu4zSa5iIRbtijIq WOZ19S3+hAcCzMGi7VmR/+/1/F8VzECPhqGBNYc2HPWeHfnqzSOtuWnVEMGm+pFMuf8X 8xxQ== X-Gm-Message-State: AAQBX9e9taXhKMu7xM2wF/yhkUK6i2S7AZY7AXqB9QKxj+gy3Vf7dpt5 n1sfiqgVdxNSyahlbFvF/BtYjP8kwwcS3lXA1bRkSWlH3M/QX5464UpvnFYTFJfeweCdW1IZOIk 8bLL/qkNUOSk77E2UhcbAiAAqR+ZTwFkdGkUKy9e6UA== X-Received: by 2002:a2e:86d8:0:b0:299:ac1c:d8b3 with SMTP id n24-20020a2e86d8000000b00299ac1cd8b3mr7427247ljj.9.1680191983498; Thu, 30 Mar 2023 08:59:43 -0700 (PDT) X-Google-Smtp-Source: AKy350a8pBB1abUYrh87dAE20eOyvvvWMQO5XFSmp+3ErEHDdoWiw2ShiCJvmHbt5kqcXQ3kp4X0YaHpuepsqbnlnRE= X-Received: by 2002:a2e:86d8:0:b0:299:ac1c:d8b3 with SMTP id n24-20020a2e86d8000000b00299ac1cd8b3mr7427241ljj.9.1680191983034; Thu, 30 Mar 2023 08:59:43 -0700 (PDT) MIME-Version: 1.0 References: <20230329234000.1405216-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 30 Mar 2023 16:59:31 +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=-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 autolearn=unavailable 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 15:44, Jonathan Wakely wrote: > > 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). In fact, thinking about P2641 some more, I might revert this change. Instead of adding an extra bool member to support constexpr, I think I'll just remove the 'constexpr' keywords from basic_endpoint for now, and implement it in terms of just inspecting the sa_family_t member of the union members. And then later, once we have something like P2641, we can re-add the constexpr keywords and use is_within_lifetime during constant evaluation. That way we don't add a bool then need to take it away again, changing the ABI each time.