From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id C97333858C74; Wed, 27 Sep 2023 04:44:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C97333858C74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-405524e6768so80731465e9.2; Tue, 26 Sep 2023 21:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695789861; x=1696394661; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hr5w/LVNFoyptMxGSzEVFd8gh4ju3LgSJgwDI+zm0gs=; b=DS274ougFvZ5DH51V2anisTQLyygHyVqX5giVeuv+bXzVd16UHFcTF203tDgaZCx+h skyLVO8zIFkX0H0orS0+QRFYgM/eJt+YDoGGiLhw+tQSjqRpC3fDOdqN7RvL5YxDEvpL w5EzNAHm0Tp+sWA2a+sxN+Z9HPwkz6E010ijh1vSDxGM+Jb3TWxa9K1Zsvm1LrcOh55Q 3eRG1Xh5EabxnsegRW/qlBTpqe84HxK4u6X7gGZ5faSwiqNAdEYLEGaAHTd/U1AHnusG sY8XJqXtVuauE2f49gVFqRRjh7y8LW12xMsWvwBskFAFcu+jMieO1psMCVvJ2BKZtGrL 1Avw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695789861; x=1696394661; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hr5w/LVNFoyptMxGSzEVFd8gh4ju3LgSJgwDI+zm0gs=; b=qHccMAZc4u1zr1mActAM5n7ECVoAPEpN5Sh4tXTy2e/r6cprwqgJXauhWPZXBcz7Za vnTptVzk+cPJGG0Di4trAHyvFz10XJkWyPKqCURtT1TZM0F/qQLUIL/F5HLAt4wjChZo IscRuspOVuDHF0h5/fJNTEJq2CbgWzTsDZQU/58Uq7sRH7bt4Pnb9G85mWYVu7HQJ2Kq a9qVv32nktLTxLQRsA3O8R144wdKdjD/m5Zckk0EzXySHjUhKI7yp2dlyjnK99pYexjU UL2G/dPSaTy5mYx27Cg908rpZRCGa6Fp8h09RIyo4jmZXzvevenfqYnINDAX3EGEhs1t lG/A== X-Gm-Message-State: AOJu0Yx/E0a5JNQU+qPO+8Ftpg9bAFXynCNWmxSYBsWjqVcNcN7/EaMs zcqFkzOFIBPHJbm/LkDdRgNSOyM5vDeVmQ== X-Google-Smtp-Source: AGHT+IFdD1fWzs/oPg5WkEHjB8iJZxAWv1Ed+yZbjPPwplEuvGOPbDNcAcFgEthAZ0SZ4MptW/iPRA== X-Received: by 2002:a1c:720c:0:b0:401:bf56:8ba6 with SMTP id n12-20020a1c720c000000b00401bf568ba6mr875261wmc.28.1695789861155; Tue, 26 Sep 2023 21:44:21 -0700 (PDT) Received: from [10.34.0.76] ([89.207.171.102]) by smtp.gmail.com with ESMTPSA id n26-20020a7bcbda000000b004063977eccesm3945689wmi.42.2023.09.26.21.44.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Sep 2023 21:44:20 -0700 (PDT) Message-ID: Date: Wed, 27 Sep 2023 06:44:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11 [PR 111050] Content-Language: en-US From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= To: Jonathan Wakely Cc: rs2740@gmail.com, libstdc++ , gcc-patches References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: Still no chance to get feedback from TC ? Maybe I can commit the below then ? AFAICS on gcc mailing list several gcc releases were done recently, too late. On 14/09/2023 06:46, François Dumont wrote: > Author: TC > Date:   Wed Sep 6 19:31:55 2023 +0200 > >     libstdc++: Force _Hash_node_value_base methods inline to fix abi > (PR111050) > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d > >     changed _Hash_node_value_base to no longer derive from > _Hash_node_base, which means >     that its member functions expect _M_storage to be at a different > offset. So explosions >     result if an out-of-line definition is emitted for any of the > member functions (say, >     in a non-optimized build) and the resulting object file is then > linked with code built >     using older version of GCC/libstdc++. > >     libstdc++-v3/ChangeLog: > >             PR libstdc++/111050 >             * include/bits/hashtable_policy.h >             (_Hash_node_value_base<>::_M_valptr(), > _Hash_node_value_base<>::_M_v()) >             Add [[__gnu__::__always_inline__]]. > > Ok to commit ? > > On 12/09/2023 18:09, Jonathan Wakely wrote: >> On Mon, 11 Sept 2023 at 18:19, François Dumont >> wrote: >>> >>> On 11/09/2023 13:51, Jonathan Wakely wrote: >>>> On Sun, 10 Sept 2023 at 14:57, François Dumont via Libstdc++ >>>> wrote: >>>>> Following confirmation of the fix by TC here is the patch where I'm >>>>> simply adding a 'constexpr' on _M_next(). >>>>> >>>>> Please let me know this ChangeLog entry is correct. I would prefer >>>>> this >>>>> patch to be assigned to 'TC' with me as co-author but I don't know >>>>> how >>>>> to do such a thing. Unless I need to change my user git identity >>>>> to do so ? >>>> Sam already explained that, but please check with Tim how he wants to >>>> be credited, if at all. He doesn't have a copyright assignment, and >>>> hasn't added a DCO sign-off to the patch, but it's small enough to not >>>> need it as this is the first contribution credited to him. >>>> >>>> >>>>>        libstdc++: Add constexpr qualification to >>>>> _Hash_node::_M_next() >>>> What has this constexpr addition got to do with the ABI change and the >>>> always_inline attributes? >>>> >>>> It certainly doesn't seem like it should be the summary line of the >>>> git commit message. >>> Oops, sorry, that's what I had started to do before Tim submitted >>> anything. >>> >>> Here is latest version: >> No patch attached, and the ChangeLog below still mentions the constexpr. >> >> I've pinged Tim via another channel to ask him about the author >> attribution. >> >> >>> Author: TC >>> Date:   Wed Sep 6 19:31:55 2023 +0200 >>> >>>       libstdc++: Force inline on _Hash_node_value_base methods to >>> fix abi >>> (PR111050) >>> >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d >>> >>>       changed _Hash_node_value_base to no longer derive from >>> _Hash_node_base, which means >>>       that its member functions expect _M_storage to be at a different >>> offset. So explosions >>>       result if an out-of-line definition is emitted for any of the >>> member functions (say, >>>       in a non-optimized build) and the resulting object file is then >>> linked with code built >>>       using older version of GCC/libstdc++. >>> >>>       libstdc++-v3/ChangeLog: >>> >>>               PR libstdc++/111050 >>>               * include/bits/hashtable_policy.h >>>               (_Hash_node_value_base<>::_M_valptr(), >>> _Hash_node_value_base<>::_M_v()) >>>               Add [[__gnu__::__always_inline__]]. >>>               (_Hash_node<>::_M_next()): Add constexpr. >>> >>>       Co-authored-by: François Dumont >>> >>> Ok for you TC (Tim ?) ? >>> >>>